Rational Unified Process (RUP ) – одна из лучших методологий разработки программного обеспечения, созданная в компании Rational Software . Основываясь на опыте многих успешных программных проектов, Унифицированный процесс позволяет создавать сложные программные системы, основываясь на индустриальных методах разработки. Одним из основных столпов, на которые опирается RUP , является процесс создания моделей при помощи унифицированного языка моделирования (UML ). Эта статья о применении диаграмм UML в рабочем процессе разработки программных систем по методологии Rational Software .
Ни для кого не секрет, что создание программного обеспечения – это сложный процесс, который, с одной стороны, имеет много общего с творчеством, а с другой, – хотя и высокодоходный, но и высокозатратный бизнес. Жестокая конкуренция на рынке вынуждает разработчиков к поискуболее эффективных методов работы. Путей создания программных систем в еще более короткие сроки, с меньшими затратами и лучшим качеством. Сложность программ постоянно увеличивается. Еще недавно программные продукты могли быть созданы в обозримые сроки одиночками или, например, в IT -отделе автоматизируемого предприятия.
Сейчас же одиночкам, создающим программы «на коленке» остается область небольших утилит и различных модулей расширения «тяжелых» программных продуктов. Будущее за индустриальным подходом к созданию ПО. В 1913 году Генри Форд запустил первый автомобильный конвейер, а в 90-х аналогичный конвейер стал применяться в сфере IT -технологий. Командная разработка требует совсем другого подхода и другой методологии, которая рано или поздно должна была быть создана.
Корпорация Rational Software (http ://www .rational .com ) выпустила на рынок структурированную базу знаний под названием Rational Unified Process (RUP ), которая представляет собойнабор исчерпывающих рекомендаций для создания практически любых программных продуктов. Вобрав в себя опыт лучших разработок, RUP подробно рассказывает когда, кто и что должен делать в проекте, чтобы в результате получить программную систему с установленные сроки, с определенной функциональностью и в рамках отведенного бюджета.
Унифицированный процесс можно представить как сумму различных видов деятельности компании-разработчика, необходимых для перевода требований заказчика в программную систему. Систему, которая давала бы «значимый результат» пользователям и выполняла бы именно то, что они от системы ожидают. Поэтому процесс управляется вариантами использования (Use Case ) системы, или иначе –прецедентами.
Для реализации требований заказчика в установленные сроки, Унифицированный процесс разделяется на фазы, которые состоят из итераций, поэтому процесс еще называют итеративным и инкрементным. Каждая итерация проходит цикл основных работ и подводит разработчиков к конечной цели: созданию программной системы. В ходе итераций создаются промежуточные артефакты, которые требуются для успешного завершения проекта и вариант программной системы, который реализует некоторый набор функций, увеличивающийся от итерации к итерации. Фазы и основные потоки работ процесса показаны на рис. 1, там же даны примерные трудозатраты работ по фазам.
рис. 1 Фазы и потоки работ RUP
Нужно отметить, что на рис. 1 показаны только основные работы Унифицированного процесса. Например, работы по управлению деятельностью здесь не показаны, чтобы не загромождать диаграмму.
Вся разработка ПО рассматривается в RUP как процесс создания артефактов. Любой результат работы проекта, будь то исходные тексты, объектные модули, документы, передаваемые пользователю, модели – это подклассы всех артефактов проекта. Каждый член проектной группы создает свои артефакты и несет за них ответственность. Программист создает программу, руководитель - проектный план, а аналитик - модели системы. RUP позволяет определить когда, кому и какой артефакт необходимо создать, доработать или использовать.
Одним из интереснейших классов артефактов проекта являются модели, которые позволяют разработчикам определять, визуализировать, конструировать и документировать артефакты программных систем. Каждая модель является самодостаточным взглядом на разрабатываемую систему и предназначена как для очерчивания проблем, так и для предложения решения. Самодостаточность моделей означает, что аналитик или разработчик может изконкретной модели почерпнуть всю необходимую ему информацию, не обращаясь к другим источникам.
Модели позволяют рассмотреть будущую систему, ее объекты и их взаимодействие еще до вкладывания значительных средств в разработку, позволяют увидеть ее глазами будущих пользователей снаружи и разработчиков изнутри еще до создания первой строки исходного кода. Большинство моделей представляются UML диаграммами, подробнее об UML можно прочитать, например в .
Унифицированный язык моделирования (Unified Modeling Language ) появился в конце 80-х в начале 90-х годов в основном благодаряусилиям «трех друзей» Гради Буча, Джима Рамбо и Ивара Якобсона. В настоящее время консорциум OMG принял этот язык как стандартный язык моделирования, который предоставляет разработчикам четкую нотацию, позволяющую отображать модели общепринятымии понятными каждому члену проекта графическими элементами.
Однако не следует забывать, что язык моделирования дает только нотацию – инструмент описания и моделирования системы, а унифицированный процесс определяет методику использования этого инструмента, как впрочем, и других инструментов поддержки методологии от компании Rational . UML можно использовать и без конкретнойметодологии, поскольку он не зависит от процесса и какой бы вариант процесса не был бы применен, вы можете использовать диаграммы для документирования принятых в ходе разработки решений и отображения создаваемых моделей.
Программная система создается для решения определенных проблем пользователя, а не для опробования новых технологийпрограммистами и получения опыта руководителем проекта. По большому счету, пользователю не важно используете ли вы в процессе разработки объектно-ориентированный подход, UML , RUP или создаете систему по методу XP (экстремального программирования) . Применение тех или иных методик, технологий, создание оптимальной внутренней структуры проекта остается на совести разработчиков, которые принимают решения исходя из предыдущего опыта и собственных предпочтений. Однако пользователь не простит вам игнорирование его требований. Будь программная система хоть десять раз разработана при помощи суперсовременных методов и технологий, если пользователь не получит от нее то, что называется «значимым результатом», ваш программный проект с треском провалится.
Из этого следует, что бездумное применение UML , просто потому что это модно, не только не приведет разработку к успеху, но и может вызвать недовольство сотрудников, которым необходимо изучать большое количество дополнительной литературы и руководителей проекта, когда окажется, что трудозатраты на проекте возрастают, а отдача не повышается. Нужно четко представлять себе, что вы хотите получить от внедрения этой технологии и следовать этой цели. Применение UML экономит ресурсы разработки, поскольку позволяет получить представление о системе быстрее, чем при создании макетов и прототипов, затратив на это несравнимо меньше ресурсов.
Диаграммы позволяет легче общаться членам проекта между собой, и, что особенноценно, вовлекают в процесс конечных пользователей системы. Моделирование позволяет уменьшить риски проекта, поскольку программистам всегда легче делать то, что ясно и понятно, чем идти к неопределенному результату. Создание диаграмм аналогично созданию проекта в строительстве – можно обойтись и без него, например, при строительстве сарая на дачном участке, однако, чем больше здание (в нашем случае программный продукт), тем труднее это делать и неопределеннее конечный результат.
Однажды я проводил семинар по RUP в компании-разработчике программного обеспечения, которая уже десять лет довольно успешно работает на рынке, но не использует в своем рабочем процессе моделирования вовсе, а основывается на прототипах. В зале собралось около двадцати молодых и умудренных опытом программистов, которые внимательно прослушали все, что я им рассказал о RUP и UML . И вот один из них, посмотрев на доску, испещренную примерами диаграмм, заметил: «Это все интересно и, наверное, хорошо подходит для других проектов», – сказал он, «но мы работаем довольно давно без всего этого,раз мы до сих пор обходились без UML , он, наверное, нам это просто не нужен».
Этот вопрос заставил меня задуматься о том, что изменение бизнес-процессов, которое неизбежно должно произойти в компании-разработчике программного обеспечения при внедрении RUP и UML может проходить также тяжело, как внедрение информационной системы на промышленном предприятии.Любое внедрение – это ломка стереотипов. Поскольку квалификация сотрудников в компании-разработчике ПО довольно высока, то и отказаться от своих взглядов таким людям труднее, чем «простым смертным», а возникающие трудности и неприятие можно сравнить с переходом от процедурного к объектно-ориентированному мышлению.
1.Определение требований
Унифицированный процесс – это процесс, управляемый прецедентами, которые отражают сценарии взаимодействия пользователей. Фактически, это взгляд пользователей на программную систему снаружи. Таким образом, одним из важнейших этапов разработки, согласно RUP , будет этап определения требований, который заключается в сборе всех возможных пожеланий к работе системы, которые только могут прийти в голову пользователям и аналитикам. Позднее эти данные должны будут систематизированы и структурированы, но на данном этапе в ходе интервью с пользователями и изучения документов, аналитики должны собрать как можно больше требований к будущей системе, что не так просто, как кажется на первый взгляд. Пользователи часто сами не представляют, что они должны получить в конечном итоге. Для облегчения этого процесса аналитики используют диаграммы прецедентов (рис. 2)
рис 2. Пример диаграммы Прецедентов
Диаграмма представляет собой отражение действующих лиц (актантов), которые взаимодействуют с системой, и реакцию программных объектов на их действия. Актантами могут быть как пользователи, так и внешние агенты, которым необходимо передать или получить информацию. Значок варианта использования отражает реакцию системы на внешнее воздействие и показывает, что должно быть сделано для актанта.
Для детализации конкретного прецедента используется диаграмма Активности (Activity Diagram ), пример которой дан на рис 3.
рис. 3 Пример диаграммы Активности
Простота диаграммы прецедентов позволяет аналитикам легко общаться с заказчиками в процессе определения требований, выявлять ограничения, налагаемые на систему и на выполнение отдельных требований, такие, например, как время реакции системы, которые в дальнейшем попадают в раздел нефункциональных требований.
Также диаграмма прецедентов может использоваться для создания сценариев тестирования, поскольку все взаимодействие пользователей и системы уже определено.
Для того чтобы верно определить требования, разработчикидолжны понимать контекст (часть предметной области) в котором будет работать будущая система. Для этого создаются модель предметной области и бизнес-модель, что является различными подходами к одному и тому же вопросу. Часто создается что-то одно: модель предметной области или бизнес-модель.
Отличия этих моделей в том, что модель предметной области описывает важные понятия, с которыми будет работать система и связи их между собой. Тогда как бизнес-модель описывает бизнес-процессы (существующие или будущие), которые должна поддерживать система. Поэтому кроме определения бизнес-объектов, вовлеченных в процесс, эта модель определяет работников, их обязанности и действия, которые они должны выполнять.
Для создания модели предметной области используется обычная диаграмма классов (рис 6), однако для создания бизнес-модели ее уже явно недостаточно. В этом случае применяется диаграмма прецедентов с использованием дополнительных значков, которые отражающие сущность бизнес-процессов – это бизнес-актант, бизнес-прецедент, бизнес-сущность и бизнес-управление. Эта модель намного ближе к следующей модели, создаваемой в процессе разработки – модели анализа.
2.Анализ
После определения требований и контекста, в котором будет работать система, наступает черед анализа полученных данных. В процессе анализа создается аналитическая модель, которая подводит разработчиков к архитектуре будущей системы. Аналитическая модель – это взгляд на систему изнутри, в отличие от модели прецедентов, которая показывает, как система будет выглядеть снаружи.
Эта модель позволяет понять, как система должна быть спроектирована, какие в ней должны быть классы и как они должны взаимодействовать между собой. Основное ее назначение - определить направление реализации функциональности, выявленной на этапе сбора требований и сделать набросок архитектуры системы.
В отличие от создаваемой в дальнейшем модели проектирования, модель анализа является в большей степени концептуальной моделью и только приближает разработчиков к классам реализации. Эта модель не должна иметь возможных противоречий, которые могут встретиться в модели прецедентов.
Для отображения модели анализа при помощи UML используется диаграмма классов со стереотипами (образцами поведения) «граничный класс», «сущность», «управление», а для детализации используются диаграммы сотрудничества (Collaboration ) (рис 4). Стереотип «граничный класс» отображает класс, который взаимодействует с внешними актантами, «сущность» – отображает классы, которые являются хранилищами данных, а «управление» – классы, управляющие запросами к сущностям.
рис 4. Пример диаграммы сотрудничества
Нумерация сообщений показывает их порядок, однако назначение диаграммы не в том, чтобы рассмотреть порядок обмена сообщениями, а в том, чтобы наглядно показать связи классов друг с другом.
Если акцентировать внимание на порядке взаимодействия, то другим его представлением будет диаграмма последовательности (Sequence ), показанная на рис 5. Эта диаграмма позволяет взглянуть на обмен сообщениями во времени, наглядно отобразить последовательность процесса. При использовании такого инструмента для создания моделей как Rational Rose , эти два вида диаграмм могут быть созданы друг из друга автоматически (подробнее о Rational Rose можно прочитать, например, в ).
Рис. 5 Пример диаграммы последовательности действий
Решение о том, какую из двух диаграмм нужно создавать первой, зависит от предпочтений конкретного разработчика. Поскольку эти диаграммы являются отображением одного и того же процесса, то и та и другая позволяют отразить взаимодействие между объектами.
3.Проектирование
Следующим этапом в процессе создания системы будет проектирование, в ходе которого на основании моделей, созданных ранее, создаетсямодель проектирования. Эта модель отражает физическую реализации системы и описывает создаваемый продукт на уровне классов и компонентов. В отличие от модели анализа, модель проектирования имеет явно выраженную зависимость от условий реализации, применяемых языков программирования и компонентов. Для максимально точного понимания архитектуры системы, эта модель должна быть максимально формализована, и поддерживаться в актуальном состоянии на протяжении всего жизненного цикла разработки системы.
Для создания модели проектирования используются целый набор UML диаграмм: диаграммы классов (рис. 5), диаграммы кооперации, диаграммы взаимодействия, диаграммы активности.
рис 6. Пример диаграммы классов
Дополнительно в этом рабочем процессе может создаваться модель развертывания, которая реализуется на основе диаграммы развертывания (Deployment Diagram ). Это самый простой тип диаграмм, предназначенный для моделирования распределения устройств в сети. Для отображения используется всего два варианта значков процессор и устройство вместе со связями между ними.
4.Реализация
Основная задача процесса реализации – создание системы в виде компонентов – исходных текстов программ, сценариев, двоичных файлов, исполняемых модулей и т.д. На этом этапе создается модель реализации, которая описывает то, как реализуются элементы модели проектирования, какие классы будут включены в конкретные компоненты. Данная модель описывает способ организации этих компонентов в соответствии с механизмами структурирования и разбиения на модули, принятыми в выбранной среде программирования и представляется диаграммой компонентов (рис. 7).
рис. 7 Пример диаграммы компонентов
5.Тестирование
В процессе тестирования проверяются результаты реализации. Для данного процесса создается модель тестирования, которая состоит из тестовых примеров, процедур тестирования, тестовых компонентов, однако не имеет отображения на UML диаграммы, поэтомуне будем на ней останавливаться.
6.Заключ ение
Здесь были рассмотрены только основные процессы методологии Rational . RUP довольно обширен, и содержит рекомендации по ведению различныхпрограммных проектов, от создания программ группой разработчиков в несколько человек, до распределенных программных проектов, объединяющих тысячи человек на разных континентах. Однако, несмотря их колоссальную разницу, методы применения моделей, создаваемых при помощи UML будут одни и те же. Диаграммы UML , создаваемые на различных этапах разработки, неотделимы от остальных артефактов программного проекта и часто являются связующим звеном между отдельными процессами RUP .
Решение о применении конкретных диаграмм зависит от поставленного в компании процесса разработки, который, хотя и называется унифицированным, однако не есть нечто застывшее. Компания Rational не только предлагает его улучшать и дорабатывать, но и предоставляет специальные средства внесения изменений в базу данных RUP .
Но в любом случае, применение UML вместе с унифицированным процессом позволит получить предсказуемый результат, уложиться в отведенный бюджет, повысить отдачу от участников проекта и качество создаваемого программного продукта.
Крачтен. Ф. Введениев Rational Unified Process. Изд. 2- е.- М.: Издательский дом "Вильямс", 2002. - 240 с.: ил.
Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения- Спб.: Питер, 2002. - 496 с.: ил.
Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования: Пер. с англ. – М.:Мир, 1999. – 191 с., ил.
Бек. Е. Экстремальное программирование. – Спб.: Питер, 2002. – 224 с.: ил.
ТрофимовС. CASE-технологии: Практическая работа в Rational Rose.
Изд. 2-е.- М.: Бином-Пресс, 2002 г. - 288 с.
Унифицированный процесс (UP) − это обобщенный каркас процесса, который может быть специализирован для широкого круга программных систем, различных областей применения, уровней компетенции и размеров проекта.
Унифицированный процесс компонентно ориентирован. Это означает, что создаваемая программная система строится на основе программных компонентов , связанных хорошо определенными интерфейсами.
Специфичные аспекты UP заключаются в трех его характеристиках:
● управляется вариантами использования;
● является архитектурно-ориентированным;
● является итеративным и инкрементным.
Жизненный цикл унифицированного процесса
Жизненный цикл UP разбивается на циклы, каждый из которых завершается поставкой выпуска продукта. Каждый цикл развития состоит из четырех фаз - анализа и планирования требований, проектирования, построения, внедрения. Каждая фаза подразделяется на итерации.
UP включает в себя восемь рабочих процессов: пять основных − определение требований, анализ, проектирование, реализация, тестирование и три вспомогательных (для поддержки основных) − управление конфигурацией и изменением требований, управление проектом, управление средой.
Для определения структуры рабочего процесса сначала необходимо определить, какие типы исполнителей участвуют в процессе. Затем определяются артефакты , которые должны быть созданы в ходе данного рабочего процесса каждым типом исполнителей.
18. XP – процесс.
Экстрема́льное программи́рование (англ. Extreme Programming, XP) - одна из гибких методологий разработки программного обеспечения. Авторы методологии - Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.
Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:
1. Короткий цикл обратной связи (Fine scale feedback)
a. Разработка через тестирование (Test driven development)
b. Игра в планирование (Planning game)
c. Заказчик всегда рядом (Whole team, Onsite customer)
d. Парное программирование (Pair programming)
2. Непрерывный, а не пакетный процесс
a. Непрерывная интеграция (Continuous Integration)
b. Рефакторинг (Design Improvement, Refactor)
c. Частые небольшие релизы (Small Releases)
3. Понимание, разделяемое всеми
a. Простота (Simple design)
b. Общение
c. Уважение
d. Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
e. Стандарт кодирования (Coding standard or Coding conventions)
4. Социальная защищенность программиста (Programmer welfare):
a. 40-часовая рабочая неделя (Sustainable pace, Forty hour week)
В XP процесс делится на очень маленькие ступеньки, по сравнению с планируемыми процессами. Это приводит к тому, что первые шаги могут занимать дни или недели вместо месяцев или даже лет для каждой ступени в модели «водопад». Сначала пишутся автоматические тесты, чтобы описать цели разработки. Потом идёт кодирование, которое заканчивается в тот момент, когда все тесты проходят, и программисты не могут придумать новых тестов. Дизайн делается теми же людьми, которые пишут код. (только последняя ступень - соединение дизайна и кода является общим для всех гибких процессов). Незаконченная, но функционирующая система показывается узкому кругу пользователей (чаще всего это сами разработчики). В этот момент начинают писать тесты для следующей наиболее важной части системы.
19. ICONIX – процесс.
ICONIX разработал Дуг Розенберг в компании ICONIX Software .Процесс ICONIX основан на вариантах испльзования, но не характеризуется множеством его недостатков. В этом процессе также применяется язык моделирования UML, но используется только базовая нотация из UML – это 20% языка. В основу процесса ICONIX положены четыре основных этапа разработки ПО на основе вариантов использования:
● моделирование предметной области;
● моделирование прецедентов;
● анализ пригодности требований (проверка на выполнение всех функциональных требований);
● построение диаграмм последовательности.
Основные этапы процесса следующие:
● Анализ требований
● Предварительное проектирование
● Проектирование
● Реализация
Процесс основан на построении минимального количества моделей, которые отражают будущую систему. На этапе анализа создаются модели прецедентов (Use Case), модель пользовательского интерфейса и модель сущностей предметной области. На этапе предварительного проектирования создается диаграмма пригодности (Robustness Diagram). Также дополняется модель прецедентов и модель сущностей предметной области. На этапе детального проектирования создается диаграмма последовательности (SequenceDiagram) и создается диаграмма классов. На этапе реализации создается исходный код. При этом возможно создание диаграммы развертывания и диаграммы компонентов. каждый этап завершается вехой рецензирования, когда созданные диаграммы необходимо обсудить с коллегами.
20. SCRUM – процесс.
Scrum - это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные небольшие промежутки времени (спринты от 2 до 4 недель) предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго-фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.
Главные действующие роли в Scrum: ScrumMaster - тот, кто ведёт Scrum митинги и следит, чтобы при этом соблюдались все принципы Scrum (роль не предполагает ничего кроме корректного ведения самогоScrum -а, руководитель проекта скорее относится к Product Owner и не должен являться ScrumMaster );Владелец Продукта (Product Owner ) - человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон; и кросс-функциональная Команда (Scrum Team ), состоящая как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т. д. (при этом размер команды в идеале составляет 7±2 человека). Команда является единственным полностью вовлечённым участником разработки, и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.
На протяжении каждого спринта создаётся функциональный рост программного обеспечения. Набор возможностей, которые реализуются в каждом спринте, происходят из этапа, называемого product backlog (документация запросов на выполнение работ), обладающего наивысшим приоритетом по уровню требований к работе, который должен быть выполнен. Запросы на выполнение работ (backlog items ), определенных на протяжении совета по планированию спринта (sprint planning meeting ), перемещаются в этап спринта. На протяжении этого собрания Владелец Продукта информирует о заданиях, которые должны быть выполнены. Тогда Команда определяет, сколько из желаемого они могут выполнить, чтобы завершить необходимые части на протяжении следующего спринта . Во время спринта команда выполняет определенный фиксированный список заданий (т. н. sprint backlog ). На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать как заморозку требований (requirements ) во время спринта.
Артефакты
Product backlog - это документ, содержащий список требований к функциональности, которые упорядочены по степени важности. Product backlog представляет собой список того, что должно быть реализовано. Элементы этого списка называются «историями» (user story ) или элементами backlog’a (backlog items ). Product backlog открыт для редактирования для всех участников Scrum-процесса.
05.10.17 1.6KУнифицированный процесс Rational - это универсальная методология распределения задач и сфер ответственности при разработке программного обеспечения. Её цель – создание высококачественного программного обеспечения, отвечающего потребностям и запросам пользователей. Методология RUP была разработана в компании Rational Software Corporation , которую в 2003 году купила IBM .
Невероятный успех предложенного в рамках RUP подхода помог многим компаниям понять, насколько важно иметь чётко прописанный и задокументированный процесс разработки.
Методология RUP предназначена для крупных проектов разработки, поэтому многие менеджеры уверены, что она не подойдёт для небольших задач, не требующих большого объёма ресурсов. Но есть множество примеров, когда небольшие проекты значительно выигрывали от внедрения RUP .
К примеру, RUP используется в системе управления онлайн-обучением TAP University . Компания поставила перед собой цель расширить область традиционного офлайн-обучения и улучшить свои сервисы для корпоративных, частных пользователей и студентов.
Хотя это был небольшой проект, внедрение методологии RUP показало отличные результаты. Она помогла выстроить набор принципов, необходимых для организации сценариев использования сервисов TAP University , помогла увидеть направления для перехода к третьей, самой важной фазе RUP - построению.
Что такое унифицированный процесс Rational (RUP)?
Работа над процессом – команда разработчиков RUP тесно работает с покупателями, партнёрами и группами компаний, постоянно обновляя методологию.
RUP оптимизирует командную работу – обеспечивает команде разработчиков свободный доступ к базе знаний с инструкциями для использования программных средств. Это помогает быстрее справиться с критическими проблемами. Благодаря этому команда легко находит общий язык в процессе работы над проектом.
RUP ориентирован на создание и поддержание моделей – вместо написания большого количества бумажной документации при использовании RUP методологии создаются модели – семантические представления разрабатываемого командой программного обеспечения.
RUP – это инструкция использования Unified Modelling Language (UML) – UML позволяет команде легко донести свои требования к проекту, его архитектуру и план реализации.
RUP – это конфигурируемый процесс , он подходит как небольшим группам разработчиков, так и крупным организациям.
Шесть основополагающих принципов RUP
В основе RUP лежит шесть главных принципов :
- Итеративная модель разработки – устранение рисков на каждой стадии проекта позволяет лучше понять проблему и вносить необходимые изменения, пока не будет найдено приемлемое решение;
- Управление требованиями – RUP описывает процесс организации и отслеживания функциональных требований, документации и выбора оптимальных решений (как в процессе разработки, так и при ведении бизнеса );
- Компонентная архитектура – архитектура системы разбивается на компоненты, которые можно использовать как в текущем, так и в будущих проектах;
- Визуальное моделирование ПО – RUP методология разработки показывает , как создать визуальную модель программного обеспечения, чтобы понять структуру и поведение архитектуры и его компонентов;
- Проверка качества ПО – в процессе разработки программного обеспечения контролируется качество всех действий команды;
- Контроль внесённых изменений – отслеживание изменений позволяет выстроить непрерывный процесс разработки. Создаётся благоприятная обстановка, в рамках которой команда будет защищена от изменений в рабочем процессе.
Структура RUP
Данный подход описывает, кто делает что делает, как и когда. RUP можно представить в виде четырёх основных элементов:
Работники – «Кто»
Элемент «работник » определяет поведение и ответственность всех членов команды, сконцентрированных на общей цели – создании искусственных объектов (артефактов ). В RUP работник – это скорее роль, определяющая, как индивидуумы должны выполнять свою работу. Работник не только производит определённые действия, но также владеет набором артефактов.
Действия – «Как»
Действие - это единица работы, которую может выполнить работник. У каждого действия есть чётко обозначенная цель. Каждое действие назначено определённому работнику. Действия могут включать в себя создание или обновление артефактов, таких как модель, класс или план.
Артефакты (искусственные объекты) – «Что»
В методологии RUP объекты или информация, производимая и изменяемая в процессе работы над финальным результатом. Артефакты служат как вводными данными для действий работников, так и результатами этих действий.
Рабочий процесс – «Когда»
Рабочий процесс представляет собой последовательность действий, приводящих к видимому результату. В терминах UML
можно представить рабочий процесс как диаграмму последовательности, диаграмму кооперации или диаграмму активности:
Жизненный цикл RUP
Жизненный цикл RUP разбит на четыре основных фазы, в каждой из которых ведётся работа над новым поколением продукта: фазу начала проекта, уточнение, построение и внедрение.
- Фаза начала проекта
В этой фазе команда определяет структуру и основную идею проекта. Команда решает, стоит ли вообще заниматься этим проектом, исходя из его предполагаемой стоимости, необходимых ресурсов и цели, которую нужно достичь.
- Уточнение
Цель этой фазы - анализ требований к системе и её архитектуры, разработка плана проекта и устранение элементов наивысшего риска. Это самая важная фаза из всех, поскольку она знаменует переход от низкого уровня риска к высокому. В рамках этой фазы команда решает, переходить ли к фазе построения (разработке и написанию кода ) или нет.
- Построение
В этой фазе RUP методологии команда начинает разработку всех компонентов и функций программного обеспечения, интегрирует их в конечный продукт. Это производственный процесс, в рамках которого команда сосредоточена на управлении ресурсами, чтобы оптимизировать расходы, время и качество продукта.
- Внедрение
Фаза, когда продукт готов и доставлен покупателям. Но после того как пользователи получают продукт, могут возникнуть новые трудности. Команде нужно будет исправить ошибки, отловить баги и доделать функции, которые не были реализованы в первично установленный срок.
В конце каждой фазы существует отметка завершения этапа (Project Milestone ) - момент, когда ваша команда оценивает, достигнуты ли поставленные цели. При этом команда принимает важные решения, влияющие на ход следующей фазы.
Rational Unified Process (RUP) - это основа технологии разработки ПО, разработанная и продаваемая компанией Rational Software. Он включает в себя передовой мировой опыт разработки ПО, и обеспечивает дисциплинарный подход к распределению и управлению задачами и областями ответственности в организации, занимающейся разработкой ПО. Применяя этот процесс, команды разработчиков программ смогут создавать высококачественное ПО, отвечающее потребностям своих конечных пользователей, и делать это в рамках предсказуемого графика и бюджета.
RUP направляет профессионалов, в области программного обеспечения, на эффективное применение лучших современных практических методов, таких как итеративная разработка , применение архитектурно – центрического подхода, вариантов использования, уменьшение риска на всех стадиях процесса и непрерывная проверка программы.
В основе Rational Unified Process лежат несколько фундаментальных принципов, собранные из множества успешных проектов:
· Начинайте вести наступление на главные риска раньше и ведите его непрерывно, или они сами пойдут в наступление на вас.
· Обеспечьте выполнение требований заказчиков.
· Сконцентрируйтесь на исполняемой программе.
· Приспосабливайтесь к изменениям с самого начала проекта.
· Рано закладывайте исполняемую архитектуру.
· Стройте систему из компонентов.
· Работайте вместе как одна команда.
· Сделайте качество образом жизни, а не запоздалой идеей.
RUP использует итеративный подход, при каждой итерации производится немного работы с требованиями, анализ, проектирование, реализация и тестирование. Каждая итерация основывается на результатах предыдущих итераций и производит исполняемую программу, которая на один шаг приближается к окончательному продукту.
RUP обеспечивает структурированный подход к итеративной разработке , разделяя проект на четыре фазы: Начало, Проектирование, Построение и Внедрение. Каждая фаза сопровождается так называемой вехой, - контрольной точкой процесса, в которой проверяется достижение целей очередной фазы, и принимается решение о переходе (или не переходе) в следующую фазу. Каждая из четырех фаз RUP, таким образом, имеет веху и четко определенный набор целей. Эти цели используются для определения того, какие задачи выполнять и какие артефакты создавать. Каждая фаза концентрируется строго на том, что единственно необходимо для достижения бизнес целей фазы.
Все элементы процесса – роли, задачи, артефакты и связанные с ними концепции, руководства и шаблоны сгруппированы в логические контейнеры, называемые Дисциплинами (Disciplines). В стандартном продукте RUP дисциплин всего девять. К ним относятся: бизнес – моделирование, управление требованиями, управление проектом, управление изменениями и среда.
Каждый рабочий поток процесса: сбор требований, анализ, проектирование, реализация и тестирование определяет набор связанных артефактов и действий. Напомним, что артефактом является документ, отчет, выполняемый элемент и т.п. Артефакт может вырабатываться, обрабатываться или потребляться.
Между артефактами потоков существуют зависимости. Например, модель Use Case, генерируемая в ходе сбора требований, уточняется моделью анализа из процесса проектирования, реализуется моделью реализации из процесса реализации и проверяется тестовой моделью из процесса тестирования.Модель - наиболее важная разновидность артефакта. Предусмотрены девять моделей, вместе они покрывают все решения по визуализации, спецификации, конструированию и документированию программных систем:
· бизнес – модель . Определяет абстракцию организации, для которой создается система;
· модель области определения . Фиксирует контекстное окружение системы;
· модель Use Case . Определяет функциональные требования к системе.
· модель анализа . Интерпретирует требования к системе в терминах проектной модели;
· проектная модель . Определяет словарь предметной области проблемы и ее решения;
· модель размещения . Определяет аппаратную топологию, в которой исполняется система;
· модель реализации . Определяет части, которые используются для сборки и реализации физической системы;
· тестовая модель . Определяет тестовые варианты для проверки системы;
· модель процессов . Определяет параллелизм в системе и механизмы синхронизации.
Технические артефакты подразделяются на четыре основных набора:
· набор требований. Описывает, что должна делать система;
· набор проектирования.
Описывает, как должна быть сконструирована система;· набор реализаций. Описывает сборку разработанных программных компонентов;
· набор размещения. Обеспечивает всю информацию о поставляемой конфигурации.
Набор требований может включать модель Use Case, модель нефункциональных требований, модель области определения, модель анализа, а также другие формы выражения нужд пользователя.
Набор проектирования может включать проектную модель, тестовую модель и другие формы выражения сущности системы.
Набор реализаций группирует все данные о программных элементах, образующих систему (программный код, файлы конфигурации, файлы данных, программные компоненты, информацию о сборке системы).
Набор размещения группирует всю информацию об упаковке, отправке, установке и запуске системы.
Каждый технологический процесс сопровождается риском . При разработке программного продукта неудовлетворительным результатом (НУ) может быть: превышение бюджета, низкая надежность, неправильное функционирование и т.д. Влияние риска вычисляют по выражению
Показатель Риска = Вероятность (НУ) *Потеря (НУ).
Управление риском включает шесть действий:
1. Идентификация риска – выявление элементов риска в проекте.
2. Анализ риска – оценка вероятности и величины потери по каждому элементу риска.
3. Ранжирование риска - упорядочение элементов риска по степени их влияния.
4. Планирование управления риском – подготовка к работе с каждым элементом риска.
5. Разрешение риска – устранение или разрешение элементов риска.
6. Наблюдение риска – отслеживание динамики элементов риска, выполнение корректирующих действий.
Первые три действия относятся к этапу оценивания риска, последние три действия – к этапу контроля риска.
Выделяют три категории источников риска: проектный риск, технический риск и коммерческий риск. После идентификации элементов риска следует количественно оценить их влияние на программный проект, решить вопросы о возможных потерях. Эти вопросы решаются на шаге анализа риска. И, наконец, в общий план программного проекта интегрируется план управления каждым элементом риска, то есть набор функций управления каждым элементом риска.
Унифицированный Процесс разработки компании Rational (Rational Unified Process, RUP) – это сумма различных видов деятельности, необходимых для преобразования требований пользователей в программную систему, . Его абстрактное и развёрнутое представление показано на рис. 7.2.
Основными понятиями RUP являются артефакт (artifact) и прецедент (precedent). Артефакты - это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным программным продуктом. Прецеденты или варианты использования (use-case) ‑ это последовательности действий, выполняемых программной системой для получения наблюдаемого результата.
Весь процесс разработки программной системы рассматривается в RUP как процесс создания артефактов . Причем то, что попадает в руки конечного пользователя, будь то программный модуль или программная документация, - это один из подклассов всех артефактов проекта.
Каждый член проектной группы создает свои артефакты и несет за них ответственность. Программист разрабатывает программу, руководитель - проектный план, а аналитик - модели системы. RUP позволяет определить, когда, кому и какой артефакт необходимо создать.
(а
)
Рис. 7.2. Унифицированный процесс разработки ПО (а ‑ абстрактное представление, б – развёрнутое представление основных процессов RUP)
Однако, RUP ‑ это больше чем единичный процесс, это обобщенный каркас процесса, который может быть специализирован для широкого круга программных систем, различных областей применения, уровней компетенции и размеров проекта. RUP ‑ компонентно-ориентирован. Это означает, что создаваемая программная система строится на основе программных компонентов, связанных хорошо определенными интерфейсами.
Для разработки графических представлений (моделей) программной системы RUP использует Унифицированный Язык Моделирования (UML). Фактически UML является неотъемлемой частью RUP ‑ они и разрабатывались совместно.
Однако действительно специфичные аспекты RUP-процесса заключаются в трех словосочетаниях - управляемый вариантами использования , архитектурно-ориентированный , итеративный и инкрементный . Это то, что делает Унифицированный процесс уникальным.
Полное представление программной системы в RUP включает девять моделей, которые совместно охватывают все важнейшие решения относительно визуализации, специфицирования, конструирования и документирования программной системы (рис 7.3):
1. модель бизнес-процессов , которая формализует абстракцию организации (со всеми вариантами использования управляющей ПС и их связями с пользователями);
2. модель прецедентов - формализует функциональные требования к системе;
3. модель предметной области или бизнес-модель , описывающую контекст системы.
4. модель анализа , которая имеет две цели - уточнить детали вариантов использования и создать первичное распределение поведения системы по набору объектов, предоставляющих различные варианты поведения;
5. модель процессов (необязательная) - формализует механизмы параллелизма и синхронизации в системе;
6. модель проектирования , которая определяет: (а ) ‑ статическую структуру системы, такую, как подсистемы, классы и интерфейсы, и (b ) ‑ варианты использования, реализованные в виде коопераций между подсистемами, классами и интерфейсами;
7. модель реализации , которая включает в себя компоненты (представленные исходным кодом) и раскладку классов по компонентам;
8. модель развертывания , которая определяет физические компьютеры - узлы сети и раскладку компонентов по этим узлам;
9. модель тестирования , которая описывает варианты тестов для проверки вариантов использования;
Рис. 7.3.
Модели RUP (в форме соответствующих UML-диаграмм)
и их связи,
Все эти модели связаны. Вместе они полностью описывают программную систему. Элементы одной модели имеют трассировочные зависимости вперед и назад, организуемые с помощью связей с другими моделями (см. рис. 7.3). Например, вариант использования (в модели вариантов использования) может быть оттрассирован на соответствующую реализацию варианта использования (в модели проектирования) и вариант тестирования (в модели тестирования). Трассировка облегчает понимание и внесение изменений. UML-диаграммы, созданные в процессе RUP-разработки, дают полное представление о программном продукте).
Основной упор в RUP делается не на подготовку документов как таковых, а на моделирование разрабатываемой системы. Модели помогают очерчивать как проблему, так и пути ее решения, а создаются они при помощи языка UML, который давно уже стал стандартом де-факто для описания сложных систем и позволяет разработчикам определять, визуализировать, конструировать и документировать артефакты программных систем любой сложности.