1.3.2. Нормативная база государственного уровня

Российские стандарты. Общие положения по оценке качества программного изделия вычислительной техники, номенклатура и применяемость показателей качества программного изделия представлены в ГОСТ 28195-89 г. «Оценка качества программных средств». Этот документ содержит показатели качества программного изделия, распределенные по фазам ЖЦ программного изделия с указанием метрик, которые могут быть учтены при разработке процедур идентификации и оценки рисков качества программного изделия. Однако некоторые положения этого стандарта не отражают требований к качеству современных программных изделий и альтернативой данному стандарту является группа современных международных стандартов серии ISO (ISO 9126 -1-4:1991-2000; ISO 14598 1-6: 1998-2000).

Зарубежные стандарты. MIL-STD-498:1994 "Разработка и документирование программного обеспечения". Документ утвержден для применения всеми ведомствами и органами министерства обороны США, в котором указано, что разработчик должен осуществлять управление рисками на протяжении всего процесса разработки программного изделия. При этом разработчик должен идентифицировать, провести анализ и установить приоритеты участников проекта разработки программного изделия, связанных с потенциальными техническими рисками, а также рисками по затратам или графикам, и разработать стратегию управления этими рисками; записать риски и стратегию в плане разработки программного изделия; реализовать стратегию в соответствии с планом. Все это свидетельствует о важности проблемы управления рисками в проектах военных программных изделий.

1.3.3. Нормативная база корпоративного уровня

На сегодняшний день среди важных научно-методических документов и стандартов корпоративного и национального уровня по проблеме управления проектами и рисками наукоемких программных проектов можно выделить следующие:

• стандарт РМВОК (Project management body of knowledge) Project Management Institute США;

• метод PJM (Project Management Method) корпорации Oracle;

• метод SEI (Software Engineering Institute) Института программной инженерии США;

• метод Riskit (The Riskit Method for Software Risk Management) университета Мэриленда (США);

• «лучшие практические навыки» SPMN (Software Program Managers Network) Сеть управления программами создания программного обеспечения США;

• метод MSF (Microsoft Solutions Framework) -корпорации Microsoft.

Рассмотрим назначение указанных научно-методических документов корпоративного уровня.

PMBOK (A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE) "Свод знаний по управлению проектами"

Данный документ определяет структуру содержания процесса управления рисками проекта (любого типа) на основе подпроцессов идентификации рисков, анализа и реагирования на риски проекта, что позволяет на практике увеличивать результат положительных событий в проектах и уменьшать последствия неблагоприятных событий.

PJM (PROJECT MANAGEMENT METHOD) Корпорации Oracle "Стандартный подход к руководству проектом"

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

Общий принцип PJM можно определить как методологию на базе процессов, с возможностью настройки в соответствии с конкретными требованиями проекта. Согласно методологии PJM риски и спорные вопросы имеют сходные характеристики. Риски это то, что могло бы иметь место и могло бы оказать воздействие на проект, если бы не были приняты меры по их сдерживанию. А спорные вопросы, как правило, имеют более конкретный характер и будут воздействовать на проект, если не будут приняты меры по их решению. В PJM считается, что спорные вопросы порождают новые риски и поэтому подлежат управлению. Меры по сдерживанию рисков могут влиять на время выполнения и стоимость, что приводит к изменениям в рабочем плане и финансовом плане проекта.

Метод SEI (Software Engineering Institute) Института программной инженерии (США)

Нормативные документы по этому методу описывают методологию управления рисками программного проекта, ориентированную на полный жизненный цикл программного изделия.

Согласно этой методологии SEI структуру процесса управления рисками программного проекта поддерживают три группы методов: оценка рисков программного проекта (метод SRE); непрерывное управление рисками (метод CRM); управление коллективным (корпоративным) риском (метод TRM).

В свою очередь, указанные методы базируются на трех основных конструкциях управления рисками программного проекта: парадигме управления риском, таксономии рисков и диагностике рисков.

Парадигма управления риском в SEI по существу определяет структуру для управления рисками программного проекта и согласно методологии SEI включает последовательность действий (этапов), образующих замкнутый круг (идентификация рисков - анализ рисков - планирование управления рисками - слежение за рисками - управление рисками - идентификация рисков). Замкнутость последовательности этапов подчеркивает, что управление рисками - непрерывный процесс, а последовательность этапов показывает логический поток информации между действиями.

Таксономия рисков - определяет и использует методы идентификации рисков, как первый шаг системного и непрерывного метода управления рисками SEI для увеличения вероятности успешного завершения проекта. Таксономия (классификация) предоставляет инженерную систему для исследования диапазона разрабатываемых программ и, таким образом, определяет общую структуру и организацию идентификации потенциальных рисков наукоемких программных проектов. Метод, используемый в SEI, состоит из классификационного вопросника (TBQ) и процесса для его применения, которые разработаны на основе обширных экспертных знаний и результатах различных практических исследований. Таксономия организует формальную разработку (определение) рисков на 3-х уровнях: класс риска; элемент риска и атрибут риска. TBQ состоит из вопросов для каждого таксономического атрибута, на которые необходимо участникам проекта и экспертам дать ответы, на основании которых делаются выводы по рискам. Практически этот процесс идентификации рисков состоит из серии интервью с группами выбранного персонала проекта и экспертами.

Диагностика рисков представляет собой симпозиум экспертов и участников проекта, на котором методы CRM и TRM приспосабливаются и объединяются с каналами связи клиента, инфраструктурой, существующими методами руководства проектом, управления рисками и техническим прикладным управлением. Диагностика рисков - краеугольный камень процесса диалогового взаимодействия разработчика программного изделия и клиента по вопросам анализа рисков, оценке альтернативных действий и процедур реагирования на риски, что в общем случае может занимать для крупных наукоемких программных проектов от нескольких дней до нескольких месяцев.

Метод RISKIT

Метод Riskit (The Riskit Method for Software Risk Management) разработан в университете Мэриленда (США) и предназначен для управления рисками разработки программного изделия. Основные шаги формального подхода Riskit в управлении рисками программного проекта соответствуют положениям стандартов, руководств и документов международного, корпоративного и ведомственного уровня. При этом следует отметить, что указанный метод в настоящее время не поддерживает процесс управления рисками качества проектов программных изделий.

К достоинствам метода можно отнести:

- использование специальных контрольных списков, которые наряду с методом мозгового штурма упрощают и облегчают процесс идентификации всех потенциально возможных рисков проекта;

- использование оригинального графического способа (языка) представления сценария каждого риска (графом сценария риска) позволяет экспертам более объективно оценить степень важности каждого идентифицированного риска. Применение здесь инструментальных средств «рисования» графа сценария для каждого анализируемого риска повышает производительность работ и снижает трудоемкость метода;

- применение шаблонов документации, инструментальных средств обработки текстов и программного обеспечения электронной таблицы в совокупности упрощает документирование и обработку информации по рискам.

К ограничениям и узким местам метода следует указать:

- сложность и не эффективность применения Riskit на этапе идентификации и мониторинга, а также на этапе анализа и планирования технических рисков (рисков качества программного изделия) вследствие большой размерности задач принятия решений экспертами не автоматизированными способами, а также Riskit принципиально не способен учитывать особенности процесса управления рисками качества наукоемких программных проектов, которые принципиально основываются на иерархической модели характеристик и субхарактеристик качества программного изделия;

- отсутствие инструментальных средств поддержки принятия решений, необходимых для многократного использования по этапам процесса управления рисками и стадиям ЖЦ наукоемких программных проектов в целях выбора альтернатив адекватных предпочтениям экспертов (специалистов), выражаемых качественным или количественным способом.