3.4.4.7. Подготовка результирующих материалов вех

Состав материалов, которые готовятся на втором этапе в ходе работы над проектом и со­ставляют отчуждаемый результат проекта, существенно зависит от типа и объема проекта. Для типичного проекта разработки вертикального приложения на заказ возможный состав материалов кратко описан в разд. 3.4.3. Различаются внешние материалы проекта, кото­рые согласуются с заказчиком и/или входят в состав результатов проекта, предусмотрен­ных Техническим заданием, и внутренние материалы, которые заказчику не предоставля­ются.

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

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

Концепция

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

Замечание по конструированию. В ЕСПД Концепции соответствует Эскизный проект. Если организация склонна к использо­ванию терминологии ЕСПД, то документ "Концепция" можно называть "Эскизный проект", от этого суть и назначение документа не меняются.

Оценка риска

На этапе подготовки к проекту производится начальная оценка риска.

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

Замечание. Оценка риска является внутренней информацией, которая используется Руководителем про­екта и руководством при планирования процесса, выделении и перераспределении ресурсов. Как правило, оценка риска не предоставляется заказчику. Однако, в некоторых специальных случаях особых отношений с заказчиком оценка риска может включаться в ТЗ. Методика оценки риска является отдельной достаточно сложной процедурой, не включенной в данной описание процесса.

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

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

• календарный риск, который ставит под угрозу срок выполнения этапа или проекта в це­лом;

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

• бизнес-риск, как опасность того, что система не будет удовлетворять (частично или пол­ностью) экономическим требованиям и ожиданиям заказчика.

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

Замечание по конструированию. |Переоценка риска производится на каждой фазе для всех типов проектов, кроме сверх легкого.

Спецификации

Спецификации проекта являются основным результатом фазы анализа. Как правило, спе­цификации проекта состоят из нескольких материалов различного типа.

• Функциональные спецификации. Исчерпывающее и подробное описание функций ре­шения. Для описания функциональных спецификаций могут использоваться разнообраз­ные средства: естественный язык; специальные таблицы; формальные языки; компьютер­ные средства моделирования и др. Наиболее перспективным является применение средств моделирования, поддерживающих Unified Modeling Language (UML).

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

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

• Внутренний язык. Описание формального языка (внутреннего языка командного типа) рекомендуется для всех многофункциональных приложений, допускающих варьируемые сценарии использования. Для приложений, имеющих программный интерфейс (API), та­кое описание крайне желательно.

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

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

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

Замечание по конструированию. В некоторых случаях План тестирования не включается в Спецификации, а является первой промежуточной вехой фазы стабилизации.

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

Замечание по конструированию. В некоторых случаях План внедрения не включается в Спецификации, а является первой промежуточной вехой фазы внедрения (опытной эксплуатации)¹. Как правило, спецификации проекта (полностью или частично) являются внешними мате­риалами и в общем случае контролируются заказчиком.

В ЕСПД План внедрения и План тестирования оформляются как один документ с названием Программа и методика испытаний. Если организация склонна к использованию ЕСПД, то "План внедрения" можно называть "Программа и методика испытаний". План тестирования лучше иметь в виде отдельного документа.

Модель приложения

Для подготовки различных материалов фаз анализа, планирования и реализации целесо­образно использовать средства визуального моделирования, в особенности средства, под­держивающие UML. Средства моделирования UML ориентированы на представление раз­личных аспектов моделируемого приложения с помощью диаграмм различного типа. Именно поэтому диаграммы UМL могут служить в качестве результатов таких вех, как Спецификации, Логический проект, Физический проект и даже Код готов (если средства автоматической генерации кода это позволяют).

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

База данных тестирования

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

Пользовательская документация

В большинстве проектов на фазе внедрения составляется документ (или несколько доку­ментов) с названием «Руководство пользователя».