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

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

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

Я публикую книгу на своем сайте в открытом доступе для того, чтобы все интересующиеся данным вопросом могли прочитать ее и получить необходимую информацию совершенно свободно и бесплатно. Причина в том, что те методики, которые описаны в данном стандарте, как я считаю, просто обязаны взять на вооружение те разработчики ПО, которые этим занимаются серьёзно. По крайней мере, это касается 2-го и 3-го уровней CMM, так как применение этих практик дает существенное повышение в производительности и устойчивости процесса разработки ПО.

---

Ресурсы и финансирование предоставляются для выполнения следующих операций:

1. Подготовка и распространение материалов экспертной оценки.

2. Руководство проведением экспертной оценки.

3. Рассмотрение материалов.

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

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

6. Сбор сведений и составление отчетов по результатам экспертных оценок.

Предпосылка 2. Ведущие эксперты должны пройти необходимое обучение руководству экспертными оценками.

Примеры тем учебных занятий:

цели, принципы и методы экспертных оценок;

планирование и организация экспертной оценки;

критерии готовности к экспертной оценке и ее завершения;

проведение экспертной оценки;

отчетность по результатам экспертной оценки;

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

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

Предпосылка 3 Участники экспертных оценок должны пройти необходимое обучение целям, принципам и методам экспертных оценок.

Примеры тем учебных занятий:

типы экспертных оценок (например, проверки требований к ПО, архитектуры ПО, кода и процедур тестирования ПО);

цели, принципы и методы экспертных оценок;

роли экспертов; определение трудоемкости подготовки и проведения экспертных оценок.

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

Выполняемые операции

Операция 1. Экспертные оценки проводятся на плановой основе, а планы документируются.

Эти планы определяют:

1. Промежуточные программные продукты, подлежащие экспертной оценке.

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

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

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

Операция 2. Проведение экспертных оценок в соответствии с документированной процедурой.

Эта процедура обычно определяет следующее:

1. Экспертные оценки планируются обученными ведущими экспертами и проводятся под их руководством.

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

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

Примеры соответствующей исходной информации:

цели промежуточного программного продукта,

применяемые стандарты,

соответствующие требования к архитектурному модулю,

детальная архитектура модуля программного кода.

3. Участникам экспертной оценки назначаются роли.

4. Определяются критерии готовности к экспертным оценкам и их завершения, подлежащие строгому соблюдению.

Вопросы, связанные с несоответствием этим критериям, докладываются соответствующим менеджерам.

5. Для единообразной идентификации критериев конкретной оценки используются контрольные списки.

Контрольные списки адаптируются к конкретному типу промежуточного продукта и экспертной оценки.

Примеры адаптируемых пунктов контрольных списков:

соответствие стандартам и процедурам,

полнота,

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

правила построения,

возможности поддержки.

Контрольные списки рассматриваются коллегами их автора и потенциальными пользователями.

6. Действия, определенные в ходе экспертной оценки, отслеживаются до своего выполнения.

7. Успешное завершение экспертных оценок, включая доработку выявленных недостатков, используется в качестве критерия завершения для соответствующей задачи.

Операция 3. Запись данных о ходе и результатах экспертных оценок.

Примеры данных:

идентификация проверенного промежуточного программного продукта,

объем промежуточного программного продукта,

размер и состав группы экспертов,

время, выделенное каждому эксперту на подготовку к оценке,

продолжительность совещания по экспертной оценке,

типы и количество обнаруженных и устраненных дефектов,

трудоемкость доработки.

Измерения и анализ

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

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

количество выполненных экспертных оценок в сравнении с планом,

общая трудоемкость выполненных экспертных оценок в сравнении с планом,

количество проверенных промежуточных продуктов в сравнении с планом.

Проверка внедрения

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

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

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

1. Проведение запланированных экспертных оценок.

2. Адекватное обучение ведущих экспертов для выполнения их ролей.

3. Полученное обучение или наличие опыта в выполнении своих ролей у экспертов.

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

5. Своевременная подача полных и точных отчетов по результатам экспертных оценок.

ПРИЛОЖЕНИЕ

ЦЕЛИ КАЖДОЙ ГРУППЫ КЛЮЧЕВЫХ ПРОЦЕССОВ

Ниже перечислены цели всех групп ключевых процессов по уровням зрелости.

1. Группы ключевых процессов для уровня 2: повторяемый уровень Управление требованиями

Цель 1. Установление контроля над системными требованиями к ПО в целях формирования базовой линии, используемой разработчиками ПО и руководством проекта.

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

Планирование проекта

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

Цель 2. Планирование и документирование работ и обязательств по проекту разработки.

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

Отслеживание хода проекта и контроль над ним

Цель 1. Сравнение фактических результатов и показателей с запланированными.

Цель 2. В случае значительного отклонения фактических результатов и показателей от запланированных — применение корректирующих действий и контроль над их выполнением.

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

Управление производственным субподрядом

Цель 1. Выбор генеральным подрядчиком квалифицированных субподрядчиков.

Цель 2. Заключение соглашения о взаимных обязательствах между генеральным подрядчиком и субподрядчиком.

Цель 3. Поддержка постоянного обмена информацией между генеральным подрядчиком и субподрядчиком.

Цель 4. Отслеживание генеральным подрядчиком фактических результатов работы и производительности субподрядчика относительно принятых им обязательств.

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

Цель 1. Планирование работ по обеспечению качества ПО.

Цель 2. Объективная проверка соответствия программных продуктов и технологических операций применяемым стандартам, процедурам и требованиям.

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

Цель 4. Передача на рассмотрение высшему руководству вопросов несоответствия, не решаемых на уровне проекта.

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

Цель 1. Управление конфигурацией ПО происходит на плановой основе.