|
|
|||||||||||||||||||||||||||||
|
Как запустить разработку процесса с помощью приложения IBM Rational Method ComposerДжефф Смит, специалист по методологии разработки программного обеспечения
Дан Попеску, разработка содержания платформы RUP Из издания Rational Edge: авторами описываются четыре этапа создания полностью адаптированного процесса разработки программного обеспечения на основе библиотек, предоставляемых приложением Rational Method Composer.
Один из наиболее трудных этапов при разработке процесса - это усилия по его запуску. Некоторые из проблем, с которыми обычно приходится сталкиваться:
Один из способов справиться с некоторыми из данных проблем - начинать разработку своего процесса с помощью платформы 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 и выполняется с помощью конфигурации метода.2 Использование подключаемых модулей в приложении 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 это достаточно простой процесс. Для этого необходимо:
В данный момент можно ввести оперативный план, созданный и утвержденный ранее, прямо в свой процесс, введя его контент в поле 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:
Теперь имеется в наличии план разработки программного обеспечения для собственного процесса, в котором есть все из плана разработки программного обеспечения платформы RUP плюс собственный дополнительный контент из поля Main Description. (Примечание: Чтобы посмотреть, как приложением RMC интерпретируется такое изменение контента, необходимо переключиться в режим Browsing. Данная операция выходит за пределы тематики данной статьи.) Приложением RMC явно различаются понятия метода и процесса. Содержимое метода - ответ на вопросы "Что будет производиться?" "Кто ответственный и какие навыки необходимы?" "Как будут представляться результаты работы?" К понятию процесса относится вопрос "когда?" - другими словами, каким образом элементы контента метода временно связываются в полуупорядоченные последовательности. В следующей статье будет специально рассмотрено, как выполнять следующие этапы разработки размерности метода вместе с размерностью процесса, то есть, шаблоны производительности. Кроме того, будет рассмотрена подготовка к публикации процесса, включая определение представлений через категории клиентов. Заключение Разработка процесса может оказаться сложным предприятием, с уникальными для него проблемами. Несопоставимые источники информации, противоречивые потребности заинтересованных сторон, информационная перегрузка, сложность процессов - это только небольшая часть из всех возможных препятствий в процессе разработки. Инструментарий RMC не разрешит все эти проблемы. Но он упростит работу по запуску разработки с помощью повторного применения подключаемых модулей и методики организации контента. Ссылки по теме
Об авторах Jeff Smith (Джефф Смит) - специалист по методологии разработки программного обеспечения, участвующий в определении направлений для разработки компанией IBM коммерческих методов с акцентом на тестирование и валидацию. Перед поступлением в группу IBM Rational контента коммерческих методов занимался разработкой программного обеспечения в области медицинского оборудования. Джефф имеет степень магистра естественных наук в области анализа, проектирования и внедрения информационных систем Лондонской школы экономики (London School of Economics, LSE).
Дан Попеску (Dan Popescu) - член группы по разработке содержимого платформы RUP. У него девятнадцатилетний опыт разработки программного обеспечения на двух континентах и степень магистра естественных наук в области электротехники. Перед поступлением в подразделение IBM Rational Дан участвовал в разработке систем для производства телекоммуникационного и полупроводникового оборудования, занимал ряд должностей, в том числе разработчик архитектуры программного обеспечения, руководитель группы и инженер-технолог.
|
|