Модели жизненного цикла программного обеспечения (стр. 9 )

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

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

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

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

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

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

  реализацию можно осуществить быстро;

  получаемые результаты можно продемонстрировать наглядно и убедительно.

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

На рис. 16 представлена еще одна модификация гантеровской модели жизненного цикла, отражающая развитие работ на первой итерации методом «Сначала в глубину». Модель модифицирована в следующих отношениях.

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

  На общей части этапов анализа и конструирования (контрольные точки 2, 3) выделяется явно работа по определению и утверждению базового набора требований и сценариев для реализации (группа сценариев обозначена овалом с внутренними незакрашенными кружками). Таким образом, появляется контрольная точка 2'6

  Этапы анализа и конструирования для выбранных сценариев выпол-няются совместно (жирная стрелка между овалами). В результате строятся модели сценариев (контрольная точка 3?, модели обозначены закрашенными кружками), которые рассматриваются в качестве исходных данных для спецификации реализуемых компонентов (контрольная точка 5).

Рис. 16. Фазовое измерение модели жизненного цикла при объектно-ориентированном развитии проекта методом «Сначала в глубину»

  Для каждого из сценариев образуется мини-цикл его разработки. Разработка мини-циклов включает в себя перекрывающиеся этапы автономной работы и интеграции сценариев (контрольные точки 3?, 5?? и 5?, 7).

  Фиксируется событие готовности результатов всех мини-цик­лов (контрольная точка 5??), которое означает завершение формирования базового набора требований.

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

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

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

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

Из приведенной модели видно, что метод «Сначала в глубину» дает вполне приемлемое представление о том, как происходит объектно-ориенти­рованное проектирование. Разработчики могут рассматривать мини-циклы в качестве прототипа итеративного наращивания, а поскольку каждый из мини-циклов обозрим, к концу первой итерации достигается решение задачи, о которой шла речь выше: доказательство того, что данная команда, используя данный метод в конкретных условиях, в дальнейшем приведет проект к успешным результатам.

3.5. Фаза завершения

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

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

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