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

Задачи

Фаза должна привести к достижению следующих целей:

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

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

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

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

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

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

Требования к документации

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

Перечень документов создаваемых на этапе разработке и внедрения автоматизированной системы

• Отчет о проделанной работе и/или о ходе выполнения проекта
• Концептуальная разработка / прототип
• Описание разработки
• Сметно-финансовые расчеты
• Журнал регистрации проблем
• План-график проекта
• Предупреждения о рисках
• Технические требования
• План-график испытаний
• План-график обучения

Описание документов

Отчет о проделанной работе или о ходе выполнения проекта

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

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

Концептуальная разработка / прототип

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

Описание разработки

Описание разработки служит руководством для построения решения. Изменения в разработке можно определить как этапы продвижения на пути к построению. Они фиксируются в документе в рамках процесса контроля изменений. Изменения, влияющие на затраты и/или сроки проекта, должны рассматриваться и утверждаться клиентом до их осуществления.

Сметно-финансовые расчеты

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

Журнал регистрации ошибок

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

План-график проекта

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

Предупреждения о риске

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

Технические требования

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

План-график испытаний

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

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

График испытаний обычно более подробен, чем план, и расписывает по дням все действия по выполнению и оценке испытаний.

План-график обучения

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