■ Согласование ожиданий заинтересованных сторон и трех составляющих проекта: требований, проектных решений и планов.

■ Приведение взаимосвязанных рабочих продуктов в непротиворечивое и сбалансированное состояние.

■ Выявление важных рисков, проблем и невыполнимых условий.

■ Выполнение глобальной оценки всего жизненного цикла, а не только какого-либо промежуточного продукта или текущей ситуации в какой-то одной перспективе.

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

В процессе руководства проектом проводятся совместные оценки трех разных типов:.

1.

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

2.

Второстепенные контрольные точки. Эти мероприятия, в фокусе внимания которых находятся итерации, проводятся для детальной проверки содержания итерации и для санкционирования дальнейшей работы.

.

3.

Оценки состояния. Эти периодические мероприятия позволяют руководству регулярно вникать в суть достигнутых успехов.

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

Уровень мероприятия и количество контрольных точек меняется в зависимости от таких параметров, как масштаб, количество заинтересованных сторон, состояние бизнеса, технический риск и чувствительность проекта к изменениям затрат и сроков. Для большинства проектов нужно установить все четыре основные контрольные точки. Только в исключительных случаях следует добавлять другие основные контрольные точки или оперировать меньшим их числом. (Для проекта государственной важности, привлекающего широкое внимание, их число можно увеличить; в случае научного эксперимента для внутреннего использования их может быть меньше.) В более простых проектах для контроля за промежуточными результатами может понадобиться меньшее число второстепенных контрольных точек или они не потребуются вовсе, а периодичность оценок состояния может быть небольшой (например, ежеквартальной). На рис. 9.1 показана типичная последовательность контрольных точек для сравнительно большого проекта.

Описания этого раздела напоминают подход с «якорными» точками жизненного цикла, рассмотренный в статье «Anchoring the Software Process» [Boehm, 1996]. Четыре основные контрольные точки располагаются в точках перехода между стадиями жизненного цикла. Они могут использоваться в самых разнообразных моделях процесса, включая традиционную водопадную модель. В итерационной модели основные

Рис. 9.1. Типичная последовательность контрольных точек на протяжении всего жизненного цикла.

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

■ Заказчики: оценки сроков и бюджета, осуществимость, оценка рисков, понимание требований, прогресс, совместимость продуктов одной линии.

■ Пользователи: непротиворечивость требований и сценариев использования, потенциальная адаптируемость, характеристики качества.

■ Архитекторы и системотехники: совместимость продуктов одной линии, изменение требований, анализ согласований, завершенность и непротиворечивость, баланс между риском, качеством и применимостью.

■ Разработчики: детальность требований и описаний сценариев использования, основа для выбора или разработки компонентов, разрешение рисков при разработке, достаточность среды разработки.

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

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

Контрольные точки, описываемые в этом разделе, могут проводиться как единая постоянно действующая конференция всех заинтересованных сторон либо в виде последовательных рассмотрений различных рабочих продуктов преимущественно в онлайновом режиме. Имеются существенные различия в уровне формальности этих мероприятий, что зависит от некоторых факторов, обсуждаемых в главе 14. Смыслом каждой основной контрольной точки является подтверждение непротиворечивости различных рабочих продуктов, а также получение гарантий того, что понимание требований, планы, касающиеся всего жизненного цикла, форма, функции и качество продукта развиваются на сбалансированных уровнях детализации. Распределение информации м^жду основными контрольными точками представлено в таблице 9.1.

Таблица 9.1.

Общее состояние планов, требований и продуктов при достижении основных контрольных точек

Таблица 9.1. (продолжение).

Общее состояние планов, требований и продуктов при достижении основных контрольных точек

Контрольная точка жизненного цикла по целям.

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

Контрольная точка жизненного цикла по архитектуре.

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

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

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

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

■ Структура рисков вполне понятна. Хотя полного разрешения всех рисков и не требуется, должно быть достигнуто понимание всеми заинтересованными сторонами наиболее значительных рисков, которые могут иметь серьезные последствия, при этом должны быть полностью проработаны планы их снижения.

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

Содержание этой контрольной точки может меняться в зависимости от предметной области проекта. Как минимум в нее будет входить следующее:.

■ Представление и обзор текущего состояния проекта.

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

■ Демонстрация возможностей.

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

Контрольная точка по начальной эксплуатационной версии.

Контрольная точка по начальной эксплуатационной версии находится в конце стадии конструирования. Ее цель — оценка готовности ПО к передаче его в эксплуатацию заказчику/пользователю и санкционирование начала приемочного тестирования. Обсуждаются проблемы, касающиеся инструкций по инсталляции, описаний версий ПО, руководств пользователя и оператора, а также возможности организации-разработчика осуществлять сопровождение продукта у пользователя. Рассматриваются характеристики качества ПО для определения его достаточности. Оценивается готовность тестовой среды и тестового ПО к приемочному тестированию. Приемочное тестирование может проводиться по нарастающей на протяжении многих итераций либо может быть выполнено полностью в течение стадии внедрения. Начало стадии внедрения необязательно должно являться завершением стадии конструирования. Эти стадии обычно перекрывают друг друга до тех пор, пока первоначальный продукт не будет передан пользователю для самостоятельной работы.

Контрольная точка по выпуску версии продукта.

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

Рис. 9.3. Стандартные программы для контрольной точки жизненного цикла по архитектуре.

.

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