Главная » UML » Кто использует Rational Unified Process

0

 

К концу 1999 года Rational Unified Process применяли многие (более тысячи) компании. Он использовался в различных прикладных областях, в больших и малых проектах, что доказывает его универсальность и широкую применимость. Назовем лишь несколько отраслей и компаний, разбросанных по всему миру, в которых применяется Rational Unified Process.

•       Телекоммуникация: Ericsson, Alcatel, MCI

•       Транспорт, авиационно-космическая отрасль, оборонная промышленность:
Lockheed-Martin, British Aerospace

•        

•       Промышленность: Xerox, Volvo, Intel

•       Финансы: Visa, Merrill Lynch, Schwab

•       Интеграторы систем: Ernst & Young, Oracle, Deloitte & Touche

Большинство из указанных компаний используют Rational Unified Process в электронной коммерции или собираются это сделать в обозримом будущем. Похоже, что в нашей промышленности постепенно начинают назревать перемены: по мере увеличения напряженности рынка и спроса на качественные продукты, компании перенимают чужой опыт и прислушиваются к полезным советам.

Все эти компании по-разному используют Rational Unified Process. Некоторые делают это формально; они развивают собственные процессы на базе Rational Unified Process и строго их придерживаются. Другие же применяют Rational Unified Process более свободно, считая его всего лишь источником советов, шаблонов и руководств, подобных электронному руководству по разработке программного обеспечения.

Структура процесса: два измерения

На рис. 2.2 показана общая архитектура Rational Unified Process. В процессе можно выделить две структуры, или, если желаете, два измерения.

 

•       Горизонтальная ось представляет время и показывает развитие различных
аспектов жизненного цикла процесса.

•       Вертикальная ось представляет основные технологические процессы, логичес
ки объединяющие виды деятельности по их природе.

Первое измерение представляет динамическую сторону процесса, т.е. показывает, как процесс происходит. Это выражается через циклы, фазы, итерации и вехи. Подробнее эти вопросы рассматриваются в главе 4, "Динамическая структура: итеративная разработка" и в главе 7, "Технологический процесс управления проектом".

Второе измерение представляет статическую сторону процесса: его описание через компоненты процесса, виды деятельности, технологические процессы, артефакты и исполнители. Эти вопросы рассматриваются в главе 3, "Статическая структура: описание процесса".

Лучшие советы по разработке в Rational Unified Process

В данном разделе пересматриваются советы, предложенные Грейди Бучем в главе 1, и определяется, как они реализованы в Rational Unified Process. Впрочем, отметим, что, кроме следования этим советам, Rational Unified Process имеет и многие другие преимущества, позволяющие оптимально реализовать процесс разработки программного обеспечения.

Итеративная разработка

Итеративный подход, рекомендуемый Rational Unified Process, лучше линейного, или водопадного, по следующим причинам.

•       Он позволяет учитывать меняющиеся требования. Дело в том, что требова
ниям свойственно меняться. Меняющиеся требования и "дрейф" требований всегда
были главными источниками неприятностей,  которые  привели  к поздней  сдаче
проекта, несоответствию графику работ, неудовлетворенным заказчикам и разоча
рованным разработчикам.

•       Интеграция в Rational Unified Process — это не совсем "большой взрыв" в конце,
а скорее постепенная сборка элементов. Такой итеративный подход — это процесс
практически непрерывной интеграции. То, что раньше составляло длительный этап
(и  занимало  до  40%  работ  в  конце  проекта),  теперь  разбито  на 6-9  меньших
составляющих, в каждую из которых требуется объединить уже значительно меньшее
число компонентов.

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

•        

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

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

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

•       В процессе работы разработчики могут накапливать опыт, и их разнообразные
способности и специализации будут использованы полнее в течение всего жизненного
цикла  проекта.   При  таком   подходе   с   самого   начала  могут   быть   задействованы
испытатели,   технические   редакторы   и   другие   исполнители.   При   неитеративной
разработке они ожидали бы начала своей работы, просто строя план за планом. Что
может тестировать испытатель, если продукт состоит из метра проектной документа
ции на полке? Необходимость переподготовки или потребность в дополнительных
сотрудниках обнаруживается на ранних этапах проекта, в процессе оценочных обзоров.

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

Руководители проекта часто пренебрегают итеративным подходом, считая его чем-то сродни бесконечной, неуправляемой и нудной работе. Однако необходимо отметить, что в Rational Unified Process итеративный подход весьма управляем; число итераций, их продолжительность и цели определяются заранее. Кроме того, заблаговременно устанавливается, кто чем занимается и кто за что отвечает. Определены объективные критерии состояния процесса. Да, при переходе от одной итерации к другой существует возможность переработки сделанного, но даже это тщательно контролируется.

Подробнее об итеративном подходе рассказывается в главе 4, а в главе 7 описываются принципы управления итеративным процессом и, в частности, рассказывается, как планировать этот процесс.

 

Управление требованиями

Управление требованиями— это упорядоченный подход к выявлению, упорядочению, связи меняющихся требований, а также управлению ими в преимущественно программной системе или приложении.

Давайте рассмотрим некоторые особенности эффективного управления требованиями.

•     Лучший контроль над сложными проектами

Для вышедших из-под контроля проектов характерно непонимание поведения разрабатываемой системы и "дрейф" требований.

Ш    Более качественное программное обеспечение и довольные пользователи

Основной критерий качества— выполняет ли система то, для чего она была предназначена. Это можно определить только тогда, когда все заинтересованные стороны четко представляют, что должно создаваться и тестироваться.

•     Снижение стоимости проекта и задержек его реализации

Исправление ошибок в требованиях обходится довольно дорого; следовательно, уменьшение числа таких ошибок на ранних стадиях проекта снижает стоимость проекта и предупреждает задержки.

•     Улучшение связи в команде

Управление требованиями способствует привлечению пользователей на ранних этапах проекта, что помогает согласовать требования пользователей с возможностями приложения. Грамотное управление требованиями позволяет полностью понять, что должен дать проект, и донести это до всех заинтересованных сторон: пользователей, заказчиков, руководителей, конструкторов и испытателей.

К рассмотренному выше мы еще вернемся в главе 9, "Технологический процесс управления требованиями", где данные свойства Rational Unified Process будут пересмотрены и расширены. В главе 13, "Технологический процесс управления конфигурацией и изменениями", будут описаны различные аспекты, касающиеся отслеживания изменений.

Архитектура и использование компонентов

Хотя всем жизненным циклом Rational Unified Process управляют прецеденты, в основе всех проектных действий лежит другое понятие — архитектура (либо архитектура системы, либо, для преимущественно программных систем, архитектура системы программного обеспечения). Основное внимание при первых итерациях процесса обращается на создание и утверждение архитектуры системы программного обеспечения, которая в исходном цикле разработки принимает форму реализуемого архитектурного прототипа, постепенно (итерация за итерацией) эволюционирующего в окончательную систему.

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

 

Rational Unified Process предлагает систематический, упорядоченный подход к проектированию, разработке и утверждению архитектуры. Этот процесс предоставляет шаблоны для описания архитектуры, основанные на понятии множественных архитектурных представлений. Он предусматривает установление архитектурного стиля, правил проектирования и ограничений. Проектный компонент процесса включает конкретные виды деятельности, направленные на определение архитектурных ограничений и архитектурно значимых элементов, а также директивы по правилам архитектурных компромиссов. Процесс управления показывает, как при планировании начальных итераций принимать во внимание эскиз архитектуры и методы разрешения основных технических рисков.

Программный компонент можно определить как нетривиальную часть программного обеспечения (модуль, пакет или подсистему), выполняющую понятную функцию, четко очерченную, поддающуюся интеграции в однозначную архитектуру. Это — физическая реализация некоторой абстракции проекта. Модульная разработка может использоваться по-разному.

•    В определении модульной архитектуры указываются, обособляются, проекти
руются, разрабатываются и тестируются однозначные компоненты. Эти компо
ненты  могут  тестироваться  по  отдельности  и  постепенно  объединяться  в

единую систему.

•       Более того, некоторые из этих компонентов могут предусматривать повторное
использование,   особенно   это   относится   к   модулям,   предлагающим   общее
решение различных частных проблем. Как правило,  повторно используемые
компоненты — это большее, чем просто набор утилит или библиотек класса. Они
предоставляют организации основу для повторного использования, увеличивая,
таким образом, общее качество и эффективность программного обеспечения.

•       В последнее время появились коммерчески успешные инфраструктуры, под
держивающие концепцию модульного программного обеспечения, — такие как
технология CORBA (Common Object Request Broker Architecture), Internet,
ActiveX и JavaBeans, — что дало начало индустрии готовых компонентов для
различных приложений. Это позволяет разработчикам покупать и объединять
эти компоненты, не занимаясь самостоятельно их разработкой.

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

Модульная разработка поддерживается и процессом Rational Unified Process.

•       Итеративный подход позволяет разработчикам постепенно выделять компоне
нты и решать, какие из них разрабатывать самостоятельно, какие— использо
вать повторно, а какие — покупать.

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

•        

•       Для упорядочения компонентов и определения связующих звеньев в процессе
анализа и проектирования используются понятия пакетов, подсистем, уровней
и т. п.

•       Тестирование вначале проходят отдельные компоненты, а затем постепенно
увеличивающиеся их наборы.

К вопросам архитектуры и ее руководящей роли в Rational Unified Process мы еще вернемся в главе 5, в которой это понятие определяется и подробно объясняется.

По теме:

  • Комментарии