В методологии RUP (Rational Unified Process) отсутствует концепция "фазы сопровождения". Некоторые утверждают, что это существенный недостаток, и предлагают добавить фазу производства (production phase), предназначенную для решения вопросов сопровождения, производственных процессов и поддержки1. Подобное дополнение, с моей точки зрения, вряд ли будет полезным. Во-первых, сопровождение, операции и поддержка представляют собой три значительно отличающихся процесса; хотя они, в принципе, и могут перекрываться по времени, тем не менее, в них вовлечены разные люди с разными обязанностями, и самое главное - они имеют различные цели. Совершенно очевидно, что операции и поддержка находятся за пределами функциональных границ RUP. С сопровождением дело обстоит иначе, но, несмотря на это, пока нет необходимости добавления очередной фазы в последовательность процессов RUP, состоящую из четырех фаз жизненного цикла: обследование, проработка проекта, построение системы, и передача в эксплуатацию. Методология RUP уже содержит всё необходимое для работы с ролями, операциями и артефактами, а также указания по сопровождению программных систем. И вследствие того, что методология RUP носит исключительно итеративный характер, возможность развивать, корректировать или отлаживать существующие артефакты, присуща большинству операций RUP.
-
Исправление ошибок ( корректирующее сопровождение).
-
Добавление небольших улучшений, или защита системы от устаревания ( улучшающее сопровождение).
-
Поддержка соответствия ПО своему окружению: операционной системе, аппаратным средствам, основным компонентам, таким как СУБД, графическим интерфейсам пользователя и коммуникационным системам ( адаптивное сопровождение).
За счет своей итеративной природы, методология RUP хорошо справляется со всеми упомянутыми задачами. Действительно, эволюция или сопровождение системы полностью неотличимы от процесса создания первоначальной системы - настолько, что стандарт IEEE по сопровождению3 выглядит как руководство для разработчика, учитывая идентификацию модификаций, анализ, проектирование, реализацию, регрессивное и системное тестирование, тестирование по приемке продукта и его поставку заказчику!
Для получения представления о роли RUP в более серьезных усовершенствованиях существующих систем, прочитайте мою статью в майском номере журнала Rational Edge : Using the RUP to Evolve a Legacy System .
Циклы разработки ПО
В методологии RUP определяется цикл разработки ПО, который всегда состоит из последовательности четырех фаз4:
-
Фаза обследования : определение концепции будущей программной системы и экономическое обоснование проекта, определение функциональных границ проекта.
-
Фаза проработки проекта : планирование необходимых работ и требуемых ресурсов; определение возможностей, проектирование и создание базовой версии архитектуры.
-
Фаза построения системы : создание продукта, дальнейшее развитие его концепции, архитектуры и планов работ до тех пор, пока продукт,имея законченную концепцию,не будет готов для первоначальной поставки заинтересованным лицам.
-
Фаза передачи в эксплуатацию : завершение передачи продукта в эксплуатацию своим пользователям, что включает такие процессы, как производство, поставку, обучение, поддержку и сопровождение продукта с целью полного удовлетворения потребностей конечных пользователей.
В этих фазах действительно важно не то, что вы в них делали, или как долго они проводились - важно то, чего именно вам удалось добиться. Фаза оценивается по своим контрольным точкам, причем каждая из основных контрольных точек имеет явно определенные критерии завершения, выраженные в терминах артефактов, которые должны быть созданы или улучшены, а также в количественных показателях.
Затем, уже в пределах каждой фазы, разработка ПО идет итеративно, путем повторения сходных наборов работ и последовательного улучшения создаваемой системы вплоть до момента, когда продукт может быть поставлен заказчику.
Эти фазы являются обязательными и через них нельзя перешагнуть; хотя в некоторых случаях проводимые в них работы можно сократить до минимума, но практически никогда невозможно сократить до нуля. Не заблуждайтесь относительно "узловой диаграммы" методологии RUP (рис. 1); эта диаграмма не учитывает факта, что вы уже затратили определенное количество времени и денег на то, чтобы выполнить часть работ. Вот один из ключевых принципов RUP: " Не делайте ничего, не имея перед собой цели . "
Рис. 1."Узловая диаграмма" методологии RUP
Давайте, например, предположим, что вы только что вышли из фазы обследования, и поняли, что имеются все предпосылки для выхода из фазы проработки проекта:
-
Требования понимаются однозначным образом.
-
В дальнейшем архитектура не будет изменяться.
-
Имеется план первой итерации фазы построения системы.
Только в этом случае вы, возможно, закончили всю работу, которую следовало провести для фазы проработки проекта. Обратите внимание, что в этой точке важно все тщательно обдумать - только тогда у вас появится уверенность, что вы действительно находитесь на нужном моменте, а не пытаетесь поспешно начать другую фазу проекта. Как минимум, вам понадобится акт о завершении фазы проекта.
В очень редком случае вы можете сжать фазу до минимума, как правило, при разработке нового ПО, (разработка "с нуля"), но иногда вы можете это сделать и для уже существующей системы. На рис. 2 изображен типичный профиль ресурсов для цикла начальной разработки.
Рис. 2. Версия 1.0: цикл начальной разработки
Циклы развития
Допустим, что система уже существует, и дальнейшая работа проходит в соответствии с циклом начальной разработки по методологии RUP. Рассмотрим, что произойдет дальше в цикле развития . Этот цикл будет иметь ту же самую последовательность фаз: обследование, проработка проекта, построение системы, передача в эксплуатацию , и закончится выпуском новой версии продукта. Тем не менее, так как система уже существует, отношение усилий, требуемых для проведения фаз, и реально проводимых на каждой фазе работ, будет другим по сравнению с циклом начальной разработки.
В цикле начальной разработки требуется провести немало исследований и проявить определенную изобретательность, и артефакты зачастую создаются "с нуля" , что происходит главным образом в итерациях фаз обследования и проработки. В противоположность этому, в цикле развития мы работаем, главным образом, над усовершенствованием уже существующих артефактов. Является ли это чем-нибудь новым? Конечно, нет. Это в точности то же самое, что мы уже делали в завершающих итерациях фазы построения системы и во время всей фазы передачи системы в эксплуатацию цикла начальной разработки.
Версия 2.0: Простое расширение функциональности
Давайте предположим, что мы выпустили первоначальный продукт: версия 1.0. Цикл развития для перехода к версии 2.0 может выглядеть так, как показано на рисунке 3.
Рис. 3. Добавление цикла развития для простого расширения функциональности
Перед тем, как приступить к выполнению проекта, мы создали экономическое обоснование для перехода к версии 2.0. Функциональными границами этого проекта являются:
-
Выполнение всех требований, которые были "оставлены за бортом" (но, тем не менее, зафиксированы) во время цикла начальной разработки;
-
Добавление одной-двух возможностей, появившихся при работе над проектом и зафиксированных, но так и не реализованных во избежание отрицательного влияния на график работ цикла начальной разработки;
-
Исправление небольшого количества ошибок при взаимодействии с базой данных.
Если ни одна из этих задач не влияет на архитектуру приложения, и отсутствует риск ослабления функциональных возможностей, тогда фаза проработки проекта сокращается до одного-двух дней работы. Построение системы (до бета-версии) и передача в эксплуатацию происходят итеративно в соответствии с циклом начальной разработки, с тем же самым персоналом и тем же распределением ролей. Все артефакты обновляются в соответствии с развитием. Цикл процесса разработки будет выглядеть подобно, изображенному на рис. 4.
Рис. 4. Добавление цикла развития с минимальной фазой проработки проекта
Версия 3.0: Существенное расширение функциональности
Далеко не все циклы развития могут быть настолько просты. Давайте предположим, что, основываясь на успехе версии 2.0 (однопользовательской, однопроцессорной версии), требования к версии 3.0 будут включать распределенную систему, поддерживающую несколько пользователей. Затем нам нужно провести ответственную фазу проработки проекта для усовершенствования и утверждения архитектуры системы, так как эволюция представляет собой достаточно рискованный шаг. Теперь цикл будет больше походить на оригинальный профиль цикла начальной разработки (см. рис. 2), с нетривиальными работами обследования и проработки процесса.
Для дальнейшего обсуждения концепции улучшающего сопровождения, а также того, как развивать систему, оригинальная версия которой не была разработана с учетом требований RUP, см. мою статью в майском выпуске Rational Edge Using the RUP to Evolve a Legacy System .
Циклы сопровождения
Теперь давайте рассмотрим наиболее типичные случаи улучшающего и адаптивного сопровождения.
Версия "исправление ошибок": улучшающее сопровождение
Допустим, что нам нужна новая версия системы, в которой исправлены некоторые уже изрядно надоевшие проблемы, обнаруженные пользователями. Цикл развития будет включать:
-
Фазу обследования : Как и для любого проекта, нам нужны функциональные границы (Что действительно должно быть фиксировано?), план (Каким образом фиксируется деятельность разработчиков и затрачиваемое время?), и экономическое обоснование проекта (Почему мы должны это делать?).
-
Фазу проработки проекта : Это, как я надеюсь, должно потребовать минимальных усилий, большинство наших исправлений ошибок не потребуют изменений требований или архитектуры.
-
Фазу построения системы : Необходима одна итерация для проведения исправления ошибок, последующего тестирования, выполнения регрессивных тестов и подготовки выпускаемой версии.
-
Фазу передачи в эксплуатацию : Если нам повезет, и завершение сборки не покажет снижения характеристик системы, тогда здесь не потребуется серьезных усилий.
Вот ключевые факторы для успеха - все проделываемые нами работы уже присутствовали в RUP .
Альтернатива: Расширение вашей фазы передачи в эксплуатацию с помощью большего числа итераций
Если улучшающее сопровождение влечет за собой лишь минимальное число изменений, в этом случае вы можете рассматривать его просто как дополнительную итерацию в вашей фазе передачи в эксплуатацию (см. рис. 5).
Рис. 5. Добавление небольших итераций улучшающего сопровождения в фазу передачи системы в эксплуатацию
Если мы рассматриваем это как экстремальное обстоятельство, то в таком случае мы имеем образец инкрементной поставки, описанной Томом Гилбом5: после того, как проделана первоначальная интенсивная работа, наступает следующий этап - система начинает инкрементно поставляться заказчику, с добавлением дополнительной функциональности на каждом шаге.
Пример: Задачи для простого улучшающего сопровождения
Ниже представлен список задач, выполнение которых может потребоваться при простой итерации улучшающего сопровождения:
Задача: Разработка плана итерации
Цели определяются выбором выполняемых запросов на изменение.Задача: планирование тестирования
Идентификация определенного теста для проверки исправления и полного набора регрессивных тестов, которые нужно провести перед выпуском окончательной версии.
Задача: распределение работЗадача: создание рабочего пространстваЗадача: создание интеграционного рабочего пространстваЗадача: исправление ошибок
Это повторяется для каждого дефекта.Задача: выполнение тестов
Задача: интеграция системы
Задача: выполнение системных тестов
Это включает все тесты, которые нужно выполнить для проверки новой версии выпускаемого продукта.Задача: Создание базовой версии
Задача: Создание описания новой версии
Задача: Модификация запроса на изменение
Задача: проведение подготовки акта о приемке работ по итерации
Задача: выпуск продукта
Версия для совместимости: адаптивное сопровождение
Зачастую нам требуется сопровождающая версия продукта (maintenancerelease), вследствие того, что обновилась одна из частей общей системы. Это могут быть изменения компонента системы, например такого, как база данных, или некоторых элементов системного окружения, скажем, операционной системы, платформы или коммуникационного интерфейса. Для того, чтобы сохранить совместимость продукта, нам следует перестроить (иногда) и повторно протестировать (практически всегда) программную систему, содержащую новые элементы. Но при этом сама система не нуждается в расширении.
Этот тип цикла сопровождения будет также иметь обтекаемый вид. В простом случае, потребуется изменить лишь несколько артефактов, а основное время займет повторная генерация системы и ее тестирование. Если интерфейс системы изменился, тогда потребуется провести некоторое проектирование и кое-где поменять программный код. Все работы, которые нужно провести, уже описаны в RUP. Тем не менее, разумно запланировать две итерации, вследствие наличия неизбежных рисков:
-
итерацию для проведения портирования или конверсии, и последующего выполнения регрессивных тестов: с целью надежного исключения риска .
-
итерацию для проведения любых исправлений, определенных во время первой итерации: для решения любых возможных проблем .
Сравнение цикла начальной разработки и цикла сопровождения
В чем состоят отличия цикла сопровождения по сравнению с циклом первоначальной разработки? Главным образом, нам следует скорректировать уровни формализации для:
-
размера организации.
-
рисков для заинтересованных лиц.
Если мы нанимаем незначительный штат, возможно только с одним сотрудником для выполнения этой работы, то этому сотруднику придется выполнять многие роли, определенные в RUP: все задачи, необходимые для обновления различных артефактов, модификации программного кода, тестирования системы и последующего выпуска окончательной версии продукта. Эти артефакты не являются новыми или значительно отличающимися, они просто обновляются, точно так же, как мы это делали в заключительной итерации цикла начальной разработки. Чем лучше мы выполнили работу на более ранних циклах разработки, тем легче будут задачи персонала, проводящего цикл сопровождения.
Если существует высокая вероятность возникновения риска, технического или какого-либо другого, тогда в процессе разработки следует продвигаться более осторожно, для обеспечения уверенности в том, что соответствующие риски правильно и заблаговременно поняты.
Конфигурационное управление и управление изменениями имеет наивысший приоритет для цикла сопровождения, особенно с точки зрения проведения параллельного сопровождения многих версий продукта или поддержки предыдущих версий.
Перекрывающиеся циклы
-
Для завершения цикла зачастую прикладываются титанические усилия, особенно в цикле начальной разработки, и для того, чтобы уложиться в сроки, необходимо участие наиболее квалифицированных сотрудников. Поэтому следует иметь в запасе несколько свободных рук для выполнения ответственной работы в фазе обследования и проработки проекта для следующего цикла.
-
По мере того, как вы увеличиваете перекрытие, наступает момент, при котором модификации артефактов проекта (исходного кода или других) для последующего цикла приведет к необходимости трудоемкого согласования с результатами текущего цикла.
-
Чем более перекрываются циклы, тем значительнее становятся риски (например, сбои в коммуникациях, возврат к предыдущему состоянию, переработка, возникновение конкуренции использования ресурсов).
Рис. 6. Перекрещивающиеся циклы: осуществимо, но не слишко надежно
Заключение
1 Scott Ambler, "Enhancing the Unified Process". SD Magazine , October 1999.
2 IEEE Standard 610.12:1990, Glossary of Software Engineering Terminology .
3 IEEE Standard 1219-1998, Software Maintenance .
4 Rational Software Corporation, Rational Unified Process . Cupertino California, 2001.
5 Tom Gilb, Principles of Software Engineering Management . Addison Wesley, 1988.