Конструирование процессов. Стандарт 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 (а можно и не использовать).

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

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

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

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

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

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

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

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

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

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

Наконец, существуют группа активностей, которые вызываютсяангл. 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.

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

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

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

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

Описание

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

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

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

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

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

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

Вопросы