Клуб разработчиков программных систем

Темы | Статьи | Рейтинги |

Унифицированный процесс разработки от Rational Software

Сергей Трофимов

PCWeek/RE, №4/2003

        

        Разработка программных продуктов, еще недавно бывшая уделом избранных одиночек, в настоящее время превратилась в высокодоходную сферу бизнеса. В ИT-проектах заняты миллионы программистов и аналитиков, руководителей разного ранга и простых инженеров по всему миру. Процесс создания программных систем стал технологией, где у каждого члена проектной команды определено свое место и круг обязанностей, где строго регламентированы все этапы — от замысла до передачи пользователям рабочей версии программы. Это единственный путь к созданию больших и малых программных систем, который позволяет уложиться в установленные сроки и выделенный бюджет, создав при этом систему нужного качества.
        Хотя индустрия разработки ПО достаточно молода, многие компании-разработчики уже осознали, что успех программных проектов зависит от однозначного определения и грамотного документирования процесса. Корпорация Rational Software (www.rational.com), ведущий производитель инструментария для создания сложных программных систем, формализовала технологический процесс разработки ПО и выпустила на рынок структурированную базу знаний под названием Rational Unified Process (RUP), в которую вошли методические рекомендации ведущих разработчиков по эффективному созданию приложений и систем. При этом RUP не есть нечто застывшее. База знаний регулярно обновляется и совершенствуется с учетом передового опыта.

Rational Unified Process Overview (фазы и процессы RUP)
Фазы и процессы RUP

        RUP создана в виде страниц формата HTML, имеющих обширную систему гиперссылок, графическую навигацию, подробное оглавление и встроенный поисковый механизм. База распространяется на компакт-дисках и посредством сети Интернет. Последняя версия продукта всегда доступна на сайте производителя. Там же можно бесплатно ознакомиться с полнофункциональной тридцатидневной пробной версией для принятия решения об ее использовании и просмотреть деморолик. Вместе с самой базой предоставляется книга Ф. Крачтена (Ph. Kruchten) “Rational Unified Process — an Introduction”, облегчающая погружение в RUP (в прошлом году она вышла в русском переводе*).
        RUP поддерживает технологию разработки программных продуктов для различных платформ, предоставляет детальные рекомендации команде программистов как по переходу к разработке на платформе Microsoft .NET, так и по самой этой разработке. Также поддерживается плагин WinDNA для тех, кто не собирается переходить на платформу .NET
        Возможна и разработка ПО для платформы Java 2 Enterprise Edition (J2EE). Доступны плагины для использования платформ IBM WebSphere, BEA WebLogic и HP Bluestone Total e-Server. Последний был включен в версию RUP 2002 и в текущем виде не был доступен в предыдущих версиях продукта.
        RUP ведет свою историю от продуктов Rational Approach и Objectory Process 3.8, объединение которых произошло после слияния в 1995 г. корпораций Rational Software и Objectory AB.
        Сейчас больше тысячи компаний воспользовались преимуществами разработки на основе RUP. Унифицированный процесс разработки используется в различных прикладных областях, в больших и малых проектах, что доказывает его универсальность и широкую применимость. В телекомунникационной сфере его используют Ericsson, Alcatel, MCI, в авиационно-космической и оборонной промышленности — Lockheed-Martin, British Aerospace, на промышленных предприятиях — Xerox, Volvo, Intel, в финансовой сфере — Visa, Merrill Lynch, Schwab. Этот процесс также взят на вооружение такими интеграторами, как Ernst & Young, Oracle, Deloitte & Toucche.

Процесс анализа проблемы в RUP
Процесс анализа проблемы

        Каждая из этих компаний использует RUP по-своему. Одни строго следуют всем рекомендациям Rational Software, другие же создают на его основе свои методики, прибегая к этой базе знаний как к источнику советов, шаблонов и руководств.
        Основными понятиями RUP являются артефакт (artifact) и прецедент (precedent). Артефакты — это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом. Прецеденты — это последовательности действий, выполняемых системой для получения наблюдаемого результата.
        Весь процесс разработки программной системы рассматривается в RUP как процесс создания артефактов. Причем то, что попадает в руки конечного пользователя, будь то программный модуль или программная документация, — это один из подклассов всех артефактов проекта.
        Каждый член проектной группы создает свои артефакты и несет за них ответственность. Программист разрабатывает программу, руководитель — проектный план, а аналитик — модели системы. RUP позволяет определить, когда, кому и какой артефакт необходимо создать.
        Основной упор в RUP делается не на подготовку документов как таковых, а на моделирование разрабатываемой системы. Модели помогают очерчивать как проблему, так и пути ее решения, и создаются они при помощи унифицированного языка Unified Modeling Language (UML), предложенного компанией Rational и впоследствии утвержденного OMG как стандарт, но еще до это UML стал стандартом де-факто для описания сложных систем и позволяет разработчикам определять, визуализировать, конструировать и документировать артефакты программных систем.
        Все задачи, описанные в RUP, поддерживаются средствами разработки от Rational Software. В RUP включен раздел Tool Mentors, в котором подробно описывается использование Rational Rose для создания UML-моделей, Rational RequisitePro, Rational Clear Quest, Rational Clear Case для анализа требований, запросов на измерения и исправления дефектов и для поддержки процесса унифицированного управления изменениями (UCM). В этом же разделе описываются методы применения Rational Purify, Rational PureCoverage, Rational Quantify, Rational Robot для автоматизации процесса тестирования и поиска дефектов программного обеспечения, а Rational SoDa — для автоматизации процесса документирования. Кроме того, Tool Mentors содержит подробные рекомендации по использованию этих и других средств компании Rational для создания конкретных артефактов разрабатываемой системы.

Процесс определения требований в RUP

        Весь процесс разработки с точки зрения RUP рассматривается в двух плоскостях. В динамике процесс выражается через циклы, фазы, итерации и вехи, а в статике — через виды деятельности, технологические процессы, артефакты и роли исполнителей.
        Каждый такой процесс представляется при помощи диаграмм, состоящих из пиктограмм, связанных гиперссылками с другими документами. При активизации гиперссылок происходит детализация процесса.
        Это дает возможность пройти через всю последовательность необходимых работ — от общего взгляда на них “с высоты птичьего полета” до создания конкретных артефактов.
        Система гиперссылок построена таким образом, что можно легко переходить от работ к артефактам, создаваемым в процессе конкретной деятельности, а через них к ролям исполнителей и обратно. К артефактам можно добраться различными путями — например, через список процессов, примеры итераций, роли исполнителей, а можно просто найти нужный артефакт в дереве ссылок, что позволяет рассматривать один и тот же процесс разработки с различных точек зрения — руководителя и исполнителя, пользователя и программиста.
        Основные артефакты, создаваемые в процессе разработки, представлены в RUP в виде готовых шаблонов, облегчающих их создание в конкретном проекте. В базу включены шаблоны более тридцати документов, для большинства распространенных типов отчетов представленные в форматах MS Word и Adobe FrameMaker. Шаблоны Rational SoDa позволяют автоматизировать процесс сбора документов из множества источников, а шаблоны RequisitePro облегчают управление требованиями. В помощь специалистам, занимающимся планированием итеративных проектов на основе RUP, в него включены шаблоны Microsoft Project. Также доступны шаблоны формата HTML, позволяющие расширять базу знаний.

Работы системного аналитика в RUP

        Ответственность за создание артефактов лежит на исполнителях. В последних версиях RUP чаще применяется понятие роль, поскольку один исполнитель может выполнять несколько ролей в проекте и отвечать за различные артефакты. В RUP определено более тридцати ролей, которые могут выполнять различные члены команды разработчиков. Обязанности каждой роли, последовательность работ и создаваемые артефакты представлены в виде понятных с первого взгляда диаграмм. Например, на рис. показана схема обязанностей системного аналитика, так как она определяется в RUP.
        И конечно же каждая пиктограмма на этой схеме представляет собой гиперссылку, позволяющую производить дальнейшую детализацию.
        RUP достаточно обширен. Это набор рекомендаций и примеров по всем стадиям и фазам разработки программ. Хотя в основу этих рекомендаций положен многолетний опыт разработки программных систем, не для каждого проекта RUP подходит на сто процентов. Любой программный проект по-своему уникален. Нельзя бездумно копировать чужой процесс, создавая артефакты, имеющие незначительную ценность. Во многих небольших организациях по разработке программного обеспечения, особенно в тех, что не имеют собственной мощной системы разработки, RUP можно использовать “как есть”, но он может быть и уточнен, расширен и специфически настроен для максимального приближения к нуждам организации-разработчика.
        Но в любом случае применение унифицированного процесса разработки позволит уменьшить затраты проекта, уложиться в заданные сроки и повысить качество создаваемого программного продукта.

        * Крачтен Филипп. Введение в Rational Unified Process. — 2-e изд.: Пер. с англ. — M.: Издательский дом “Вильямс”, 2002. — 240 с.

Вы можете заказать книги о RUP здесь >> 

Статьи по теме:

Риски программных проектов
Что такое проект?
Распространенные ошибки стратегического планирования
Общие принципы построения команды проекта при внедрении ERP-системы
Ваш проект может рухнуть в любое время, если...

Связанные темы:
Ведение проектов
Процесс разработки программ
| 1 |


| 1 |
Комментарии к статьям закрыты.

© Trofimov Sergey   http://www.caseclub.ru при цитировании ссылка обязательна.