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

Для получения представления о роли RUP в более серьезных усовершенствованиях существующих систем, прочитайте мою статью в майском номере журнала Rational Edge: Using the RUP to Evolve a Legacy System.

Циклы разработки ПО

В методологии RUP определяется цикл разработки ПО, который всегда состоит из последовательности четырех фаз⁴:

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

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

Эти фазы являются обязательными и через них нельзя перешагнуть; хотя в некоторых случаях проводимые в них работы можно сократить до минимума, но практически никогда невозможно сократить до нуля. Не заблуждайтесь относительно "узловой диаграммы" методологии RUP (рис. 1); эта диаграмма не учитывает факта, что вы уже затратили определенное количество времени и денег на то, чтобы выполнить часть работ. Вот один из ключевых принципов RUP: “Не делайте ничего, не имея перед собой цели.”

Рис. 1."Узловая диаграмма" методологии RUP

Давайте, например, предположим, что вы только что вышли из фазы обследования, и поняли, что имеются все предпосылки для выхода из фазы проработки проекта:

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

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

Рис. 3. Добавление цикла развития для простого расширения функциональности

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

Версия 3.0: Существенное расширение функциональности

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

Для дальнейшего обсуждения концепции улучшающего сопровождения, а также того, как развивать систему, оригинальная версия которой не была разработана с учетом требований RUP, см. мою статью в майском выпуске RationalEdge  Using the RUP to Evolve a Legacy System.

Циклы сопровождения

Теперь давайте рассмотрим наиболее типичные случаи улучшающего и адаптивного сопровождения.

Версия "исправление ошибок": улучшающее сопровождение

Допустим, что нам нужна новая версия системы, в которой исправлены некоторые уже изрядно надоевшие проблемы, обнаруженные пользователями. Цикл развития будет включать:

Вот ключевые факторы для успеха - все проделываемые нами работы уже присутствовали в RUP.

Альтернатива: Расширение вашей фазы передачи в эксплуатацию с помощью большего числа итераций

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

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

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

Пример: Задачи для простого улучшающего сопровождения

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

Версия для совместимости: адаптивное сопровождение

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

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

Сравнение цикла начальной разработки и цикла сопровождения

В чем состоят отличия цикла сопровождения по сравнению с циклом первоначальной разработки? Главным образом, нам следует скорректировать уровни формализации для:

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

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

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

Перекрывающиеся циклы

Рис. 6. Перекрещивающиеся циклы: осуществимо, но не слишко надежно

Заключение