3.4.2.5. Фаза «Внедрение»

Фаза внедрения является заключительной, ее главная веха называется «проект закончен». Эта веха характеризуется следующими основными признаками: разработанное решение используется заказчиком (пользователями) на практике; взаимоотношения с заказчиком урегулированы, результаты проекта документированы, измерены, архивированы и подго­товлены для повторного использования. Фаза опытной эксплуатации подобна фазе внедрения, но не является заключительной. Эти фазы различаются в части документов, описывающих удовлетворенность заказчика ре­зультатами проекта. В конце фазы внедрения все зафиксированные претензии и замечания заказчика удовлетворены. В конце фазы опытной эксплуатации претензии и замечания заказчика зафиксированы в форме протокола замечаний/разногласий. На фазе внедрения промежуточные вехи могут устанавливаться заказчиком. Типичными вехами фазы внедрения являются следующие:

• Приложение (решение) развернуто. Разработанное приложение (решение) уста­новлено у заказчика и проверена его работоспособность согласно программе и ме­тодике испытаний.

• База данных загружена. Эксплуатация решения ведется на реальных данных за­казчика.

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

3.4.3. Выбор архитектуры процесса.

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

Замечание по конструированию. Это обеспечивает итеративность разработки, необходимую для гарантии конечного успеха и, одновременно, предсказуемую завершаемость проекта, требуемую фиксированными вре­менными рамками, указанными в требованиях к процессу. Витки выполняются не последовательно, а частично накладываются друг на друга. Это обеспечивает сокращение общих сроков выполнения проекта (при некотором увеличе­нии трудозатрат, что допускается требованиями к процессу).

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

3.4.3.1. Типы проектов

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

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

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

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

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

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

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

• критерий новизны;

• критерий сложности;

• критерий времени.

Критерий новизны подразумевает проверку следующих условий:

• инструментальное программное обеспечение является новым (первый раз исполь­зуемым) для всех разработчиков;

• предметная область проекта является новой (не имеет прямых аналогов среди вы­полненных проектов);

• тип и/или масштаб приложения являются новыми (не имеют прямых аналогов сре­ди выполненных проектов).

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

Критерий сложности основан на подсчете количества принципиально различных специ­альных (инструментальных) средств, которые предполагается использовать в проекте. Что именно следует считать специальным средством, зависит от специфики проекта. Напри­мер, подготовку ТЗ в Word не следует считать случаем использования специального сред­ства, а написание сотни хранимых процедур для SQL сервера - следует. Если проект требует не более одного специального средства, то это сверх легкий проект, если 2-3, то легкий, если в проект вовлечено больше трех различных средств, то это тяже­лый или сверх тяжелый проект.

Критерий времени использует календарные сроки проекта для типизации проекта.

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

Сверх легкий проект имеет продолжительность до двух месяцев, легкий проект - до 6 ме­сяцев, тяжелый проект - до 9 месяцев и сверх тяжелый проект продолжается год или бо­лее.

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

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