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

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

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

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

---

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

3. План доступен для членов всех инженерных групп.

4. При обновлении плана учитываются все межгрупповые обязательства и изменения этих обязательств.

5. План обновляется по мере выполнения работ, отражая ход проекта и изменения его планов; в частности при завершении основных этапов проекта или значительных изменениях планов.

6. План рассматривается и утверждается всеми инженерными группами и менеджером проекта.

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

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

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

1. Каждая критическая зависимость должна быть явно определена, включая следующее:

что должно быть подготовлено,

кто должен это подготовить,

когда это должно быть подготовлено,

критерии приемки.

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

3. Даты потребности и доступности объектов критической зависимости связываются с календарными графиками проекта и процесса разработки.

4. Соглашение по каждой критической зависимости документируется, проверяется и утверждается как получающей группой, так и группой, ответственной за подготовку объекта критической зависимости.

5. Критические зависимости регулярно отслеживаются и в случае необходимости по отношению к ним применяются корректирующие действия.

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

Оценивается влияние позднего и досрочного выполнения обязательств на будущие работы и этапы.

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

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

Операция 6. Межгрупповые проблемы, не решаемые отдельными представителями инженерных групп проекта, рассматриваются в соответствии с документированной процедурой.

Примеры межгрупповых проблем:

несовместимые календарные графики,

неадекватное финансирование,

технические риски,

дефекты системной архитектуры и требований,

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

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

Участники этих проверок и совещаний решают следующие задачи:

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

2. Проверка хода технических работ проекта.

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

4. Проверка выполнения обязательств.

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

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

Операции № 10 группы ключевых процессов «Интегрированное управление разработкой ПО».

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

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

Примеры фактических измерений:

объем трудозатрат и других ресурсов, израсходованных разработчиками на поддержку других инженерных групп;

объем трудозатрат и других ресурсов, израсходованных другими инженерными группами на поддержку группы разработки ПО;

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

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

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

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

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

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

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

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

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

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

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

2. Управление межгрупповыми проблемами.

9.7. Экспертные оценки

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

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

Экспертные оценки включают в себя систематическое изучение промежуточных программных продуктов, проводимое экспертами-разработчиками в целях выявления дефектов и областей, в которые следует внести изменения. Конкретные продукты, подлежащие экспертной оценке, определяются в документе производственного процесса проекта, а их оценка планируется в составе мероприятий по планированию проекта разработки, как это описано в группе ключевых процессов «Интегрированное управление разработкой ПО».

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

Цели

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

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

Обязательства по выполнению

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

Эта политика обычно состоит из следующих положений:

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

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

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

Примеры промежуточных программных продуктов:

системное ПО и вспомогательные программы,

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

программные (например, код) и непрограммные промежуточные продукты (например, документы),

описания процессов.

3. Экспертные оценки проводятся под руководством ведущих экспертов, опытных в их проведении.

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

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

Необходимые предпосылки

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