38. Объектно-ориентированные модели жизненного цикла программного обеспечения

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

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

        Итеративность развития

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

        Наращивание функциональности в соответствии со сценариями

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

        Ничто не делается однократно

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

        Оперирование на размножающихся фазах подобно

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

В ходе итеративного наращивания обыкновенно выполняются вполне традиционные этапы:

        Определение требований, или план итерации — фиксируется, что должно быть выполнено на данной итерации в виде описания области, для которой планируется разработать функциональность на данной итерации, и что для этого нужно. Обычно этот этап включает отбор сценариев, которые должны быть реализованы на данной итерации;

        Анализ — исследуются условия выполнения планируемых требований, проверяется полнота отобранных сценариев с точки зрения реализации требуемой функциональности;

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

        Конструирование — обычная декомпозиция проекта, проводимая в объектно-ориентированном стиле. Конструирование включает построение или наращивание иерархии системы классов, описание событий и определение реакции на них и т.д. В ходе конструирования определяются объекты, реализуемые и/или доопределяемые на данной итерации, и набор функций (методов объектов), которые обеспечивают решение задачи данной итерации;

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

        Тестирование — этап комплексной проверки результатов, полученных на данной итерации;

        Оценка результатов итерации — этап включает работу, связанную с рассмотрением полученных результатов в контексте проекта в целом. В частности, должно быть выяснено, какие задачи проекта можно решать с учетом результатов итерации, на какие ранее поставленные вопросы получены ответы, какие новые вопросы возникают в новых условиях.

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

Следует отметить еще одну модификацию схемы Гантера, отраженную на рисунке. В рамках этапа оценки выделен специальный вложенный этап Пополнение базового окружения проекта, смысл которого сводится к переиспользованию программного обеспечения. Любой объектно-ориентированный проект реализуется исходя из некоторой уже существующей среды классов и других компонентов. Это базовое окружение проекта интенсивно используется и, в свою очередь, пополняется средствами, возникающими в результате итеративного наращивания. Полезность сохранения таких средств для текущего проекта и для последующих разработок не подлежит сомнению. В этой связи целесообразно в рамках выполнения этапа оценки производить дополнительную работу, направленную на сохранение полезного в депозитарии проектов.

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

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

 

Рис. 2.8. Модель жизненного цикла при объектно-ориентированном развитии проекта

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

        требуется определить ближайшую задачу и перспективные задачи проекта. Первая из них — задача первой итерации, в ходе которой, в частности, готовится первый рабочий продукт, предъявляемый заказчику. От качества это результата зависит судьба проекта в целом. Перспективные задачи — это планируемое развития, которое допускает корректировку в дальнейшем;

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

Фаза завершения проекта включает в себя:

        поставка (roll-out) или пакетирование изделия для потребителя и

        сопровождение программного продукта.

После того, как приложение используется некоторое время, и оно может рассматриваться как готовое,  в рамках данной фазы осуществляется:

        выделение переиспользуемых компонентов.

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

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

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

Планирование итерации (1-2, 7-8)

Анализ (2-3)

Конструирование (3-5)

Программирование (4-7)

Тестирование (6-7)

Оценка (7-8)

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

I.

Пл

Ан

Ко

Пр

Те

Оц

II.

Пл

Ан

Ко

Пр

Те

Оц

III.

Пл

Ан

Ко

Пр

Те

Оц

 б) Три итерации проекта I, II и III, развиваемые одновременно

Пл		Ан	Ко		Пр	Те	Оц
	Совмещение не допустимо			Совмещение  возможно			Совмещение рационально	Последовательное выполнение

  в) Пределы совмещения итераций в проекте

Рис. 2.9. Распараллеливание выполнения итераций проекта

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

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

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

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

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

 

Рис. 2.10. Спираль развития объектно-ориентированного проекта