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

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

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

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

---

Проблемы, связанные с требованиями к ПО, выявляются и рассматриваются группой, ответственной за системные требования. Соответствующие изменения вносятся как в установленные требования, так и в требования к ПО.

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

5. Требования к ПО документируются.

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

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

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

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

9. Документ требований к ПО рассматривается и утверждается.

Примеры сотрудников, рассматривающих и утверждающих документ требований к ПО:

менеджер проекта,

менеджер по системному проектированию,

производственный менеджер проекта,

менеджер по тестированию ПО.

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

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

11. Документ требований к ПО помещается в систему управления конфигурацией.

См. группу ключевых процессов «Управление конфигурацией ПО». 12. При любом изменении установленных требований соответствующие изменения вносятся и в требования к ПО. См. группу ключевых процессов «Управление требованиями».

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

Архитектура ПО состоит из системной архитектуры и архитектуры программы.

1. Создание и проверка критериев разработки архитектуры ПО.

Примеры критериев разработки архитектуры ПО:

возможность проверки,

соблюдение стандартов для архитектуры ПО,

удобство реализации,

простота,

удобство планирования реализации.

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

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

Примеры стандартов разработки приложений:

стандарты интерфейсов операционной системы,

стандарты пользовательских интерфейсов,

стандарты сетевых интерфейсов.

4. Для проектирования архитектуры ПО используются эффективные методы.

Примеры методов проектирования архитектуры ПО:

создание прототипов,

структурные модели,

повторное использование элементов архитектуры,

объектно-ориентированное проектирование,

системный анализ.

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

Системная архитектура описывает программную структуру верхнего уровня с четко определенными внутренними и внешними интерфейсами.

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

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

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

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

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

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

10. Документ, описывающий архитектуру ПО, помещается в систему управления конфигурацией.

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

11. При любом изменении требований к ПО соответствующие изменения вносятся и в описание архитектуры ПО.

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

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

2. Для создания кода используются эффективные методы программирования. Примеры методов программирования: структурированное программирование, повторное использование кода.

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

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

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

5. Программный код помещается в систему управления конфигурацией.

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

6. При любом изменении требований к ПО или архитектуры ПО соответствующие изменения вносятся и в программный код.

Операция 5. Тестирование ПО выполняется в соответствии с производственным процессом проекта.

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

2. Тестирование ПО осуществляется с помощью эффективных методов.

3. Адекватность тестирования определяется следующими факторами:

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

Примеры уровней тестирования:

модульное тестирование,

интеграционное тестирование,

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

приемочное тестирование.

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

Примеры стратегий тестирования:

функциональная («черный ящик»),

структурная («прозрачный ящик»),

статистическая.

достигаемое тестовое покрытие,

Примеры тестового покрытия:

покрытие операторов,

покрытие путей,

покрытие ветвей,

профиль использования.

4. Для каждого уровня тестирования ПО устанавливаются и используются критерии готовности к тестированию.

Примеры критериев, определяющих готовность к тестированию:

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

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

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

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

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

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

«Управляемый и контролируемый» означает, что в любой момент времени (прошлый или настоящий) известна версия используемого промежуточного продукта, а внесение изменений происходит управляемым образом. Если желательно реализовать еще большую степень формальности, промежуточный продукт может быть помещен в условия полномасштабного управления конфигурацией, как это описано в группе ключевых процессов «Управление конфигурацией ПО».

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

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

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

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