Лекция 9: Моделирование объектно-ориентированного жизненного цикла программных проектов

3. Требования к очередной итерации утверждены.

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

4. Спецификации реализуемых сценариев составлены.

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

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

5. Спецификации утверждены.

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

6. Автономная проверка завершена и комплексное тестирование началось.

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

Часто говорят, что для проектов, разрабатываемых по методикам быстрого развития, нет нужды выделять этап конструирования (см., например, [3]). Как следствие, контрольные точки 3, 4 и 5 сливаются. Все, что надо сделать в проекте в связи с требованиями к очередной итерации, приурочивается к контрольной точке 6. К тому же в этом подходе не разделяются автономная и комплексная проверка результатов, поскольку каждая новая возможность системы с самого начала интегрируется с уже реализованными возможностями. Как следствие, автономная разработка остается лишь на уровне продумывания того, каким образом встроить новую возможность в складывающийся архитектурный каркас.

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

7. Тестирование завершилось, начата подготовка новой итерации.

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

• выделение общих лишь для данного проекта переиспользуемых компонентов (его целесообразно выполнить до расщепления жизненного цикла — контрольная точка 9);
• выделение общих, не привязанных к проекту переиспользуемых компонентов (целесообразно начинать эти работы, когда программный рабочий продукт итерации рассматривается как готовое приложение, — контрольная точка 9, и завершать к моменту передачи системы на распространение — контрольная точка 10).

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

8. Требования к новой итерации приняты.

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

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

9. Начато использование изделия.

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

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

Традиционные работы фазы завершения включают в себя:

• поставку или пакетирование изделия для потребителя ( контрольная точка 9);
• сопровождение программного продукта (по причине разнообразия вариантов организации этих работ они редко описываются структурно, т.е. с разбиением на этапы);
• этап окончания работ (см. ниже — контрольные точки 11, 12).

10. Изделие или его версия переданы на распространение.

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

11. Извещение о прекращении поддержки изделия (версии) выпущено.

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

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

12. Изделие (версия) снято с производства.

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

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

Одним из существенных моментов адаптивных методологий, который учитывается и при обычном объектно-ориентированном проектировании, является отказ от традиционного постулата о том, что все требования к системе сформулированы заранее. Как указывает М. Фаулер [24], предсказать направление целесообразного развития программного проекта чаще всего невозможно, а потому следует строить адаптивные процессы разработки, что применительно к моделированию жизненного цикла вообще и его фазы завершения в частности означает необходимость учета обработки потока внешних требований на всех этапах. Этому вопросу еще будет уделено внимание, а пока можно считать (как чаще всего и бывает), что требования, поступающие на фазе завершения итерации, рассматриваются как относящиеся к следующим итерациям, т.е. к следующим версиям системы. В таком случае завершение итерации означает сопровождение программного изделия, а затем — окончание работы с данной версией. Пожелания к развитию проекта в этот период учитываются как требования к последующим (возможно, еще не начатым) итерациям. Окончание проекта рассматривается как отказ от сопровождения всех версий системы. Поучительно сопоставить это положение с традиционными подходами к проектированию, когда учет пожеланий к системе в процессе ее эксплуатации чаще всего означает одно: организацию нового проекта (быть может, специального), цель которого — учет новых требований.

Несколько слов о функциональном измерении в модифицированной для объектно-ориентированного подхода матрице фазы—функции. Как было показано выше, целесообразно список производственных функций расширить за счет моделирования. Соответственно, следует определить в матрице Гантера строку интенсивностей для этой функции. В предположении о сохранении распределения интенсивностей других функций (см. рис. 8.2) распределение интенсивности для модифицированной модели жизненного цикла можно задать так, как это сделано на рис. 9.2. На рисунке показан новый вид модели целиком (указаны номера контрольных точек жизненного цикла без пояснений).

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

Рис. 9.2. Модель фазы—функции, модифицированная для объектно-ориентированного развития