Марк Паулк - Модель зрелости процессов разработки программного обеспечения
Критические зависимости могут возникать как внутри группы разработки ПО (т. е. между подгруппами), так и между группой разработки и другими задействованными группами.
3. Определяются критические последовательности, после чего они отражаются в календарном графике разработки. 4. Критические зависимости проекта и критические последовательности календарного графика регулярно отслеживаются. 5. Для каждой критической последовательности устанавливается специфический документированный пороговый критерий, при ожидаемом превышении которого требуется принятие соответствующих мер.
Примеры принимаемых мер:
анализ и моделирование компромиссных вариантов функций, качества, затрат, графика, персонала и других ресурсов;
определение страховочных действий и, по возможности, внесение резерва времени в график;
оценка влияния предполагаемых действий на все критические зависимости;
распространение информации о принятых решениях между всеми задействованными группами.
Операция 10. Выявление, оценка, документирование рисков проекта разработки и управление ими проводится в соответствии с документированной процедурой.
Основные практики, связанные с выявлением и отслеживанием рисков, содержатся в описании Операции № 13 группы ключевых процессов «Планирование проекта» и Операции № 10 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Примеры областей, в которых риски могут с большой вероятностью привести к срыву проекта: календарный график, затраты, функциональные возможности разрабатываемой системы, пропускная способность или реальная производительность, надежность и доступность, использование критических компьютерных ресурсов.
Примеры работ по управлению рисками: раннее выявление проектных задач с высокой степенью риска; определение событий, порождающих риски или повышающих их вероятность; создание прототипов или ранняя реализация модулей с высокой степенью риска; тщательное отслеживание индикаторов ключевых рисков проекта.
Эта процедура обычно определяет следующее:
1. Документируется план управления рисками разработки, который затем используется для выявления рисков и управления ими.
Примеры вопросов, рассматриваемых в плане управления рисками:
необходимые ресурсы (включая персонал и инструментальные средства);
методы управления рисками (т. е. выявление, анализ, определение приоритетов, планирование, мониторинг и устранение);
список выявленных рисков (включая оценку, приоритет, статус и планируемые действия);
график управления рисками;
обязанности и полномочия; метод и периодичность распространения информации о статусе рисков и связанных с ними мероприятиях;
измерения.
2. Планирование страховочных действий основывается на производственном процессе проекта и выполняется в течение всего жизненного цикла разработки.
Примеры областей, в которых проводится планирование страховочных действий:
определение вариантов,
оценка влияния вариантов,
техническая осуществимость вариантов,
распределение резервов управления,
критерии принятия решений о реализации вариантов.
3. Для каждого риска разработки, по возможности, определяются альтернативные решения и критерии выбора альтернатив.
4. Первый вариант и основные изменения плана по управлению рисками проходят экспертную оценку.
См. группу ключевых процессов «Экспертные оценки».
5. Документ плана управления рисками должен быть управляемым и контролируемым.
6. Риски отслеживаются, переоцениваются и перепланируются на определенных этапах проекта, в определенных точках контроля рисков и при планировании значительных изменений, влияющих на проект разработки ПО.
При проведении этих переоценок проверяются и пересматриваются приоритеты рисков и планы по управлению рисками.
Информация, полученная при отслеживании рисков, используется для уточнения оценок рисков и планов по управлению рисками.
7. Группа разработки ПО, а также другие задействованные группы и отдельные лица должны получать информацию о рисках разработки, планах по управлению рисками и результатах действий по снижению рисков.
Примеры групп и отдельных лиц, задействованных в проекте:
заказчик,
субподрядчики,
конечные пользователи,
группа оценки объема составляющих проекта,
системного проектирования,
системного тестирования,
обеспечения качества ПО,
управления конфигурацией ПО,
управления договорами,
управления документацией.
Операция 11 Периодически выполняются проверки проекта в целях определения действий, требуемых для приведения в соответствие хода и результатов разработки с текущими и планируемыми потребностями бизнеса, заказчика и конечных пользователей.
Примеры действий:
ужесточение календарного графика,
изменение системных требований в ответ на изменения рыночной ситуации или потребностей заказчика и конечных пользователей,
прекращение проекта.
В этих практиках термином «конечные пользователи» называются конечные пользователи, определенные заказчиком, либо их представители.
Измерения и анализ
Измерение 1. Выполнение измерений и использование их результатов для определения эффективности работ по интегрированному управлению разработкой ПО.
Примеры измерений:
объем выполненных на текущий момент работ по управлению проектом в сравнении с запланированным;
периодичность, причины и масштаб работ по перепланированию;
для каждого выявленного риска разработки — фактическая величина нежелательных последствий в сравнении с расчетной;
отслеживаемые во времени количество и масштаб наиболее существенных непредвиденных нежелательных воздействий на проект разработки.
Проверка внедрения
Проверка 1. Регулярная проверка высшим руководством выполнения работ по управлению проектом.
Практики, связанные со стандартным содержанием проверок со стороны высшего руководства, содержатся в описании Проверки № 1 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Проверка 2. Регулярные и событийные проверки менеджером проекта работ по управлению проектом.
Практики, связанные со стандартным содержанием проверок со стороны руководства проекта, содержатся в описании Проверки № 2 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».
Проверка 3. Выполнение группой обеспечения качества (SQA) проверок и/или аудитов работ и промежуточных продуктов по управлению проектом и составление отчетов по их результатам.
См. группу ключевых процессов «Обеспечение качества ПО».
Как минимум, проверяется следующее:
1. Процесс разработки и пересмотра производственного процесса проекта.
2. Процесс подготовки планов разработки ПО и управления рисками.
3. Процессы управления проектом в соответствии с его производственным процессом.
4. Процессы сбора и предоставления соответствующих данных для базы данных ППО.
5. Процесс использования базы данных ППО для поддержки работ по планированию, проведению оценочных расчетов и слежению за ходом проекта.
9.5. Инженерия разработки программного продукта
Группа ключевых процессов для уровня 3: определенный уровень
Цель группы ключевых процессов «Инженерия разработки программного продукта» заключается в последовательном выполнении четко определенного процесса, интегрирующего все операции разработки в целях рационального и эффективного создания качественных и надежных программных продуктов.
Инженерия разработки программного продукта включает в себя выполнение инженерных задач по созданию и сопровождению ПО с использованием производственного процесса проекта (описанного в группе ключевых процессов «Интегрированное управление разработкой ПО»), а также соответствующих методов и инструментов.
Задачи инженерии разработки ПО включают в себя анализ системных требований, отнесенных к ПО (эти требования описываются в группе ключевых процессов «Управление требованиями»), разработку требований к ПО, разработку его архитектуры, проектирование, реализацию кода программы, интегрирование компонентов ПО и его тестирование в целях проверки выполнения определенных требований (т. е. системных требований, отнесенных к ПО, и требований к ПО).
Разрабатывается и проверяется документация, необходимая для выполнения задач разработки (например, документ требований к ПО, документ архитектуры ПО, план и процедуры тестирования). Проверка документации должна подтвердить, что каждая задача использует результаты предшествующих задач, а их последовательное выполнение дает соответствующие результаты (включая задачи эксплуатации и сопровождения ПО). При внесении в проект утвержденных изменений, должны быть пересмотрены промежуточные программные продукты, планы, обязательства и процессы, на которые влияют эти изменения.
