Конструирование процессов. Стандарт IEEE 1074

В отличие от рассмотренных выше ГОСТ Р ИСО/МЭК 15271 и ГОСТ Р ИСО/МЭК 16326 документ IEEE 1074-1997, который называется "Стандарт IEEE для построения процессов жизненного цикла программного обеспечения", имеет отчетливую практическую направленность и дает специалистам-практикам работающий инструмент для построения процессов жизненного цикла в конкретном проекте разработки программного обеспечения (IEEE 1074, 1997).

Созданный в 1997 г., этот стандарт допускал совместное использование со стандартом IEEE/EIA 12207.0-1996 - прообразом ISO IEC 12207 (и, соответственно, ГОСТ Р ИСО/МЭК 12207-99), но не опирался на него и не предполагал его обязательного применения. Поэтому конструирование процессов жизненного цикла проекта в ISO 1074 не представляет собой адаптации ISO 12207, в ходе которой из реализованного в организации стандарта "выкраиваются" процессы проекта. Вместо этого ISO 1074 содержит собственные "заготовки" процессов (названные активностями) и правила конструирования процессов проекта из активностей. Работы и задачи ISO IEC 12207 можно использовать наравне с собственными активностями IEEE 1074 (а можно и не использовать).

Активности разбиты на пять наборов, в каждый набор входят группы активностей:

• первый набор - группы активностей по управлению проектами;
• второй набор - группы активностей, предшествующих разработке;
• третий набор - группы активностей по разработке;
• четвертый набор - группы активностей, выполняющихся по окончании разработки;
• пятый набор - группы общих^{1англ. integral} активностей.

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

Фундаментальное значение имеют следующие понятия, приведенные в стандарте:

• жизненный цикл ПО^{2ПО - программное обеспечение} (Software LifeCycle, SLC) - конкретная последовательность активностей, полученная в результате отображения активностей стандарта на модель жизненного цикла;
• модель жизненного цикла (Software LifeCycle Model, SLCM) - внешняя по отношению к стандарту модель, описывающая модель жизненного цикла и связанные с ней атрибуты, такие, например, как форматы проектных документов;
• процесс жизненного цикла (Software LifeCycle Process, SLCP) - описание конкретного процесса в проекте, базирующееся на SLC и процессных активах организации;
• процессный актив организации (Organizational Process Asset, OPA) - артефакт, определяющий часть окружения проекта по разработке ПО в организации. Это могут быть специфические требования, нормативные документы, ограничения и т. п.

Стандарт предназначен для использования архитекторами процессов - людьми или группами людей, ответственными за построение SLCP.

Схема построения SLCP представлена на рис. 5.1.

увеличить изображение
Рис. 5.1. Разработка SLCP

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

Отображение активностей, в результате которого получается SLC, подчиняется следующим правилам.

Каждая активность выбирается из перечня, предложенного стандартом, и помещается в SLC (это и есть отображение). Для помещения активности в SLC должны уже существовать ее входы; активность преобразовывает их в выходы.

Некоторые активности помещаются в SLC один-единственный раз, в результате возникает экземпляр^{3англ. instance} активности. Экземпляры полностью преобразуют все имеющиеся входы в выходы. К таким активностям относится, например, А.1.1.3 - "Распределить ресурсы проекта".

Некоторые активности помещаются в SLC несколько раз, в результате возникает повторение^{4англ. iteration} активности. Повторения перерабатывают подмножества входов в подмножества выходов. К таким активностям относится, например, А.1.3.2 - "Управлять проектом". У нее 22 входа, которые возникают последовательно, и активность преобразует их в выходы по мере их возникновения.

Наконец, существуют группа активностей, которые вызываются^{5англ. invoked} из других активностей, причем вызываемые активности могут выполняться параллельно. Примером служит активность А.1.2.7 "Спланировать управление проектом". Одним из выходов этой активности является совокупность проектных планов (Software Project Management Planned Information, SPMPI). Перед тем как объявить SPMPI своим выходом и сделать ее доступной другим активностям, активность А.1.2.7 вызывает параллельно три активности: А.5.1.1 "Провести обсуждения", А.5.2.2 "Выполнить контроль конфигурации", А.5.3.1 "Подготовить документацию". Результаты выполнения этих активностей возвращаются в А.1.2.7.

Последовательность выполнения активностей определяется тремя факторами:

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

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

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

Набор А.1 "Группы активностей по управлению проектом". Группа активностей А.1.2 "Активности по планированию проекта". Активность А.1.2.8 "Спланировать интеграцию".

Описание

При выполнении активности "Спланировать интеграцию" необходимо определить порядок включения (интеграции) компонентов в систему. Для этого анализируются требования к ПО и детальный проект системы. Кроме этого, необходимо рассмотреть SLCP, определенный в SPMPI. Методы интеграции должны быть зафиксированы в выходе активности - плане интеграции. План интеграции должен быть скоординирован с планом тестирования.

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

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

• А.5.1.1 "Провести обсуждения";
• А.5.2.2 "Выполнить контроль конфигурации";
• А.5.3.1 "Подготовить документацию".

Как видно из приведенного описания, стандарт очень конкретен и предназначен для непосредственного практического использования. Он проще в применении, чем рассмотренный выше ГОСТ Р ИСО/МЭК 12207, и не требует большой предварительной организационной работы, поскольку не распространяется за пределы проекта. Он выгодно отличается от ГОСТ Р ИСО/МЭК 12207 наличием готовых практических инструментов (они составляют Приложение С), не требует почти никаких специальных знаний и не ориентирован ни на какую конкретную технологию разработки. Немаловажно и то, что документ очень компактен (без Приложений всего 11 страниц) и хорошо структурирован. Тем не менее идеи, использованные в IEEE 1074, не получили продолжения в более поздних стандартах. "Алгоритмический" подход к построению процесса, который можно считать "ноу-хау" стандарта IEEE 1074, оказался невостребованным: методы построения процессов из отдельных активностей теперь полностью отданы на усмотрение пользователей стандартов.

Краткие итоги

Описан стандарт IEEE 1074, демонстрирующий нетрадиционный подход к построению процессов жизненного цикла программного обеспечения, отличный от подхода ГОСТ Р ИСО/МЭК 12207. Подчеркиваются простота и практическая направленность стандарта.

Вопросы

1. В чем состоит назначение стандарта IEEE 1074?
2. Какие наборы активностей содержит IEEE 1074?
3. В чем принципиальная разница между IEEE 1074 и ГОСТ Р ИСО/МЭК 12207?
4. Что такое "модель жизненного цикла" и какова ее роль в IEEE 1074?