ФИНЭКОСОФТ

Colin O'Neill, Директор, OCSolutions

Оригинал статьи:http://www.ibm.com/developerworks/rational/library/sep07/oneill/index.html

От журнала Rational Edge: Организации могут наращивать мощь своего процесса, построенного на базе RUP, добавляя еще одно макроизмерение к изначальной идее итераций. Использование эволюций (evolutions) -- множественных и перекрывающихся прохождений вдоль жизненного цикла RUP -- может снизить риск разработки при значительном уменьшении времени поставки системы заказчикам и повышении эффективности использования ресурсов, как утверждает Колин О'Нейл (Colin O'Neill), который также предлагает и графические иллюстрации, представляющие принципы макроитеративного измерения.

Подход к разработке, описанный в IBM® Rational Unified Process® или RUP®, является итеративным, как с точки зрения микро, так и макроитеративного измерения. Эта статья фокусируется на макроитеративном измерении, вводя понятия эволюций, которые представляют собой множественные и перекрывающиеся прохождения вдоль жизненного цикла RUP. Этот подход RUP поддерживает принцип гибкой поставки систем в виде быстрого и частого производства релизов конечного продукта. Поскольку каждая итерация снижает проектный риск, то каждый эволюционирующий релиз снижает организационный риск.

Расширение концепции итеративной разработки

Итеративная разработка базируется на спиральной модели, разработанной в конце 80-х годов Бари Боэмом (Barry W. Boehm, "A Spiral Model of Software Development and Enhancement," IEEE Computer, vol. 21, #5, May 1988). В течение ряда лет диаграмма жизненного цикла, представленная на рис.1, была классикой отображения RUP интерпретации модели Бари Боэма. Она представляет четыре фазы (или этапа) -- Начало (Inception), Уточнение (Elaboration), Построение (Construction) и Внедрение (Transition) -- каждая из которых состоит из одной или более итераций. Каждая итерация -- и, соответственно, каждая фаза -- охватывает разработку и проверку чего-то, что является либо симуляцией бизнес процесса, либо архитектурным прототипом, либо операционным кодом или релизом продукта. Итерация включает все дисциплины и деятельности, требуемые для успешного выполнения фазы (Barry W. Boehm, "Anchoring the Software Process," IEEE Software, vol.13, #4, July 1996), и определяет ограниченный по времени набор работ, позволяющий реализовать инкрементное наращивание чего-то полезного в разрабатываемом продукте.

Рисунок 1: Широко известная диаграмма жизненного цикла RUP

Диаграмма жизненного цикла RUP отображает RUP вместе с микроитеративным измерением, которое адекватно представляет усилия, требуемые для выполнения малых проектов. Хотя диаграмма жизненного цикла RUP не является точной диаграммой структуры проекта, она представляет концепцию жизненного цикла для отдельного проекта и полный цикл разработки ПО (Philippe Kruchten, "Software Maintenance Cycles with the RUP," The Rational Edge, August 2001). Организации обычно выстраивают и финансируют проекты, основываясь на допущениях, что они будут стабильно производить и поставлять систему. Если проект требует лишь одно прохождение через жизненный цикл разработки ПО для создания и поставки необходимого продукта конечным пользователям, тогда достаточно просто разбить цикл на серии итераций в составе соответствующих фаз (Grady Booch, Object Solutions: Managing the Object-Oriented Project, Addison-Wesley, 1995).

Однако большинство средних и крупных проектов получат значительный выигрыш от организации множественных прохождений через жизненный цикл RUP; это верно как для приложения в коробочном варианте поставки, так и для приложения, создаваемого в ходе заказной разработки. Эти проекты требуют макроитеративного измерения, которое представляет итеративный процесс в виде серии циклов (Best Practices for Software Development Teams, Rational Software white paper, 1998), называемых мной эволюциями (Kurt Bittner and Ian Spence, Managing Iterative Software Development Projects, Addison-Wesley, 2007).

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

Сила эволюций

Так как конкуренция на рынке становится все острее, IT проекты находятся под постоянным давлением необходимости ускорения развития функционала систем, разрабатываемых для конечных пользователей. Процессы водопадной разработки нацелены на производство требуемого функционала к концу проекта -- неэффективный подход для разработки средних и крупных, достаточно сложных систем (Per Kroll, "The RUP: An Industry-wide Platform for Best Practices," The Rational Edge, December 2001). Гораздо более эффективно и менее рискованно вести разработку меньшими кусками функционала, но в то же время более частыми -- другими словами, выпускать релизы продукта множество раз. Это основная предпосылка, лежащая в основе эволюционного подхода RUP. Это также основной принцип гибкой, итеративной методологии, представляющей значительное улучшение водопада в отношении рисков, стоимости, качества и эффективности.

Выгоды от применения эволюций

Использование RUP, как серий эволюций предоставляет множество важных преимуществ (Ibid, Bittner and Spence, 2007):

• Люди фокусируются на краткосрочных целях. Дата поставки очередного релиза системы действует, как мотиватор для каждого участника проекта и является ключевой целью.
• Участники команды достаточно рано получают удовлетворение и значительный рост своего опыта. Участники проекта быстро получают реальный работающий продукт -- вместе с возможностью развивать его сильные и слабые стороны.
• Конечные пользователи могут расставить приоритеты. Организация и ее конечные пользователи могут принять решение о том, какой функционал им необходим в первую очередь и какой можно отложить до следующих релизов (Per Kroll and Walker Royce, "Key Principles for Business-Driven Development," IBM developerWorks, October 2005). И им комфортно быть уверенными, что все необходимые функции будут реализованы — и установлен грамотный порядок их реализации.
• Организация выигрывает в целом. Постепенно все большая часть организации получает полезные релизы для эксплуатации системы в промышленных условиях, т.к. они выпускаются часто.
• Менеджеры могут более эффективно использовать как закрепленные за проектом, так и разделяемые ресурсы организации. В ходе обычной фазы Уточнения (Elaboration), системные аналитики, проектировщики и архитекторы загружены полностью, тестировщики загружены частично (создают сценарии тестирования на основе сценариев использования) и разработчики почти не загружены. Если планируется множество эволюций, то можно распределить занятость для всего проекта способом, который гарантирует, что ни одна группа не будет перегружена или недогружена в любой момент времени.
• Заинтересованные лица остаются полностью востребованными на всем протяжении циклов разработки и поставки. Менеджеры проектов могут привлекать и способствовать участию как специалистов IT, так и специалистов бизнеса при разработке желаемого решения. Специалисты с особенными навыками легко могут перейти из одной эволюции в другую, пока проектные проблемы все еще свежи в их памяти. Обычно эксперты от бизнеса максимально задействованы в фазах Начала (Inception) и Внедрения (Transition); системные аналитики и архитекторы - в фазе Уточнения (Elaboration) и разработчики обычно наиболее активны в фазе Построения (Construction). Если имеются неперекрывающиеся итерации со значительными разрывами между ними, то есть риск потерять эти ресурсы для других проектов и может возникнуть необходимость ввода новых участников, которые не работали на ранних стадиях. Эволюционный подход помогает обеспечить непрерывность проекта и придает ему импульсы для быстрейшей реализации критичных требований с целью производства высококачественных продуктов в короткие отрезки времени.
• Архитектура может эволюционировать итеративно. Команды могут непрерывно развивать и улучшать архитектуру вместо попыток определить все архитектурно значимые элементы сразу.
• Администраторы могут лучше разобраться и сопровождать продукт. Руководитель проекта может рассматривать администраторов, как заинтересованных лиц, выделяя для них время и давая возможность изучать продукт, чтобы интегрировать последний в общую инфраструктуру организации и эффективно управлять им. В ходе последующего развертывания они могут помочь в организации обратной связи, используя реальный накопленный опыт.

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

Перекрывающиеся эволюции: Расширение макроизмерения

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

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

Эволюции могут перекрываться не более, чем тремя фазами, но никак не четырьмя; нельзя начать фазу в новой эволюции, пока не завешена аналогичная фаза в предыдущей (Ibid, Bittner and Spence, 2007). Кроме того, перекрывающиеся эволюции порождают риск - если были сделаны значительные изменения в архитектуре или в требованиях в более поздних эволюциях, то это может повлиять на более ранние эволюции. Эффективный процесс управления изменениями может помочь справиться с этим риском.

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

Применение эволюций в реальном проекте

Недавно, консультируя команду в рамках эволюционного подхода в основном проекте, организованном по принципам RUP, я разработал три возможных представления двух итерационных измерений RUP. В этой работе я применил принципы, предложенные Эдвардом Туфте (Edward R. Tufte, The Visual Display of Quantitative Information, Cheshire, CT: Graphic Press, 1983), пионером в области многомерного графического дизайна. Каждый метод представления имеет свои сильные и слабые стороны. Давайте начнем рассмотрение каждого из них с краткого описания проекта RUP, на который я далее буду ссылаться, как на Проект X.

Обзор Проекта X

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

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

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

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

Спиральное представление Проекта X

Рис.2 показывает один из вариантов представления макроитеративного подхода, используемого нами. Здесь показаны три эволюции для этого проекта с применением цилиндров, каждый из которых представляет итерацию. Заметьте, что каждый цилиндр содержится внутри своей спирали, представляющей эволюцию.

Рисунок 2: Спиральное представление проекта

**Рисунки 2, 3, и 4, предложены Эрином Кином (Erin King), 2007

Объем каждого цилиндра отражает общий относительный уровень трудоемкости в итерации (УТ) в терминах человекочасов. Каждый срез цилиндра представляет отдельную дисциплину RUP; в соответствии с лучшими практиками RUP все дисциплины участвуют в каждой итерации. Толщина каждого среза отражает УТ для разнообразных ролей внутри соответствующей дисциплины. Аналогичным образом горбы из цилиндров на рис.1 выражают изменение УТ, которая требуется для каждой дисциплины на всем протяжении итераций и фаз. Заметьте, как изменяется толщина срезов для итераций различных типов (Philippe Kruchten, The Rational Unified Process: An Introduction, Addison-Wesley, 2004).

В первой эволюции (I1), итерация фазы Начала (Inception) была всеобъемлющей (продолжительностью 4 недели). Здесь были определены границы проекта и гарантированные выгоды для заинтересованных лиц от всего проекта. Итерации фазы Начала (Inception) в последовательных эволюциях (I2 и I3) были очень короткими. В них просто были определены границы и расписания для соответствующих эволюций. Заметьте, что третья эволюция включает две последовательных итерации Построения (Construction) - C3 и C4. Так сделано потому, что требуется большое количество кода для реализации требований, определенных в итерации E3.

Представление Проекта X в виде плавательных дорожек

Рис.3 предлагает другой путь для отображения макроитеративного изменения Проекта X. Он использует плавательные дорожки вместо спиралей для представления эволюций и параллелепипеды вместо цилиндров для представления итераций. Объем каждого параллелепипеда выражает относительную УТ итерации. Также заметьте, что итерации соотносятся по времени в соответствии с их расположением на временной шкале рис.2.

Рисунок 3: Представление плавательных дорожек для Проекта X

Хотя рис.2 показывает, что итерации могут выполняться параллельно, здесь не показано, как итерации зависят друг от друга внутри эволюций. С помощью стрелок рис.3 показывает, как результаты одной итерации могут переходить в другую, создавая таким образом вместе полное, автоматизированное решение. В Проекте X итерация E1 имела продолжительность шесть месяцев и привела к выпуску восьми значимых сценариев использования. Когда команда разработчиков завершила фазу Уточнения (Elaboration) и достигла ее точки контроля (т.е. архитектура и требования для некоторого куска системы стали стабильными), то архитекторы, программисты и тестировщики, задействованные в итерации E1 стали лидерами в итерации C1. В ходе этой итерации участники команды реализовали в системе функции, описанные в E1, создав стабильный продукт, позволяющий выполнять онлайновые платежи индивидуалами и членами семей. Затем итерация T1 позволила экспертам предметной области провести приемочные испытания и расписаться в передаче системы в промышленную эксплуатацию.

План проекта, разработанный в течение итерации I1 показал, что будет три промышленных релиза и, по этой причине, три эволюции. Однако, когда было выполнено планирование второй эволюции в итерации I2, выяснилось, что заинтересованные лица от бизнеса не получат никаких бизнес выгод от развертывания результатов Эволюции 2 без функций, реализация которых была намечена в Эволюции 3. По этой причине было решено финансировать выполнение Эволюции 2 до фазы Внедрения (Transition) (включая приемочные испытания), но при этом остановиться перед выпуском промышленного релиза. Именно по этой причине на рис.3 показано, что итерация T2 является полупрозрачной и имеет штрихпунктирную границу. В данном примере, сама по себе эволюционная модель дает огромную выгоду, позволяя команде избежать ненужной работы и ее дублирования.

Проекционное представление Проекта X

Может быть не так привлекательно, как на рис.2 и 3, но рис.4 несет такую же информацию, а при этом и с одним дополнительным параметром: общее количество ресурсов, необходимых в каждый момент времени для некоторого подмножества эволюций. Точки на передней части каждого параллелепипеда представляют относительное количество ресурсов, требуемых для каждой дисциплины в рамках итерации. Когда эти точки проецируются на колонки с общим количеством ресурсов (вершина фигуры), то результаты суммируются. Этот графический рисунок иллюстрирует очень вероятный и мало понятный риск: для итеративной разработки систем на макроуровне необходимо уметь предвидеть, сколько и каких ресурсов потребуется для того, чтобы точно сформировать команду проекта, особенно для наиболее трудоемких и сложно управляемых периодов, когда эволюции перекрываются. Заметьте, что количество ресурсов для дисциплин Реализации (Implementation) и Тестирования (Test) наибольшее в течение 16 недели, когда три трудоемкие итерации выполняются одновременно.

Именно здесь интересно взглянуть на Проект X. Итерация E3 (в которой определяется вторая часть требований к проведению онлайновых платежей работниками бизнес организаций) была в самом разгаре, как и итерация T1 (приемочные испытания для части системы, реализующей операции для индивидуалов и членов семей) и итерация C2 фазы Конструирования (Construction), предназначенная для реализации первой половины требований по индивидуалам. Это предъявило значительные требования к персоналу: Как смогли бы системные аналитики сформировать сценарии испытания, продолжая совместную работу с разработчиками и тестировщиками в рамках предыдущих эволюций? Как смогли бы тестировщики продолжать проверку реализации требований и, в то же время, будучи погруженными в систему, интеграцию, приемочные испытания, и все в одно и то же время? Хотя организация, комплектование команды, коммуникация и взаимодействие на параллельных эволюциях путали все с течением времени, выгоды -- ускорение поставки на рынок и максимально эффективное использование ресурсов -- значительно превзошли потраченные усилия.

Рисунок 4: Проекционное представление Проекта X

Результаты проекта X: ускорение поставки на рынок, максимальная утилизация ресурсов, более качественное программное обеспечение

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

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

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

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

Двигаясь дальше

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

Этот подход особенно полезен для определенных типов проектов:

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

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

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

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