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

системного проектирования,

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

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

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

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

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

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

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

Эта сфера ответственности включает в себя следующее:

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

2. Влияние на изменения системных требований и их отнесение к элементам проекта.

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

К установленным требованиям относятся следующие:

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

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

2. Технические требования к ПО. Примеры технических требований:

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

3. Критерии приемки, по которым будет оценено соответствие программных продуктов установленным требованиям.

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

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

2. Действия по управлению требованиями должны быть обеспечены вспомогательными инструментальными средствами.

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

электронные таблицы,

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

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

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

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

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

используемые в проекте методы, стандарты и процедуры;

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

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

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

1. Выявляются пропущенные пункты требований.

2. Выполняется проверка установленных требований на:

выполнимость и возможность реализации в виде программы,

четкость и корректность формулировки,

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

возможность тестирования.

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

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

Примеры групп, задействованных в проекте:

разработки ПО (включая все подгруппы, например, проектирования ПО),

оценки составляющих проекта,

системного проектирования,

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

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

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

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

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

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

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

Установленные требования:

1. являются управляемыми и контролируемыми;

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

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

2. являются основой для создания плана разработки ПО;

3. являются основой для разработки требований к ПО.

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

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

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

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