Путеводитель по разработке методов (Rational Edge)

На протяжении десяти лет команда IBM Rational Unified Process, или RUP, занималась созданием базовых средств разработки методов, "варясь в собственном соку", т.е. используя те принципы, процессы и технологии, которые сам RUP применяет для разработки программного обеспечения. Однако создание такого базового средства разработки, как RUP, - это совсем не то же самое, что разработка приложения.  С годами команда разработчиков RUP адаптировала свои собственные процессы и технологии к конкретным нуждам разработки методов.  С появлением IBM Rational Method Composer  (RMC) все большее число клиентов и внутренних команд IBM начинают создавать или адаптировать собственные методы. В связи с этим возникла настоятельная потребность в создании руководства по разработке методов.

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

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

Данный подход описан в терминах RMC, чтобы согласовать терминологию между методом и инструментальным средством и чтобы показать, что его можно легко реализовать при помощи RMC. Однако этот подход можно широко применять и вне RMC: например, его можно использовать для написания книги метода (Method Book).

Подход описывает новые методы с нуля, допускает существенную адаптацию уже существующих методов, например, расширение RUP до сервис-ориентированной архитектуры (RUP for SOA) и SOA до System z (RUP for z). Однако данный подход не решает сложной задачи объединения нескольких существующих методов в один общий метод. Кроме того, он не предназначен для прямой адаптации, ⁴ например, модификации уже существующего метода для заданного проекта на основе адаптации структуры последовательности действий или плана проекта.

Разработка методов в сравнении с разработкой программного обеспечения

Основные принципы бизнес-ориентированной разработки, определенные Пером Кроллом (Per Kroll) и Уокером Ройсом (Walker Royce)  для преимущественно программных систем, в целом могут быть применены и к методам. Следовательно, ими можно руководствоваться в целях улучшения результатов проектирования метода. Эти принципы таковы:

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

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

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

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

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

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

Рабочие продукты разработки метода

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

Рабочие продукты, характерные для метода

В первую очередь метод определяется в терминах элементов метода (Method Elements). Элемент метода может являться элементом контента (Content Element) (роль, задача, рабочий продукт, руководство для контента) или элементом процесса (Process Element) (действие, шаблон действий, процесс получения, или руководство для процесса). Определения различных типов компонентов метода приведены в таблице 1.

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

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

На ранних этапах проектирования рекомендуется обрисовать метод в общих чертах посредством эскиза метода (Method Sketch). Задача эскиза метода заключается в том, чтобы помочь проектной группе определить подходящие элементы метода и некоторые отношения между ними и предложить предварительное описание некоторых ключевых компонентов. Для этого и в зависимости от типа проекта (создание нового метода с чистого листа, расширение уже существующего метода только за счет компонентов контента, расширение уже существующего метода за счет компонентов, контента и процесса, и так далее) эскиз метода может принимать различные формы. Например, он может содержать один или несколько из следующих элементов: критический анализ жизненного цикла, краткое описание возможных ролей, задач и рабочих продуктов и их отношения, перечень потенциальных руководств по методу (шаблоны, примеры, "белые книги" и т.д.), предварительный график распределения работ (WBS) или макет Web-сайта метода. Эскиз метода должен быть задокументирован в графическом формате, текстовом документе, в виде электронной таблицы, визуальной модели или с помощью любых других средств. Такое свободное представление предназначено для поддержки творческого мышления и позволяет проектной группе определить и проанализировать предварительные эскизы метода, используя контент, формат, обозначения, и поддержать те из них, которые в большей степени соответствуют их навыкам и потребностям. Как только из эскиза метода начинает прорисовываться новый метод или часть метода, это значит, что пора запускать Rational Method Composer, в котором можно дать более полное и более формальное определение метода. На данном этапе можно расстаться с эскизом метода и оставить его для исследования других идей, преобразовать его в маршрутную карту метода (управление процессом) или просто превратить, например, в перечень всех компонентов метода, которые необходимо создать. В этом случае его можно использовать для распределения обязанностей и отслеживания хода работы.

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

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

Конфигурация метода (Method Configuration) - описание версии метода (например, RUP для малых проектов и RUP для крупных проектов). В RMC, конфигурация метода определяет, каким образом следует создавать Web-сайт метода на основе компонентов метода, вошедших в выборку плагинов метода и пакетов метода (так как может возникнуть желание не публиковать все элементы метода, определенные в методе в контексте заданной конфигурации). Конфигурация метода также определяет представления, которые будут отображаться в браузере в дереве Web-сайта метода.

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

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

Рисунок 1: Пример описания метода для RUP for z в RMC, включая выбор компонентов для публикации на Web-сайте метода RUP for z

На рисунке 1 показан пример описания метода RMC для RUP for z, содержащего 3 плагина метода (rup, rup_for_soa, и rup_for_z, так как плагин rup_for_z определяется расширением и rup и rup_for_soa) и 1 конфигурация метода (конфигурация RUP for z). Но, несмотря на то, что описание метода содержит три плагина метода, только плагин rup_for_z входит в область разработки метода RUP for z. (Плагины rup и rup_for_soa находятся за пределами данной области, потому что они не будут изменены при проектировании). Конфигурация RUP for z определяет контент, публикуемый на Web-сайте RUP for z. В этом упрощенном примере Web-сайт будет содержать элементы контента пакета контента метода rup (пакет процессов rup был отфильтрован), элементы контента пакета контента метода rup_for_soa (пакет процессов rup_for_soa был отфильтрован), так же, как и все элементы метода (из обоих пакетов: контента и процессов) rup_for_z. Пользователи смогут перемещаться по Web-сайту с помощью дерева навигации, показанного в поле представления (View) на рисунке 1.

На рисунке 2 показан пример Web-сайта метода для RUP for z, который был сгенерирован из описания метода, показанного на рисунке 1.

Рисунок 2: Пример Web-сайта метода для RUP for z

Если новый метод строится с чистого листа, то в начале проектирования описание метода будет пустым. Если метод адаптируется, то в описании метода содержатся плагины уже существующего метода, но не существующие конфигурации, так как конфигурация специфична для заданного метода и, следовательно, не является ресурсом многократного использования. Например, для того, чтобы создать адаптированную версию RUP for z, необходимо начать с описания метода, в том числе и плагинов, показанных на рисунке 1. Затем, как минимум, необходимо добавить: один новый плагин метода (на базе уже существующих плагинов: rup, rup_for_soa, и rup_for_z), для того, чтобы описать элементы метода, специфичные для нового метода, и одну новую конфигурацию метода, для того, чтобы сконфигурировать Web-сайт нового метода. Новые элементы метода могут быть созданы с нуля или посредством усиления некоторых компонентов уже существующего метода, используя отношения вариативности  (например, вклад, расширение или замена).

А теперь наступило время определить пару терминов, которые я упоминала раньше:

• Архитектура метода (Method Architecture) описывает структуру метода в терминах значимых структурных компонентов и отношений между ними.
• План метода (Method Design) описывает структуру метода, включая все структурные элементы и отношения между ними.

В RMC структурными элементами являются: плагины метода, пакеты метода, элементы метода и конфигурации метода.

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

Вспомогательные рабочие продукты

Помимо тех основных рабочих продуктов, характерных для разработки метода, которые были рассмотрены выше, и, невзирая на тот факт, что описываемый в данной статье подход нацелен на разработку самого метода, а не документации по проекту, возникают ситуации, когда определенную пользу разработке может принести создание вспомогательных рабочих продуктов. В данном разделе будут представлены некоторые продукты, которые, хотя и не характерны для разработки метода, все же доказали свою пользу в поддержке проектно-конструкторских работ различных масштабов. Аналогичные рабочие продукты можно обнаружить и в других методах, например, в OpenUP/Basic ⁷ или RUP. Степень формализации данных вспомогательных рабочих продуктов зависит от многих факторов, например, сложности проекта, традиций организации-разработчика и динамики управления проектом.

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

Поскольку я искренне верю в преимущества итеративного и учитывающего риски подхода к разработке метода, то для эффективной реализации проекта я рекомендую использовать план проекта (Project Plan). План проекта определяет стадии и этапы проектирования. Он может содержать и план итераций (Iteration Plan) для описания особенностей каждой итерации (например, в терминах задач с назначенными ресурсами), и оценку итераций (Iteration Assessment) для оценивания результатов итерации и внесения необходимых промежуточных корректив, а также перечень рисков (Risk List) для выявления и определения приоритетов рисков, и описания действий по предупреждению последствий или поведения в непредвиденных ситуациях.

В таблице 3 перечислены все рабочие продукты, которые рекомендуются для обеспечения разработки метода.

Путеводитель по разработке метода

Представленный в данной статье подход к разработке метода основан на 4 стадиях RUP: начало (Inception), проектирование (Elaboration), построение (Construction) и внедрение (Transition). В данном разделе мы пройдем по всем стадиям типичного проекта.

Начальная стадия (Inception)

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

Цели начальной стадии

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

Критерии оценки начальной стадии

В конце начальной стадии проектирования проект следует оценить по следующим критериям:

• Достигнуто ли согласие заинтересованных сторон относительно оценок объема, требований, ограничений и календарного плана.
• Все ли риски были определены, и был ли для каждого случая выработан комплекс действий по предупреждению последствий или поведению в непредвиденных ситуациях.
• Установлена ли среда разработки метода и готова ли она к переходу к стадии разработки? В частности, установлены ли: среда управления конфигурацией (например, IBM Rational ClearCase®) и среда разработки метода (например, RMC).
• Прошла ли команда соответствующее обучение и готова ли она приступить к стадии проектирования.

Если проект не удовлетворяет данным критериям, то он может быть отклонен или пересмотрен.

Состояние ключевых рабочих продуктов по окончании начальной стадии

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

Ключевые задачи, выполняемые во время стандартной итерации начальной стадии

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

Рисунок 3: Ключевые задачи начальной стадии вместе с их ролями и входными/выходными рабочими продуктами

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

Например, ядро метода RUP для System z ⁸ по большей части было определено стратегией "сверху вниз", в рамках группового поиска идей, который происходил целыми рабочими днями в течение двух недель. Результаты данного мозгового штурма были задокументированы в эскизе метода. Во-первых, пользователей z попросили изучить все стадии RUP и определить, какие изменения следует внести в его основные задачи и разработанную документацию для того, чтобы удовлетворить какие-либо конкретные потребности среды z. Это позволило проектной группе определить начальный набор рабочих продуктов (например, процедуры проверки установки и модулей), который необходимо добавить в RUP для удовлетворения потребностей специалистов z и для достижения согласия относительно того факта, что цели основных стадий RUP применимы к z. Во-вторых, пользователей z попросили описать типичные действия высокого уровня, которые выполняются ими в настоящее время и которые позволят решить задачи, поставленные перед каждой стадией. Это позволило группе разработчиков определить для каждой стадии типичные итерации в терминах последовательности или сочетания действий высокого уровня. В-третьих, пользователей z попросили дать подробное описание каждого действия с точки зрения группировки задач (и возможные промежуточные действия), выполняемого ответственным лицом (ролью) и создающего рабочие продукты, - это было реализовано усилением как можно большего числа существующих компонентов RUP. Данная деятельность позволила группе разработчиков определить круг задач (например, модульный проект и процедуры проверки установки) и имеющие отношение роли и рабочие продукты, которые необходимо добавить в RUP for z. Результатом данной стратегии является определение непрерывного процесса, описывающее технологии разработки ПО, используемые в настоящее время в среде z и усиливающие некоторые задачи, роли, рабочие продукты, действия и передовой опыт, воплощенные в RUP. Кроме того, данная стратегия дает гарантию того, что каждый компонент метода явно связан с одной или несколькими целями стадии.

Таблица 4: Описание задачи построения эскиза метода

Задача: Эскиз метода (Method Sketch)

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

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

Стадия проектирования

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

Цели проектирования

Основная цель стадии проектирования заключается в построения прототипа архитектуры метода (Method Architecture) для того, чтобы предоставить стабильную основу для разработки на стадии проектирования. Устойчивость архитектуры оценивается посредством одного или нескольких Web-сайтов метода.

Критерии оценки проектирования

На последнем этапе стадии проектирования, проект оценивается по следующим критериям:

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

Если проект не удовлетворяет данным критериям, то он может быть отклонен или продуман заново.

Состояние ключевых рабочих продуктов на заключительном этапе стадии проектирования

• Эскиз метода. Определены не только все существенные компоненты метода, но и некоторые их из отношений. В эскизе может присутствовать первичное описание некоторых ключевых компонентов. Было проведено изучение и достигнуто согласие по эскизу, например, каждый потенциальный компонент метода станет компонентом метода описания метода.
• Описание метода. Построен прототип архитектуры метода, в котором содержатся все важные компоненты структуры (плагины метода, а именно, пакеты, компоненты и конфигурации метода) и отношения между ними. По возможности он усиливает существующие ресурсы. Частично может быть описано проектное решение метода (Method Design). Проектное решение метода содержит незначительные структурные компоненты и отношения между ними.
• Описания компонентов метода. Созданы черновые описания компонентов метода, либо непосредственно в RMC, либо с помощью любого другого редактора. Полностью созданы и проанализированы описания важных компонентов метода.
• Web-сайт метода. Было сгенерировано один или несколько Web-сайтов для изучения важных аспектов метода и оценки пригодности к использованию.
• Визуализация (Vision). Детализирована визуализация на основе новой информации, полученной на данной стадии, и, таким образом, достигнуто твердое понимание наиболее важных требований, которые, в свою очередь, управляют решениям по планированию и архитектуре.
• План проекта. План проекта обновлен и расширен до стадий построения и внедрения. План итераций для первой итерации стадии построения завершен и проанализирован. Созданы черновые варианты последующих итерации стадии построения. Обновлены и проанализированы риски.

Основные задачи, выполняемые во время стандартной итерации стадии проектирования

Рабочие продукты стадии проектирования, которые являются специфичными именно для разработки метода, генерируются в результате выполнения задач, показанных на рисунке 4. Обратите внимание, что могут присутствовать и другие задачи и рабочие продукты (например, для того, чтобы протестировать Web-сайт). Здесь приведен минимальный рекомендуемый набор. Выполнение задач, показанных на рисунке 4, должно управляться понятной визуализацией и планом проекта, независимо от их уровня формализации. В основном рецензентами метода являются люди одного круга и специалисты в данной области. Однако к оценке метода рекомендуется привлекать и других заинтересованных лиц, например, пользователей и заказчиков, для того, чтобы убедиться, что метод отвечает требованиям всех заинтересованных сторон.

Рисунок 4: Основные задачи стадии разработки вместе с сопутствующими ролями и входными/выходными рабочими продуктами

В таблице 5 приведено описание задач структурного метода.

Таблица 5: Описание задач структурного метода

Задача: Структурный метод

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

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

Стадия построения

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

Цели стадии построения

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

Критерии оценки стадии построения

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

Если проект не будет удовлетворять данному критерию оценки, то стадию внедрения придется отложить.

Состояние ключевых рабочих продуктов на заключительном этапе стадии построения

• Описание метода. Полностью определено проектное решение метода (Method Design), которое включает в себя структурные компоненты (плагины метода, включая пакеты и компоненты метода, и конфигурации метода) и отношения между ними.
• Описания компонентов метода. Описания компонентов метода завершены и проанализированы, то есть все они находятся в RMC.
• Web-сайт метода. Создан Web-сайт, охватывающий весь метод целиком. Он был протестирован на наличие дефектов, например, неработающих ссылок или проблем с удобством использования.
• План проекта. План итераций для первой итерации стадии внедрения завершен и проанализирован. Созданы черновые варианты последующих итерации. Обновлены и проанализированы риски.

Основные задачи, выполняемые во время стандартной итерации стадии построения

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

Рисунок 5: Основные задачи стадии построения вместе с сопутствующими ролями и входными/выходными рабочими продуктами

Стадия внедрения

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

Цели стадии внедрения

Основная цель стадии внедрения - предоставление качественного метода пользователям.

Критерии оценки стадии внедрения

На завершающем этапе стадии внедрения проект оценивается по следующему критерию: метод был развернут для сообщества пользователей и пользователи довольны.

Окончание проектирования может быть отложено в том случае, если проект не удовлетворяет данному условию.

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

Состояние ключевых рабочих продуктов на последних этапах стадии внедрения

• Описание метода. Плагины метода (включая описания компонентов метода) и конфигурации метода закончены в соответствии со всеми требованиями. Учтены все рекомендации рецензентов.
• Web-сайт метода. Создан Web-сайт, охватывающий весь метод (устранены проблемы, выявленные во время тестирования).

Основные задачи, выполняемые во время стандартной итерации стадии внедрения

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

Рисунок 6: Основные задачи стадии внедрения с сопутствующими ролями и входными/выходными рабочими продуктам

Заключение

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

Данный подход реализуется и совершенствуется уже в течение нескольких лет и будет совершенствоваться и дальше, с точки зрения набора проектов различной величины: от абсолютно простых расширений RUP, обращающихся к конкретной технологии посредством инструментальных наставников (например, RUP для IBM Rational Software Architect), до очень сложных расширений, обращающихся к определенным доменам посредством различных руководств, дополнительных компонентов контента и модифицированного жизненного цикла (например, RUP для COTS). Данный подход описывался при реализации RUP для System z, который соответствует стандартной деятельности по разработке метода среднего или высокого уровня сложности (пять человек в команде разработчиков проекта, график реализации проекта - 14 недель, результат - 1 плагин, 1 конфигурация и около 8 новых компонентов контента и процесса).

Представленный подход в настоящее время задокументирован как RMC-метод Method Authoring Method Basic (MAM Basic). Данная статья является первой попыткой формализовать процесс разработки метода, который реализуется группой разработчиков RUP. Так как интерес к разработке метода постоянно растет, то, вероятно, в ближайшем будущем появятся и другие руководства, написанные сообществом разработчиков методов и описывающие различные вопросы, например, архитектуру метода, управление сборкой или конфигурацией метода.