Как запустить разработку процесса с помощью приложения IBM Rational Method Composer

Из издания Rational Edge: авторами описываются четыре этапа создания полностью адаптированного процесса разработки программного обеспечения на основе библиотек, предоставляемых приложением Rational Method Composer.

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

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

• Незнание того, с какого места начинать. Следует ли начинать с нулевой черты? Оказывается, иногда хуже начинать, уже имея в наличии некоторые процессы.
• Информационная перегрузка. Часто оказывается так, что для начала разработки процесса необходимо просмотреть много различных источников информации; это вызывает перегрузку статической информацией (документы, документы, документы...).
• Баланс интересов различных владельцев процесса. Различным ролям в организации свойственно придерживаться отличных друг от друга интересов относительно разных сторон разработки процесса и самого процесса в целом.
• Приведение в систему информации, относящейся к процессу. Зачастую бывает очень сложно организовать всю совокупность различных элементов процесса, и ещё сложнее добавлять и поддерживать актуальную информацию о них.
• Ограничения на среду разработки. Статические документы, с которыми необходимо работать вручную, могут затруднить разработку концепции процесса и видение самого процесса, а также относящихся к нему элементов.
• Присущая процессам сложность. Процессам часто присуща обескураживающая сложность, которую нельзя преодолеть без помощи каких-либо инструментальных платформ.

Один из способов справиться с некоторыми из данных проблем - начинать разработку своего процесса с помощью платформы Rational Unified Process®, или RUP®, в качестве основы. Приложение RMC поставляется с библиотекой содержимого стандартных методов, состоящей из подключаемых модулей, которые можно использовать непосредственно из инструментария приложения RMC, и в библиотеку подключаемых модулей приложения RMC включен встроенный подключаемый модуль платформы RUP. В данном документе будет описан один из способов использования существующей библиотеки для запуска разработки процесса. Это простой подход на основе следующих четырех этапов: 1) просмотр библиотеки платформы RUP, 2) создание оперативного плана, 3) анализ недостатков RUP и, наконец, 4) использование функциональной возможности - вариации содержимого приложения RMC для дальнейшей адаптации своего процесса.

Просмотр библиотеки платформы RUP

Приложение RMC поставляется с большим объемом встроенного содержимого процессов. Как и в случае любой другой среды разработки, перед тем, как овладеть работой в ней, необходимо ознакомиться с доступными библиотеками. Предположим, что необходимо написать программу на языке Java в интегрированной среде разработки. Перед началом кодирования, для ускорения работы сначала необходимо изучить, какие библиотеки необходимо будет использовать. Таким образом, можно написать более эффективный программный код, зная, что необходимо дополнить или реализовать. Аналогично, в приложении RMC, перед созданием процесса, необходимо ознакомиться с контентом процесса, который поставляется в виде подключаемых модулей в составе упомянутой выше библиотеки стандартных методов. Подключаемый модуль состоит из двух ветвей: метода (пакет Method Content) и процесса (пакет Processes), как показано на рис. 1.

Рис. 1. Подключаемые модули библиотеки методов RMC

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

Использование подключаемых модулей в приложении RMC облегчается с помощью базового подключаемого модуля. Например, если выбрать подключаемый модуль rup_soa_plugin и дважды щелкнуть по нему, в области Referenced Plug-ins отобразятся дополнительные подключаемые модули, на которые ссылается подключаемый модуль rup_soa_plugin. В данном случае можно видеть, что его основой являются подключаемые модули rup и rup_bm.

Теперь, после просмотра библиотеки содержимого методов RMC, можно создать свой собственный подключаемый модуль метода в качестве основы. В таком случае, платформа RUP будет использоваться как основа для создания процесса управления проектом разработки программного обеспечения. Чтобы начать, следует щелкнуть правой кнопкой мыши на отображение библиотеки методов. Выбрать в контекстном меню New Method Plug-in. В окне New Method Plug-in присвоить подключаемому модулю имя acme software project management. Окно примет вид, показанный на рис. 2.

Рис. 2. Подключаемый модуль "процесса управления проектом разработки программного обеспечения"

Создание оперативного плана

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

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

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

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

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

После рассмотрения поэтапного оперативного плана с основными заинтересованными сторонами данное описание преобразуется в plug-in "процесса управления проектом разработки ПО". В RMC это достаточно простой процесс. Для этого необходимо:

1. Перейти к подключаемому модулю процесса управления проектом
2. Развернуть группу Method Content и правой кнопкой мыши щелкнуть на пункте Content Packages
3. Выбрать New--"Content Package. В поле Name ввести Guidance
4. Перейти к меню File--"Save All
5. Развернуть пакет контента Guidance. Станет видно, что приложением RMC уже автоматически наполнены группы Roles, Tasks, Work Products и Guidance. Этим можно воспользоваться для того, чтобы сгруппировать те элементы, которые относятся к пакету plug-in-а Guidance
6. Чтобы создать оперативный план, следует щелкнуть правой кнопкой мыши на элемент Guidance в пределах группы содержимого Guidance. Приложением RMC предоставляется контекстное меню с различными типами руководств, которые здесь можно создать
7. Выбрать New--"Roadmap
8. В поле Name ввести software_pm_process_roadmap. Это имя файла, связанного с данным оперативным планом
9. В поле Presentation Name ввести Software Project Management Process Roadmap. Это имя файла для представления, которое отображается при просмотре данного оперативного плана

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

Рис. 3. Предварительный просмотр оперативного плана управления проектом по программному обеспечению

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

Оперативные планы могут принимать различные формы. Перед началом написания собственных оперативных планов следует перейти к библиотеке подключаемых модулей методов, чтобы воспользоваться примерами, такими как rup, rup_legacy_evol_plugin, rup_j2ee_plug-in, rup_soa_plugin и rup_ux_modeling_plugin.

Выполнение анализа различий с платформой RUP

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

Таблица 1. Отображение результатов работы.

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

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

Использование вариации контента

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

Таблица 2. Типы вариаций.

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

1. Перейти к подключаемому модулю процесса управления проектом разработки ПО в окне Library View.
2. Развернуть группу Method Content и правой кнопкой мыши щелкнуть пункт Content Packages.
3. Выбрать New--"Content Package. В поле Name ввести Software Project Management.
4. Перейти к меню File--"Save All.
5. Развернуть группу контента Software Project Management. Станет видно, что приложением RMC уже автоматически наполнены группы Roles, Tasks, Work Products и Guidance. Этим можно воспользоваться для того, чтобы сгруппировать те элементы, которые относятся к группе подключаемых модулей Guidance.
6. Чтобы добавить план разработки программного обеспечения платформы RUP и использовать его в своем процессе, следует щелкнуть правой кнопкой мыши на элементе Work Product в группе контента Software Project Management. Приложением RMC предоставляется контекстное меню с различными типами результатов работы в форме эталонных документов, отчетов или итоговых результатов. Так как план разработки программного обеспечения платформы RUP, который необходимо добавить, представляет собой эталонный документ, нужно выбрать New--"Artifact.
7. В поле Name ввести sw_development_plan. Оставить незаполненным поле Presentation Name. (Так как дополнения вносятся в план разработки программного обеспечения платформы RUP, будет сохранено имя для представления эталонного документа платформы RUP.)
8. Прокрутить вниз меню sw_development_plan до пункта Content Variability. В выпадающем меню типов Variability выбрать Contributes.
9. В поле Base ниже выбрать кнопку Select. (Для удобства, в окне Select Artifacts Dialog щелкнуть кнопку Collapse All.)
10. Далее развернуть подключаемый модуль RUP и развернуть группу Management, а затем развернуть группу Project Planning. Выбрать эталонный документ rup_software_development_plan и щелкнуть Ok.
11. Теперь любой текст, введенный в любое поле собственного эталонного плана разработки программного обеспечения будет добавляться к концу текста плана разработки программного обеспечения платформы RUP. Попробовать далее набрать, только для примера, "Данный план является всеобъемлющим планом всей разработки программного обеспечения." в поле Main Description своего эталонного документа. Щелкнуть Save All.

Теперь имеется в наличии план разработки программного обеспечения для собственного процесса, в котором есть все из плана разработки программного обеспечения платформы RUP плюс собственный дополнительный контент из поля Main Description. (Примечание: Чтобы посмотреть, как приложением RMC интерпретируется такое изменение контента, необходимо переключиться в режим Browsing. Данная операция выходит за пределы тематики данной статьи.)

Следующие этапы

Приложением RMC явно различаются понятия метода и процесса. Содержимое метода - ответ на вопросы "Что будет производиться?" "Кто ответственный и какие навыки необходимы?" "Как будут представляться результаты работы?" К понятию процесса относится вопрос "когда?" - другими словами, каким образом элементы контента метода временно связываются в полуупорядоченные последовательности.

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

Заключение

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

Об авторах