Особенности применения RUP

Основной упор в RUP делается не на подготовку документов как таковых, а на моделирование разрабатываемой системы.

Модели помогают очерчивать как проблему, так и пути ее решения, и создаются они при помощи унифицированного языка 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 в виде готовых шаблонов, облегчающих их создание в конкретном проекте. В базу включены шаблоны более тридцати документов, для большинства распространенных типов отчетов представленные в форматах MS Word и Adobe FrameMaker. Шаблоны Rational SoDa позволяют автоматизировать процесс сбора документов из множества источников, а шаблоны RequisitePro облегчают управление требованиями. В помощь специалистам, занимающимся планированием итеративных проектов на основе RUP, в него включены шаблоны Microsoft Project. Также доступны шаблоны формата HTML, позволяющие расширять базу знаний.

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

Таким образом, эта методология направлена на снижение коммерческих рисков (risk mitigating) посредством обнаружения ошибок на ранних стадиях разработки. Технические риски (assesses) оцениваются и «расставляются» согласно приоритетам на ранних стадиях цикла разработки, а затем пересматриваются с течением времени и с развитием проекта в течение последующих итераций. Новые цели появляются в зависимости от приоритетов данных рисков. Релизы версий распределяются таким образом, что наиболее приоритетные риски устраняются первыми.

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

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

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