Анализ рисков и первичная оценка

При планировании разработки программного изделия необхо­димо учитывать имеющиеся многочисленные источники и угрозы рисков в проекте. Риск касается как будущего, так и текущего выбора, если учесть, что любому выбору присуща неопределенность.

Важным моментом при планировании является анализ риска. Примерами областей возможного риска служат

• качество и стабильность требований пользователя;

• стабильность и полнота описания внешних интерфейсов;

• опыт и квалификация кадров;

• техническая новизна проекта.

Анализ риска включает четыре разных вида деятельности:

1. Идентификация риска.

2. Описание риска.

3. Оценка риска.

4. Управление риском.

Прежде всего, необходимо идентифицировать все возможные риски и систематизировать их по категориям. На самом верхнем уровне можно выделить следующие группы:

• риск проектирования;

• технический риск;

• бизнес-риск (деловой риск).

Риски проектирования включают риски, связанные с неопреде­ленностью в финансировании проекта, в квалификации персонала, непостоянством требований заказчика, несвоевременными постав­ками технических и программных средств и т.д. Кроме того, к факторам риска относятся сложность и размер программного изделия.

Технический риск появляется в результате того, что разработ­чик на первых этапах не может предвидеть всех сложностей, которые проявятся на этапах разработки, т.е. проблема всегда сложнее, чем она оценивается вначале.

Деловой риск связан в большей степени с проблемами маркетинга. Например, создан качественный продукт, но он не соответствует либо требованиям рынка, либо стратегической линии компании. Возможно, прекращено его финансирование, тогда как требуется доработка и продвижение на рынок и т.п.

После составления подробного перечня возможных рисков де­лается попытка описать каждый из выявленных рисков с точки зре­ния вероятности его проявления и с точки зрения тех последствий, которые с ним связаны. С этой целью устанавливается шкала, от­ражающая вероятность риска с точки зрения управленца и проек­тировщика, оценивается влияние риска на проектирование и на продукт.

Три фактора определяют степень влияния риска: природа риска, область его действия и время действия. Природа риска показывает, с какими проблемами столкнется разработчик и управленец, когда событие произойдет. Область действия (влияния) риска показывает, что будет затронуто в проекте и скольким пользователям будет причинен ущерб и т.д. Временной фактор риска характеризует, когда и как долго будет ощущаться его влияние.

Помимо вероятности его появления риска и степени его влияния, устанавливаются приоритеты рисков, которые обычно рассматриваются с точки зрения возможного нарушения графика работ, превышения выделенных средств и нарушений требований поль­зователя. На этапе описания рисков необходимо думать о путях предотвращения наиболее из них опасных, т.е. об управлении рисками.

2.9. Размерно-ориентированные метрики: правила оценивания, область применимости

Размерно-ориентированные метрики позволяют прямо измерить программное изделие и процесс его разработки. Основываются такие метрики на оценках количества строк кода программ или других подобных количественных характеристиках. Это наиболее распространенная методика оценки программных проектов.

Терминология. В условиях доминирования англоязычной терминологии, которая внедряется даже в традиционную русскоязычную систему терминов, дадим как нормальное, так и англоязычное обозначение. Объёмом программного изделия будем называть количество строк исходного кода, единица измерения (мера) – тысяча строк кода, обозначение – СК. Например, 5 СК означает 5 тыс. строк исходного кода. Аналогичное англоязычное обозначение – SLOC (Source Lines Of Code) или просто LOC.

Первоначально оценки, основанные на измерении СК, применялись в условиях, когда для языков программирования характерным было соответствие одной строки кода одной команде языка. Со временем это соответствие для них перестало выполняться: одна физическая строка кода может содержать несколько команд языка и наоборот. Кроме того, большую роль стал играть стиль программирования, требующий поддержки определённой структуры программы, наличия комментариев и т.п.

Не существует единственного общепризнанного подхода к оценке, приемлемого для различных языков программирования и ориентированного на универсальное применение. Нередко объём определяется как общее число строк кода за исключением пустых строк и комментариев, причём, подсчитывается именно число «физических» строк, наличие нескольких операторов на одной строке не учитывается. Этот подход нельзя считать правильным, так как он побуждает отказываться от комментариев, что отрицательно сказывается на качестве программы.

Размерно-ориентированные метрики, основанные на строках кода, имеют и другие варианты, с помощью которых оцениваются отдельные характеристики проекта, например:

• число строк, содержащих исходный код и комментарии (Lines with Both Code and Comments, C&SLOC);

• процент комментариев;

• среднее число строк для функций (методов);

• среднее число строк для модулей;

• среднее число строк для классов.