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

Цели

Цель 1. Определение, интеграция и последовательное выполнение задач разработки ПО.

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

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

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

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

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

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

2. Для создания и сопровождения программных продуктов используются соответствующие методы и инструменты.

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

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

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

Предпосылка 1. Выполнение задач разработки ПО должно быть обеспечено соответствующими ресурсами и финансированием.

1. Задачи разработки должны выполняться квалифицированными сотрудниками.

В число задач входят:

анализ требований к ПО,

проектирование архитектуры ПО,

составление кода,

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

поддержка ПО.

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

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

рабочие станции,

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

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

графические инструменты,

средства создания интерактивной документации,

текстовые процессоры.

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

инструменты для отслеживания требований,

инструменты для создания спецификаций,

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

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

средства эмулирования.

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

инструменты для создания спецификаций,

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

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

языки описания архитектуры.

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

редакторы,

компиляторы,

генераторы перекрестных ссылок,

средства печати.

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

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

генераторы тестов,

тестовые драйверы,

тестовые профайлеры,

символьные отладчики,

анализаторы тестового покрытия.

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

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

Примеры обучения для выполнения анализа требований к ПО:

принципы анализа требований к ПО;

существующие требования к имеющемуся и поддерживаемому ПО;

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

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

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

концепции разработки архитектуры;

существующая архитектура имеющегося и поддерживаемого ПО;

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

Примеры обучения для выполнения кодирования:

применяемые языки программирования;

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

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

Примеры обучения тестированию ПО и другим методам контроля:

методы контроля (анализ, демонстрация, проверка, тестирование);

планирование тестов;

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

критерии готовности и завершения тестов;

измерение тестового покрытия.

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

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

Примеры областей, связанных с разработкой ПО:

анализ требований к ПО,

проектирование архитектуры ПО,

составление кода,

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

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

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

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

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

Примеры ориентации:

инструменты и методы разработки ПО,

предметная область,

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

инструкции по управлению проектом с использованием выбранных методов и инструментов.

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

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

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

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

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

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

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

Документируются обоснования выбора конкретного инструмента или метода.

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

Примеры моделей управления конфигурацией:

модели внесения/извлечения данных,

композиционные модели,

транзакционные модели,

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

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

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

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

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

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

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

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

функциональная декомпозиция,

объектно-ориентированная декомпозиция,

изучение альтернатив,

имитация,

моделирование,

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

разработка сценариев.

3. Документируются результаты анализа требований и обоснования выбранного варианта.

4. Требования к ПО анализируются на реализуемость, понятность, непротиворечивость, возможность тестирования и полноту (если имеется в виду набор требований).

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

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

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

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