Путеводитель по разработке методов (Rational Edge)Источник: IBM developerWorks Россия
На протяжении десяти лет команда 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). Однако данный подход не решает сложной задачи объединения нескольких существующих методов в один общий метод. Кроме того, он не предназначен для прямой адаптации, 4 например, модификации уже существующего метода для заданного проекта на основе адаптации структуры последовательности действий или плана проекта. Разработка методов в сравнении с разработкой программного обеспечения Основные принципы бизнес-ориентированной разработки, определенные Пером Кроллом (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-сайт нового метода. Новые элементы метода могут быть созданы с нуля или посредством усиления некоторых компонентов уже существующего метода, используя отношения вариативности (например, вклад, расширение или замена). А теперь наступило время определить пару терминов, которые я упоминала раньше:
В RMC структурными элементами являются: плагины метода, пакеты метода, элементы метода и конфигурации метода. Обратите внимание, что для создания архитектуры метода и плана метода не требуются никакие новые рабочие продукты, так как они явно определяются в RMC в рабочем продукте описания метода. По крайней мере до тех пор, пока проектная группа не придет к выводу о необходимости собрать их в отдельные рабочие продукты, например, документацию по архитектуре или визуальную модель, что зачастую происходит при определении сложных методов. Вспомогательные рабочие продукты Помимо тех основных рабочих продуктов, характерных для разработки метода, которые были рассмотрены выше, и, невзирая на тот факт, что описываемый в данной статье подход нацелен на разработку самого метода, а не документации по проекту, возникают ситуации, когда определенную пользу разработке может принести создание вспомогательных рабочих продуктов. В данном разделе будут представлены некоторые продукты, которые, хотя и не характерны для разработки метода, все же доказали свою пользу в поддержке проектно-конструкторских работ различных масштабов. Аналогичные рабочие продукты можно обнаружить и в других методах, например, в OpenUP/Basic 7 или RUP. Степень формализации данных вспомогательных рабочих продуктов зависит от многих факторов, например, сложности проекта, традиций организации-разработчика и динамики управления проектом. Так как каждому проекту необходим источник, из которого можно узнать потребности заинтересованной стороны, объемы проекта, все требования и ограничения, то рекомендуется отразить данную информацию в документе Vision. Этот документ может служить соглашением между заказчиком и организацией-разработчиком. Поскольку я искренне верю в преимущества итеративного и учитывающего риски подхода к разработке метода, то для эффективной реализации проекта я рекомендую использовать план проекта (Project Plan). План проекта определяет стадии и этапы проектирования. Он может содержать и план итераций (Iteration Plan) для описания особенностей каждой итерации (например, в терминах задач с назначенными ресурсами), и оценку итераций (Iteration Assessment) для оценивания результатов итерации и внесения необходимых промежуточных корректив, а также перечень рисков (Risk List) для выявления и определения приоритетов рисков, и описания действий по предупреждению последствий или поведения в непредвиденных ситуациях. В таблице 3 перечислены все рабочие продукты, которые рекомендуются для обеспечения разработки метода.
Путеводитель по разработке метода Представленный в данной статье подход к разработке метода основан на 4 стадиях RUP: начало (Inception), проектирование (Elaboration), построение (Construction) и внедрение (Transition). В данном разделе мы пройдем по всем стадиям типичного проекта. В данном разделе будет описана начальная стадия разработки метода в терминах первичных целей, критериев оценки, состояния ключевых рабочих продуктов по окончании стадии и главных задач. Цели начальной стадии Первоочередными целями начальной стадии являются: достижение согласия относительно задач проектирования между всеми заинтересованными сторонами и принятие решения о праве проекта на существование. Критерии оценки начальной стадии В конце начальной стадии проектирования проект следует оценить по следующим критериям:
Если проект не удовлетворяет данным критериям, то он может быть отклонен или пересмотрен. Состояние ключевых рабочих продуктов по окончании начальной стадии
Ключевые задачи, выполняемые во время стандартной итерации начальной стадии Рабочие продукты начальной стадии создаются путем решения задач, показанных на рисунке 3. Обратите внимание, что могут ставиться и другие задачи и использоваться другие рабочие продукты (например, для установки среды разработки метода или обучения проектной группы). Однако мы описали минимальный рекомендуемый набор. На рисунке 3 роль заинтересованной стороны иллюстрирует то, что информация, полученная от заинтересованных лиц, например, заказчиков, пользователей и других специалистов в данной области, управляет всеми задачами начальной стадии, чтобы гарантировать, что проектная группа разрабатывает правильный метод и укладывается в сроки и бюджет.
Рисунок 3: Ключевые задачи начальной стадии вместе с их ролями и входными/выходными рабочими продуктами В таблице 4 представлено описание задачи эскиза метода. Задача не зависит от фактической стратегии, выбранной проектной группой для описания метода, например, сверху вниз (определение полного жизненного цикла с точки зрения стадий и их целей управляет определением компонентов контента) или снизу вверх (определение компонентов контента управляет определением жизненного цикла). На практике проектная группа обычно использует комбинацию из этих двух стратегий. Однако я бы порекомендовала по возможности отдавать предпочтение стратегии "снизу вверх", так как она позволяет создавать более связные методы, а именно, более очевидной становится связь каждого элемента контента с одной или несколькими целями стадии. Например, ядро метода RUP для System z 8 по большей части было определено стратегией "сверху вниз", в рамках группового поиска идей, который происходил целыми рабочими днями в течение двух недель. Результаты данного мозгового штурма были задокументированы в эскизе метода. Во-первых, пользователей z попросили изучить все стадии RUP и определить, какие изменения следует внести в его основные задачи и разработанную документацию для того, чтобы удовлетворить какие-либо конкретные потребности среды z. Это позволило проектной группе определить начальный набор рабочих продуктов (например, процедуры проверки установки и модулей), который необходимо добавить в RUP для удовлетворения потребностей специалистов z и для достижения согласия относительно того факта, что цели основных стадий RUP применимы к z. Во-вторых, пользователей z попросили описать типичные действия высокого уровня, которые выполняются ими в настоящее время и которые позволят решить задачи, поставленные перед каждой стадией. Это позволило группе разработчиков определить для каждой стадии типичные итерации в терминах последовательности или сочетания действий высокого уровня. В-третьих, пользователей z попросили дать подробное описание каждого действия с точки зрения группировки задач (и возможные промежуточные действия), выполняемого ответственным лицом (ролью) и создающего рабочие продукты, - это было реализовано усилением как можно большего числа существующих компонентов RUP. Данная деятельность позволила группе разработчиков определить круг задач (например, модульный проект и процедуры проверки установки) и имеющие отношение роли и рабочие продукты, которые необходимо добавить в RUP for z. Результатом данной стратегии является определение непрерывного процесса, описывающее технологии разработки ПО, используемые в настоящее время в среде z и усиливающие некоторые задачи, роли, рабочие продукты, действия и передовой опыт, воплощенные в RUP. Кроме того, данная стратегия дает гарантию того, что каждый компонент метода явно связан с одной или несколькими целями стадии.
В данном разделе описана стадия проектирования с точки зрения ее основных целей, критериев оценки, состояния на этапе завершения стадии основных рабочих продуктов и важных задач. Цели проектирования Основная цель стадии проектирования заключается в построения прототипа архитектуры метода (Method Architecture) для того, чтобы предоставить стабильную основу для разработки на стадии проектирования. Устойчивость архитектуры оценивается посредством одного или нескольких Web-сайтов метода. Критерии оценки проектирования На последнем этапе стадии проектирования, проект оценивается по следующим критериям:
Если проект не удовлетворяет данным критериям, то он может быть отклонен или продуман заново. Состояние ключевых рабочих продуктов на заключительном этапе стадии проектирования
Основные задачи, выполняемые во время стандартной итерации стадии проектирования Рабочие продукты стадии проектирования, которые являются специфичными именно для разработки метода, генерируются в результате выполнения задач, показанных на рисунке 4. Обратите внимание, что могут присутствовать и другие задачи и рабочие продукты (например, для того, чтобы протестировать Web-сайт). Здесь приведен минимальный рекомендуемый набор. Выполнение задач, показанных на рисунке 4, должно управляться понятной визуализацией и планом проекта, независимо от их уровня формализации. В основном рецензентами метода являются люди одного круга и специалисты в данной области. Однако к оценке метода рекомендуется привлекать и других заинтересованных лиц, например, пользователей и заказчиков, для того, чтобы убедиться, что метод отвечает требованиям всех заинтересованных сторон.
Рисунок 4: Основные задачи стадии разработки вместе с сопутствующими ролями и входными/выходными рабочими продуктами В таблице 5 приведено описание задач структурного метода.
В данном разделе описана стадия построения проекта разработки метода в терминах главных целей, критериев оценки и состояния важных рабочий продуктов на последних этапах стадии, ключевых задач. Цели стадии построения Основные цели стадии построения заключаются в завершении разработки метода на основе архитектуры прототипа и получении метода, пригодного для производственного применения пользователями. Критерии оценки стадии построения На завершающем этапе стадии построения проект оценивается по следующему критерию: метод должен быть достаточно стабилен и закончен для применения пользователями. Если проект не будет удовлетворять данному критерию оценки, то стадию внедрения придется отложить. Состояние ключевых рабочих продуктов на заключительном этапе стадии построения
Основные задачи, выполняемые во время стандартной итерации стадии построения Рабочие продукты стадии построения, которые являются специфичными именно для разработки метода, генерируются в результате выполнения задач, показанных на рисунке 5. Обратите внимание, что могут присутствовать и другие задачи и рабочие продукты (например, для того, чтобы протестировать Web-сайт). Здесь приведен минимальный рекомендуемый набор. Выполнение задач, показанных на рисунке 5, должно управляться планом проекта, независимо от его уровня формализации, проясняя, какие потребности удовлетворяются на каждой итерации стадии построения, для того, чтобы команда разработчиков могла сконцентрировать свое внимание на достижении результатов настолько быстро, насколько это возможно на данном практическом этапе: творческий этап уже пройден. В основном рецензентами метода являются люди одного круга и специалисты в данной области. Однако к оценке метода рекомендуется привлекать и других заинтересованных лиц, например, пользователей и заказчиков, для того, чтобы убедиться, что метод отвечает требованиям всех заинтересованных сторон.
Рисунок 5: Основные задачи стадии построения вместе с сопутствующими ролями и входными/выходными рабочими продуктами В данном разделе описана стадия внедрения проекта разработки метода в терминах главных целей, критериев оценки и состояния важных рабочий продуктов на последних этапах стадии, ключевых задач. Цели стадии внедрения Основная цель стадии внедрения - предоставление качественного метода пользователям. Критерии оценки стадии внедрения На завершающем этапе стадии внедрения проект оценивается по следующему критерию: метод был развернут для сообщества пользователей и пользователи довольны. Окончание проектирования может быть отложено в том случае, если проект не удовлетворяет данному условию. На последнем этапе стадии внедрения начинается цикл обслуживания метода после официального выпуска. Возможно, потребуется новый цикл, или дополнительные отладочные версии. Состояние ключевых рабочих продуктов на последних этапах стадии внедрения
Основные задачи, выполняемые во время стандартной итерации стадии внедрения Рабочие продукты стадии внедрения, которые являются специфичными именно для разработки метода, генерируются в результате выполнения задач, показанных на рисунке 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. Так как интерес к разработке метода постоянно растет, то, вероятно, в ближайшем будущем появятся и другие руководства, написанные сообществом разработчиков методов и описывающие различные вопросы, например, архитектуру метода, управление сборкой или конфигурацией метода. |