Марк Паулк - Модель зрелости процессов разработки программного обеспечения

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

5. Документация подвергается экспертной оценке. См. группу ключевых процессов «Экспертные оценки».

6. Документация должна быть управляемой и контролируемой.

7. Окончательная документация рассматривается и утверждается заказчиком, конечными пользователями, и при необходимости, специалистами по поддержке ПО.

Операция 9. Сбор и анализ данных по дефектам, выявленным при экспертной оценке и тестировании, выполняются в соответствии с производственным процессом проекта.

Примеры собираемых и анализируемых данных:

описание дефекта,

категория дефекта,

серьезность дефекта,

модули, содержащие дефект,

модули, подверженные влиянию дефекта,

операция, в которой проявился дефект,

экспертная оценка или тестовые сценарии, выявившие дефект,

описание сценария, при выполнении которого был выявлен дефект,

ожидаемые и фактические результаты, выявляющие дефект.

Операция 10. Поддержка согласованности всех промежуточных программных продуктов, включая планы разработки ПО, описания процессов, установленные требования, требования к ПО, архитектуру ПО, планы и процедуры тестирования.

1. Промежуточные программные продукты документируются, а к созданной документации имеется постоянный доступ.

2. Требования к ПО, архитектура ПО, программный код и тестовые сценарии отслеживаются от источника их происхождения до продуктов последующих операций разработки ПО.

3. Документация, отслеживающая установленные требования до требований к ПО, архитектуры, кода и тестовых сценариев, должна быть управляемой и контролируемой.

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

Влияние изменений на ход проекта определяется до того, как эти изменения будут реализованы.

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

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

Задействованные группы информируются об изменениях и участвуют в их обсуждении.

Примеры групп, задействованных в проекте:

группа разработки ПО,

оценки составляющих проекта,

системного тестирования,

обеспечения качества ПО,

управления конфигурацией ПО,

управления договорами,

управления документацией.

Изменения отслеживаются до своей реализации.

Измерение 1. Выполнение измерений и использование их результатов для определения функциональных возможностей и качества программных продуктов.

Примеры измерений:

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

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

Измерение 2. Выполнение измерений и использование их результатов для определения статуса операций по инженерии разработки программного продукта.

Примеры измерений:

статус каждого установленного требования в течение всего проекта;

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

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

объем внесенных изменений и затраты на их реализацию и тестирование, включая начальную оценку и фактические показатели объема и затрат.

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

Практики, связанные со стандартным содержанием проверок со стороны высшего руководства, содержатся в описании Проверки № 1 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».

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

Практики, связанные со стандартным содержанием проверок со стороны руководства проекта, содержатся в описании Проверки № 2 группы ключевых процессов «Отслеживание хода проекта и контроль над ним».

Проверка 3. Проведение группой обеспечения качества проверок и/или аудитов работ и промежуточных продуктов, связанных с инженерией разработки программного продукта, и выполнение отчетов по их результатам.

См. группу ключевых процессов «Обеспечение качества ПО».

Минимальное содержание этих проверок и/или аудитов:

1. Проверка следующих качеств требований к ПО:

полнота,

корректность,

непротиворечивость,

осуществимость,

возможность тестирования.

2. Выполнение критериев готовности и завершения для каждой задачи разработки ПО.

3. Соответствие программных продуктов указанным для них стандартам и требованиям.

4. Выполнение требуемого тестирования.

5. Выполнение системного и приемочного тестирования ПО в соответствии с документированными планами и процедурами.

6. Соответствие результатов тестирования приемочным критериям согласно документу плана тестирования ПО.

7. Успешное выполнение тестов и запись их результатов.

8. Документирование, отслеживание и принятие мер по устранению обнаруженных проблем и недостатков.

9. Отслеживание установленных требований до требований к ПО, архитектуры, кода и тестовых сценариев.

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

Группа ключевых процессов для уровня 3: определенный уровень

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

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