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