Унифицированный процесс Rational (RUP)


Оглавление (нажмите, чтобы открыть):

Рабочие процессы RUP и диаграммы UML

10.05.2003

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

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 )[1,2], которая представляет собой набор исчерпывающих рекомендаций для создания практически любых программных продуктов. Вобрав в себя опыт лучших разработок, RUP подробно рассказывает когда, кто и что должен делать в проекте, чтобы в результате получить программную систему с установленные сроки, с определенной функциональностью и в рамках отведенного бюджета.

Унифицированный процесс можно представить как сумму различных видов деятельности компании-разработчика, необходимых для перевода требований заказчика в программную систему. Систему, которая давала бы «значимый результат»[2] пользователям и выполняла бы именно то, что они от системы ожидают. Поэтому процесс управляется вариантами использования ( Use Case ) системы, или иначе – прецедентами.

Для реализации требований заказчика в установленные сроки, Унифицированный процесс разделяется на фазы, которые состоят из итераций, поэтому процесс еще называют итеративным и инкрементным. Каждая итерация проходит цикл основных работ и подводит разработчиков к конечной цели: созданию программной системы. В ходе итераций создаются промежуточные артефакты, которые требуются для успешного завершения проекта и вариант программной системы, который реализует некоторый набор функций, увеличивающийся от итерации к итерации. Фазы и основные потоки работ процесса показаны на рис. 1, там же даны примерные трудозатраты работ по фазам.

рис. 1 Фазы и потоки работ RUP

Нужно отметить, что на рис. 1 показаны только основные работы Унифицированного процесса. Например, работы по управлению деятельностью здесь не показаны, чтобы не загромождать диаграмму.

Вся разработка ПО рассматривается в RUP как процесс создания артефактов. Любой результат работы проекта, будь то исходные тексты, объектные модули, документы, передаваемые пользователю, модели – это подклассы всех артефактов проекта. Каждый член проектной группы создает свои артефакты и несет за них ответственность. Программист создает программу, руководитель — проектный план, а аналитик — модели системы. RUP позволяет определить когда, кому и какой артефакт необходимо создать, доработать или использовать.

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

Модели позволяют рассмотреть будущую систему, ее объекты и их взаимодействие еще до вкладывания значительных средств в разработку, позволяют увидеть ее глазами будущих пользователей снаружи и разработчиков изнутри еще до создания первой строки исходного кода. Большинство моделей представляются UML диаграммами, подробнее об UML можно прочитать, например в [3].

Унифицированный язык моделирования ( Unified Modeling Language ) появился в конце 80-х в начале 90-х годов в основном благодаря усилиям «трех друзей» Гради Буча, Джима Рамбо и Ивара Якобсона. В настоящее время консорциум OMG принял этот язык как стандартный язык моделирования, который предоставляет разработчикам четкую нотацию, позволяющую отображать модели общепринятыми и понятными каждому члену проекта графическими элементами.

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

Программная система создается для решения определенных проблем пользователя, а не для опробования новых технологий программистами и получения опыта руководителем проекта. По большому счету, пользователю не важно используете ли вы в процессе разработки объектно-ориентированный подход, UML , RUP или создаете систему по методу XP (экстремального программирования) [4]. Применение тех или иных методик, технологий, создание оптимальной внутренней структуры проекта остается на совести разработчиков, которые принимают решения исходя из предыдущего опыта и собственных предпочтений. Однако пользователь не простит вам игнорирование его требований. Будь программная система хоть десять раз разработана при помощи суперсовременных методов и технологий, если пользователь не получит от нее то, что называется «значимым результатом», ваш программный проект с треском провалится.

Из этого следует, что бездумное применение 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]).

Рис. 5 Пример диаграммы последовательности действий

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

3.Проектирование

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

Для создания модели проектирования используются целый набор UML диаграмм: диаграммы классов (рис. 5), диаграммы кооперации, диаграммы взаимодействия, диаграммы активности.

рис 6. Пример диаграммы классов

Дополнительно в этом рабочем процессе может создаваться модель развертывания, которая реализуется на основе диаграммы развертывания ( Deployment Diagram ). Это самый простой тип диаграмм, предназначенный для моделирования распределения устройств в сети. Для отображения используется всего два варианта значков процессор и устройство вместе со связями между ними.

4.Реализация

Основная задача процесса реализации – создание системы в виде компонентов – исходных текстов программ, сценариев, двоичных файлов, исполняемых модулей и т.д. На этом этапе создается модель реализации, которая описывает то, как реализуются элементы модели проектирования, какие классы будут включены в конкретные компоненты. Данная модель описывает способ организации этих компонентов в соответствии с механизмами структурирования и разбиения на модули, принятыми в выбранной среде программирования и представляется диаграммой компонентов (рис. 7).

рис. 7 Пример диаграммы компонентов

5.Тестирование

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


6.Заключение

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

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

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

[1] Крачтен . Ф . Введение в Rational Unified Process. Изд . 2- е .- М.: Издательский дом «Вильямс», 2002. — 240 с.: ил.

[2] Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения — Спб.: Питер, 2002. — 496 с.: ил.

[3] Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования: Пер. с англ. – М.:Мир, 1999. – 191 с., ил.

[4] Бек. Е. Экстремальное программирование. – Спб.: Питер, 2002. – 224 с.: ил.

[5] Трофимов С. CASE-технологии: Практическая работа в Rational Rose.
Изд. 2-е.- М.: Бином-Пресс, 2002 г. — 288 с.

QA evolution

RUP (Rational Unified Process) – методология разработки ПО, созданная компанией Rational Software

1 — ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков

2 — концентрация на выполнении требований заказчиков к исполняемой программе

3 — ожидание изменений в требованиях , проектных решениях и реализации в процессе разработки

4 — компонентная архитектура , реализуемая и тестируемая на ранних стадиях проекта

5 — постоянное обеспечение качества на всех этапах разработки проекта (продукта)

6 — работа над проектом в сплочённой команде , ключевая роль в которой принадлежит архитекторам

Процессы и стадии RUP

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

Полный жизненный цикл разработки ПО состоит из 4 этапов:

1.Начальная стадия (Inception)

В фазе начальной стадии:

Формируются видение и границы проекта .

Создается экономическое обоснование (business case).

Определяются основные требования, ограничения и ключевая функциональность продукта .

Создается базовая версия модели прецедентов .

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

При завершении начальной фазы оценивается достижение этапа жизненного цикла цели , которое предполагает соглашение заинтересованных сторон о продолжении проекта.

Уточнение (Elaboration)

В фазе «Уточнение» производится анализ предметной области и построение исполняемой архитектуры . Это включает в себя:

Документирование требований (включая детальное описание для большинства прецедентов).

Спроектированную, реализованную и оттестированную исполняемую архитектуру .

Обновленное экономическое обоснование и более точные оценки сроков и стоимости.

Сниженные основные риски .

Успешное выполнение фазы разработки означает достижение этапа жизненного цикла архитектуры

Построение (Construction)

В фазе «Построение» происходит реализация большей части функциональности продукта . Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности.

Внедрение (Transition)

В фазе «Внедрение» создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования , обучение пользователей, а также определение качества продукта . В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта и завершение полного цикла разработки

Rational Unified Process

Разработка программного обеспечения
Процесс разработки ПО
Ключевые процессы
Анализ • Проектирование • Программирование • Документирование • Тестирование
Модели
Итеративная • Спиральная • Каскадная • V-Model • Dual Vee Model
Методологии
Agile (XP, Lean, Scrum, FDD и др.) • Cleanroom • OpenUP • RAD • RUP • MSF • DSDM • TDD • BDD
Сопутствующие дисциплины
Конфигурационное управление • Управление проектами • Управление требованиями • Обеспечение качества

Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.

Содержание

Принципы

В основе RUP лежат следующие принципы:

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

Процессы и стадии RUP

RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта. Первые идеи итеративной модели разработки были заложены в «спиральной модели» [1] [2] .

Полный жизненный цикл разработки продукта состоит из четырёх фаз, каждая из которых включает в себя одну или несколько итераций:

1. Начальная стадия (Inception)


В фазе начальной стадии:

  • Формируются видение и границы проекта.
  • Создается экономическое обоснование (business case).
  • Определяются основные требования, ограничения и ключевая функциональность продукта.
  • Создается базовая версия модели прецедентов.
  • Оцениваются риски.

При завершении начальной фазы оценивается достижение этапа жизненного цикла цели (англ. Lifecycle Objective Milestone ), которое предполагает соглашение заинтересованных сторон о продолжении проекта.

2. Уточнение (Elaboration)

В фазе «Уточнение» производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:

  • Документирование требований (включая детальное описание для большинства прецедентов).
  • Спроектированную, реализованную и оттестированную исполняемую архитектуру.
  • Обновленное экономическое обоснование и более точные оценки сроков и стоимости.
  • Сниженные основные риски.

Успешное выполнение фазы уточнения означает достижение этапа жизненного цикла архитектуры (англ. Lifecycle Architecture Milestone ).

3. Построение (Construction)

В фазе «Построение» происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).

4. Внедрение (Transition)

В фазе «Внедрение» создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.

Унифицированный процесс Rational

Читайте также:

  1. A) Бесплатное ведение процесса и предоставление защиты
  2. Excel кестелік процессоры
  3. I. ГЛОБАЛЬНЫЙ ИСТОРИЧЕСКИЙ ПРОЦЕСС КАК ЧАСТНЫЙ ПРОЦЕСС В ГЛОБАЛЬНОМ ЭВОЛЮЦИОННОМ ПРОЦЕССЕ БИОСФЕРЫ
  4. II. ГЛОБАЛЬНЫЙ ИСТОРИЧЕСКИЙ ПРОЦЕСС 1 страница
  5. II. ГЛОБАЛЬНЫЙ ИСТОРИЧЕСКИЙ ПРОЦЕСС 2 страница
  6. II. ГЛОБАЛЬНЫЙ ИСТОРИЧЕСКИЙ ПРОЦЕСС 3 страница
  7. IV этап. Углубленный энергетический аудит отдельных технологических процессов и энергопотребителей
  8. IV. УПРАВЛЕНИЕ В ГЛОБАЛЬНОМ ИСТОРИЧЕСКОМ ПРОЦЕССЕ 1 страница
  9. IV. УПРАВЛЕНИЕ В ГЛОБАЛЬНОМ ИСТОРИЧЕСКОМ ПРОЦЕССЕ 2 страница
  10. IV. УПРАВЛЕНИЕ В ГЛОБАЛЬНОМ ИСТОРИЧЕСКОМ ПРОЦЕССЕ 3 страница
  11. IV. ФОРМЫ И ОСОБЕННОСТИ ОРГАНИЗАЦИИ УЧЕБНОГО ПРОЦЕССА ФОРМЫ ПРОМЕЖУТОЧНОГО И ИТОГОВОГО КОНТРОЛЯ
  12. MISC-процессоры

Лекция

«Тяжелые» и «легкие» процессы разработки

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

RUP является примером так называемого «тяжелого» процесса, детально описанного и предполагающего поддержку собственно разработки исходного кода ПО большим количеством вспомогательных действий. Примерами подобных действий являются разработка планов, технических заданий, многочисленных проектных моделей, проектной документации и пр. Основная цель такого процесса — отделить успешные практики разработки и сопровождения ПО от конкретных людей, умеющих их применять. Многочисленные вспомогательные действия дают надежду сделать возможным успешное решение задач по конструированию и поддержке сложных систем с помощью имеющихся работников, не обязательно являющихся суперпрофессионалами.

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

Экстремальное программирование, наоборот, представляет так называемые «живые» (agile) методы разработки, называемые также «легкими» процессами. Они делают упор на использовании хороших разработчиков, а не хорошо отлаженных процессов разработки. Живые методы избегают фиксации четких схем действий, чтобы обеспечить большую гибкость в каждом конкретном проекте, а также выступают против разработки дополнительных документов, не вносящих непосредственного вклада в получение готовой работающей программы.

RUP [1,2] является довольно сложной, детально проработанной итеративной моделью жизненного цикла ПО.

Исторически RUP является развитием модели процесса разработки, принятой в компании Ericsson в 70–80-х годах XX века. Эта модель была создана Джекобсоном (Ivar Jacobson), впоследствии, в 1987 году, основавшим собственную компанию Objectory AB именно для развития технологического процесса разработки ПО как отдельного продукта, который можно было бы переносить в другие организации. После вливания Objectory в Rational в 1995 году разработки Джекобсона были интегрированы с работами Ройса (Walker Royce, сын автора «классической» каскадной модели), Крухтена (Philippe Kruchten) и Буча (Grady Booch), а также с развивавшимся параллельно универсальным языком моделирования (Unified Modeling Language, UML).

RUP основан на трех ключевых идеях:

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

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

  • Основой процесса разработки являются планируемые и управляемые итерации, объем которых (реализуемая в рамках итерации функциональность и набор компонентов) определяется на основе архитектуры.

увеличить изображение
Рис. 3.1. Пример хода работ на фазе начала проекта

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

1. Фаза начала проекта (Inception)

Основная цель этой фазы — достичь компромисса между всеми заинтересованными лицами относительно задач проекта и выделяемых на него ресурсов.

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

На эту фазу может уходить около 10% времени и 5% трудоемкости одного цикла.

Пример хода работ показан на рис. 3.1.

увеличить изображение
Рис. 3.2. Пример хода работ на фазе проектирования

2. Фаза проектирования (Elaboration)

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

На эту фазу может уходить около 30% времени и 20% трудоемкости одного цикла.

Пример хода работ представлен на рис. 3.2.

увеличить изображение
Рис. 3.3. Пример хода работ на фазе построения

3. Фаза построения (Construction)

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

На эту фазу уходит около 50% времени и 65% трудоемкости одного цикла.

Пример хода работ на этой фазе представлен на рис.3.3.

4. Фаза внедрения (Transition)

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

На эту фазу может уходить около 10% времени и 10% трудоемкости одного цикла.

Пример хода работ представлен на рис. 3.4.


увеличить изображение
Рис. 3.4. Пример хода работ на фазе внедрения

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

Наиболее важные с точки зрения RUP артефакты проекта — это модели, описывающие различные аспекты будущей системы. Большинство моделей представляют собой наборы диаграмм UML. Основные используемые виды моделей следующие:

  • Модель вариантов использования (Use-Case Model).

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

увеличить изображение
Рис. 3.5. Основные артефакты проекта по RUP и потоки данных между ними

Модель вариантов использования служит основой для проектирования и оценки готовности системы к внедрению.

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

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

Рис. 3.6. Пример варианта использования и действующих лиц

  • Модель анализа (Analysis Model).

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

Интерфейсные классы (boundary classes) соответствуют устройствам или способам обмена данными между системой и ее окружением, в том числе пользователями. Классы данных (entity classes) соответствуют наборам данных, описывающих некоторые однотипные сущности внутри системы. Эти сущности являются абстракциями представлений пользователей о данных, с которыми работает система. Управляющие классы (control classes) соответствуют алгоритмам, реализующим какие-то значимые преобразования данных в системе и управляющим обменом данными с ее окружением в рамках вариантов использования.

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

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

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

увеличить изображение
Рис. 3.7. Пример модели анализа для одного варианта использования

· Модель проектирования (Design Model)

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

Каждая такая платформа может включать: операционные системы всех вовлеченных машин; используемые языки программирования; интерфейсы и классы конкретных компоне нтных сред, таких как J2EE, .NET, COM или CORBA; интерфейсы выбранных для использования систем управления базами данных, СУБД, например, Oracle или MS SQL Server; используемые библиотеки разработки пользовательского интерфейса, такие как swing или swt в Java, MFC или gtk; интерфейсы взаимодействующих систем и пр.

В нашем примере, прежде всего, необходимо детализировать классы, уточнить их функциональность. Скажем, для того, чтобы клиенту было удобнее делать заказ, нужно предоставить ему список имеющихся товаров, какие-то способы навигации и поиска в этом списке, а также детальную информацию о товаре. Это значит, что интерфейс заказа товара реализуется в виде набора классов, представляющих, например, различные страницы сайта магазина. Точно так же данные заказа должны быть детализированы в виде нескольких таблиц в СУБД, включающих, как правило, данные самого заказа (дату, ссылку на данные клиента, строки с количеством отдельных товаров и ссылками на товары), данные товаров, клиента и пр. Кроме того, для реляционной СУБД понадобятся классы-посредники между ее таблицами и объектной структурой остальной программы. Обработчик заказа может быть реализован в виде набора объектов нескольких классов, например, с выделенным отдельно набором часто изменяемых политик (скидки на определенные категории товаров и определенным категориям клиентов, сезонные скидки, рекламные комплекты и пр.) и более постоянным общим алгоритмом обработки.

Далее, приняв, например, решение реализовывать систему с помощью технологий J2EE или .NET, мы тем самым определяем дополнительные ограничения на структуру классов, да и на само их количество. О правилах построения ПО на основе этих технологий рассказывается в следующих лекциях.

· Модель реализации (Implementation Model).

Под моделью реализации в рамках RUP и UML понимают набор компонентов результирующей системы и связей между ними. Под компонентом здесь имеется в виду компонент сборки — минимальный по размерам кусок кода системы, который может участвовать или не участвовать в определенной ее конфигурации, единица сборки и конфигурационного управления. Связи между компонентами представляют собой зависимости между ними. Если компонент зависит от другого компонента, он не может быть поставлен отдельно от него.

Часто компоненты представляют собой отдельные файлы с исходным кодом. Далее мы познакомимся с компонентами J2EE, состоящими из нескольких файлов.

· Модель развертывания (Deployment Model)

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

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

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

· Модель тестирования (Test Model или Test Suite)

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

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

Для выделенного варианта использования «Заказ товара» можно определить следующие тестовые варианты:

  • заказать один из имеющихся на складе товаров и проверить, что сообщение об этом заказе поступило оператору;
  • заказать большое количество товаров и проверить, что все работает так же;
  • заказать отсутствующий на складе товар и проверить, что в ответ приходит сообщение о его отсутствии;
  • сделать заказ от имени пользователя, помещенного в «черный список», и проверить, что в ответ приходит сообщение о неоплаченных прежних заказах.

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

· Моделирование предметной области (бизнес-моделирование, Business Modeling)

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

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

· Определение требований (Requirements)

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

Требования принято фиксировать в виде модели вариантов использования.

· Анализ и проектирование (Analysis and Design)

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

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

· Реализация (Implementation)

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

· Тестирование (Test)

Задачи — найти и описать дефекты системы (проявления недостатков ее качества), оценить ее качество в целом, оценить, выполнены или нет гипотезы, лежащие в основе проектирования, оценить степень соответствия системы требованиям.


· Развертывание (Deployment)

Задачи — установить систему в ее рабочем окружении и оценить ее работоспособность на том месте, где она должна будет работать.

· Управление конфигурациями и изменениями (Configuration and Change Management)

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

· Управление проектом (Project Management)

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

· Управление средой проекта (Environment)

Задачи — подстройка процесса под конкретный проект, выбор и замена технологий и инструментов, используемых в проекте.

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

увеличить изображение
Рис. 3.8. Распределение работ между различными дисциплинами в проекте по RUP

Напоследок перечислим техники, используемые в RUP согласно [3].

Дата добавления: 2014-11-29 ; Просмотров: 360 ; Нарушение авторских прав? ;

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Рациональный унифицированный процесс (rup)

Рациональный унифицированный процесс(РУП,RUP – Rational Unified Process) – унифицированный каркасный подход, предлагаемый фирмойRational Software Corporation(с 2003 г. – подразделениеIBM Corporation); поэтому возможен и другой перевод названия:Унифицированный процесс [от] Rational Software.

Исторически РУП является развитием подхода Объекторный Процесс (Objectory Process), принятого в компанииEricssonв 70‑х – 80‑х гг. XX в. Объекторный Процесс был создан А. Якобсоном как дальнейшее развитие его методики Объектно-ориентированная инженерия ПО. Впоследствии, в 1987 г., автор основал собственную компаниюObjectory ABименно для развития своего технологического подхода разработки ПО как отдельного продукта, который можно было бы переносить в другие организации. После вливанияObjectory ABвRationalв 1995 г. подход Якобсона был объединён с Рациональным Подходом (Rational Approach). Рациональный подход основан на работах У. Ройса, Ф. Крухтена и Г. Буча.

Объединённый подход вначале получил название Рациональный Объектный Процесс (РОП, ROP – Rational Objectory Process), затем, после включения поддержки бизнес-моделирования, переименован в РУП. Кроме этого в подход была включена развивавшаяся в это время сотрудникамиRationalобъектно-ориенти­рованная методика анализа и проектирования, получившая название языкаUML.

РУП является довольно сложным, детально проработанным итеративным подходом разработки. Он представляет собой адаптируемый каркас процессов, который может быть специализирован для конкретных организаций или определённых проектов путём выбора наиболее подходящих элементов из предлагаемого каркаса. Существует множество вариантов РУП для различных областей.

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

Этот продукт входит как составная часть в набор инструментальных средств IBMRationalдля поддержки РУП. Некоторые из этих средств благодаря возможности их расширения оказываются применимыми в качестве инструментария для других подходов. В частности, подходMSFдолгое время основывался на этом наборе до разработки собственного набора средств.

Основы подхода

Исследование различных неудачных проектов привело авторов РУП к выявлению признаков и первопричин их провала.

Основными считаются следующие первопричины:

1. Непланируемое управление требованиями.

2. Неоднозначное и неопределённое взаимодействие.

3. Хрупкая архитектура (архитектура, не работающая в стрессовых условиях).

4. Непреодолимая сложность.

5. Необнаруженные несогласованности между требованиями, дизайном и реализацией.

6. Недостаточное тестирование.

7. Субъективная оценка состояния проекта.

8. Провал из-за накопившихся рисков.

9. Неконтролируемое распространение изменений.

10. Недостаточная автоматизация.

Проявлениями первопричин считаются следующие признаки:

1. Неточное понимание потребностей конечных пользователей.

2. Неспособность иметь дело с изменяющимися требованиями.

3. Не соответствующие друг другу модули.

4. Тяжёлое для сопровождения и расширения ПО.

5. Позднее обнаружение серьёзных недостатков в проекте.

6. Плохое качество ПО.

7. Неприемлемая производительность ПО.

8. Невозможность участников проекта даже совместно определить (или вспомнить), кто что изменил, когда, где и почему.

9. Ненадёжный процесс построения и выпуска.

Провал проекта обычно связан с некоторой комбинацией указанных признаков, вызванных рядом первопричин, хотя такие проекты заканчиваются неудачей каждый по‑своему.

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

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

Лучшими считаются следующие практики, используемые в РУП: 1. Итеративная разработка;2. Управление требованиями;3. Использование компонентной архитектуры;4. Визуальное моделирование;5. Проверка качества;6. Контроль изменений.

Итеративная разработка заключается в создании требуемой системы итерациями, что обеспечивает:

– снижение воздействия серьёзных рисков на ранних этапах проекта, пока это ещё можно сделать с минимальными затратами;

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

– концентрация усилий на наиболее важных направлениях проекта;


– непрерывное итеративное тестирование продукта, позволяющее оценить успешность всего проекта в целом;

– раннее обнаружение несогласованностей между требованиями, дизайном и реализацией;

– равномерное распределение ресурсов проекта;

– реальная оценка текущего состояния проекта.

Управление требованиями включает в себя выявление, организацию и документирование требований к системе и подразумевает:

– организованный подход к управлению требованиями;

– взаимодействие участников проекта на базе выявленных и утверждённых требований;

– ранжирование требований по приоритету, фильтрация их по необходимым параметрам и выявление зависимости между ними;

– объективная оценка состояния проекта на основе реализованной функциональности и текущей производительности системы;

– раннее обнаружение различных несоответствий и расхождений;

– использование инструментальных средств для организации более эффективного процесса управления требованиями.

Использование компонентной архитектуры даёт возможность повысить эффективность процесса разработки за счёт:

– повышения гибкости архитектуры создаваемой системы;

– чёткого определения изменений, требующихся при доработке системы;

– наличия множества готовых коммерческих компонентов, которые построены на основе промышленных спецификаций, что облегчает реализацию и позволяет экономить проектные ресурсы;

– упрощения задач по управлению конфигурацией продукта;

– использования средств визуального моделирования, опирающихся на компонентный подход.

Визуальное моделирование – это способ представления проблемы с помощью моделей, построенных вокруг идей из исследуемого мира. Оно позволяет.

– однозначно описать функциональное поведение разрабатываемой системы;

– определить архитектурно значимые компоненты системы и сосредоточится на их реализации;

– обеспечить построение гибкой и надёжной архитектуры и системы в целом;

– исключить из рассмотрения второстепенные детали, не влияющие на решение задачи;

– выявить на ранних стадиях проекта ошибки проектирования и несогласованность в реализации отдельных компонент системы.

Проверка качества реализуется с помощью тестирования сценариев. Непрерывная проверка качества обеспечивает следующие выгоды:

– производит оценку состояния проекта по объективным показателям;

– позволяет на ранних стадиях проекта обнаружить несоответствия в требованиях, дизайне и реализации;

– акцентирует внимание на тех сторонах работы системы, которые имеют наибольшую важность и повышенный риск;

– дефекты выявляются на ранних этапах, снижая затраты на их устранение;

– автоматизированное тестирование обеспечивает снижение влияния «человеческого фактора» и повторяемость результатов.

Контроль изменений включает в себя управление запросами на изменение, управление конфигурацией и управление измерением и обеспечивает:

– контроль состояния проекта в целом и отдельных задач на основании статусов запросов на изменение;

– хранение историй изменений по каждому запросу на изменение;

– актуальную информацию по загрузке участников проекта;

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

– учёт трудозатрат участников проекта по выполняемым изменениям;

– упрощение коммуникаций между участниками проекта: необходимые данные об изменениях всегда доступны и актуальны.

Лучшие практики послужили основой для создания подхода РУП.

РУП основан на наборе из 6 ключевых принципов бизнес-управляемой разработки, сокращённо называемый ABCDEF:

1. Адаптация процесса.

2. Баланс приоритетов заинтересованных лиц.

3. Сотрудничество между командами.

4. Демонстрация результата итерационно.

5. Эволюция (рост) уровня абстракции.

6. Фокусировка непрерывно на качестве.

Эти принципы были определены П. Кроллом и У. Ройсом.

IBM Rational Unified Process (RUP)

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

На сегодняшний день практически все ведущие компании — разработчики технологий и программных продуктов ( IBM , Microsoft , Oracle , Computer Associates , Sybase и др.) располагают развитыми технологиями создания ПО, которые создавались как собственными силами, так и за счет приобретения продуктов и технологий, созданных небольшими специализированными компаниями.

Rational Unified Process -это одна из наиболее совершенных технологий, претендующих на роль мирового корпоративного стандарта. RUP представляет собой программный продукт, разработанный компанией IBM Rational Software . RUP является результатом объединения подходов Rational Approach и Objectory Process , происшедшего после слияния в 1995 году компаний Rational Software и Objectory AB (созданной Иваром Якобсоном).

RUP в значительной степени соответствует стандартам и нормативным документам, связанным с процессами жизненного цикла ПО и оценкой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, CMM и др.).

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


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

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

1.Начальный уровень — это основной стандарт. К данному уровню, как правило,

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

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

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

4. Управляемый уровень. На этом уровне добавляются следующие процессы:

  • управление производительностью и продуктивностью
  • количественное управление проектом

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

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

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

Из градации уровней видно, что технологические требования сохраняются только до третьего уровня, далее же в основном следуют требования к административному управлению. То есть уровни 4 и 5 по большей части управленческие и для их достижения важно не только выпустить программный продукт, но и проанализировать ход проекта, а также построить планы на будущий проект, основываясь на текущих шаблонах. Применение данных подходов должно обеспечить планомерно-плавное улучшение используемых процессов. Применение RUP и рабочих инструментов IBM Rational гарантирует получение как минимум третьего уровня CMM . Основными принципами методологии RUP являются:

  1. Итерационный и инкрементный (наращиваемый) подход к созданию ПО.
  2. Планирование и управление проектом на основе функциональных требований к системе — вариантов использования.
  3. Построение системы на базе архитектуры ПО.

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

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

Рис. 2. Общее представление RUP.

На рисунке показано общее представление RUP в двух измерениях:

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

Итерационный (итеративный) и инкрементный (наращиваемый) подход к созданию ПО

Большая часть команд, разрабатывающих программное обеспечение, до сих пор использует в своих проектах каскадную разработку (waterfall process), при фазы выполняются в четкой последовательности: сначала требования, затем анализ и проектирование, потом реализация/интеграция и затем тестирование. Или, что более обычно, модифицированную каскадную разработку с добавлением к вышеописанному ходу действий циклов обратной связи. Такой подход заставляет ключевых членов группы простаивать довольно продолжительное время, а тестирование откладывается на самый конец жизненного цикла проекта, когда проблемы, как правило, являются серьезными, исправлять их дорого и это ставит под угрозу сроки выхода конечного продукта.

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

Рис. 3. Итеративная разработка в RUP.

Итеративный подход доказал свои преимущества по сравнению с каскадным по многим пунктам.

  • Итеративный подход приспособлен к меняющимся требованиям . Изменение требования и «распознавание функциональности», — добавление свойств, определяемое заказчиком или нуждами технологии — всегда было самым главным источником проблем проектов. Это приводило к опозданию с выпуском, нарушению графиков, неудовлетворению заказчиков и т.п. Итеративная разработка концентрирует внимание группы на создании и демонстрации исполняемой программы в течение нескольких недель, что заставляет сосредоточится на наиболее существенных требованиях.
  • Своевременная интеграция . Оставить интеграцию на самый конец означает получить переработки с большими затратами времени — иногда до 40% всего объема проекта. Чтобы избежать этого, итеративный подход разбивает проект на небольшие итерации, каждая из которых заканчивается интеграцией, при которой строительные блоки постепенно и непрерывно интегрируются, что сводит к минимуму позднейшую переработку.
  • Риски обнаруживаются и устраняются на ранних итерациях. Итеративный подход RUP минимизирует риск на ранних итерациях, когда тестируются все компоненты. Поскольку каждая итерация задействует многие аспекты проекта, такие как инструменты, готовое программное обеспечение и навыки членов группы, в можете быстро обнаружить, является ли предполагаемый риск реальным, а также выявить новые, неожиданные риски в то время, когда их легче и не так дорого снять.
  • Менеджеры имеют возможность внесения тактических изменений в продукт . Итеративная разработка быстро создает исполняемую архитектуру (хотя и с ограниченной функциональностью), которую можно использовать для быстрого выпуска продукта с некоторыми ограничениями, чтобы ответить на действия конкурента.
  • Облегчается повторное использование . Гораздо легче определить общие части тогда, когда они уже частично спроектированы или реализованы в итерациях, чем распознавать их при планировании.
  • Дефекты можно найти и исправить за несколько итераций . Это обеспечивает создание четкой архитектуры и высококачественного приложения. Просчеты обнаруживаются еще в ранних итерациях, а не в ходе массированной тестовой фазы в конце. Узкие места производительности обнаруживаются тогда, когда на них еще можно повлиять, а не перед самым выпуском продукта.
  • Лучшее использование персонала в проекте . Многие организации совмещают использование каскадного подхода с организацией по типу конвейера: аналитики посылают готовые требования проектировщикам, которые отсылают свой продукт программистам, которые посылают компоненты специалистам по интеграции, которые отсылают систему тестировщикам. Такие многочисленные переходы являются источниками ошибок и недопонимания и заставляют людей меньше чувствовать ответственность за конечный продукт. Итеративный процесс расширяет области компетенции членов группы, разрешая им выполнять много ролей, позволяя менеджеру проекта лучше использовать имеющийся персонал, и одновременно убивает вредные передачи.
  • Члены команды учатся на ходу . Участники проекта на протяжении цикла разработки получают возможность учиться на своих ошибках от одной итерации к другой. В результате изучения более ранних итераций можно получить больше возможностей для обучения. При использовании каскадного подхода у вас есть только одна попытка для проектирования, кодирования и тестирования.
  • Улучшается процесс разработки сам по себе и становится по ходу работы более совершенным . Оценка в конце итерации позволяет не только изучить состояние проекта с точки зрения продукта или графика, но также проанализировать, что можно улучшить в организации и технологии в следующей итерации.

Структура процессов в RUP

На рис.2 показана общая архитектура Rational Unified Process . У процесса есть два аспекта, или, если угодно, два измерения:

Динамическое измерение

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

  • начальная стадия (inception)
  • стадия разработки (elaboration)
  • стадия конструирования (construction)
  • стадия ввода в действие (transition)

Каждая стадия завершается в четко определенной контрольной точке (milestone). В этот момент времени должны достигаться важные результаты и принимаются критически важные решения о дальнейшей разработке.

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

  • общее описание системы: основные требования к проекту, его характеристики и ограничения
  • начальная модель вариантов использования (степень готовности 10-20%)
  • начальный проектный глоссарий (словарь терминов)
  • начальный бизнес-план
  • план проекта, отражающий стадии и итерации
  • один или несколько прототипов

На стадии разработки выполняются более детальные требования к системе, выполняется высокоуровневый анализ предметной области и проектирование для построения базовой архитектуры системы, создается план конструирования и устраняются наиболее рискованные элементы проекта. Результатами стадии разработки являются:

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

Стадия разработки занимает около пятой части общей продолжительности проекта. Основными признаками завершения стадии разработки являются два события:

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

RUP представляет собой итерационный и пошаговый процесс разработки, в котором программное обеспечение разрабатывается и реализуется по частям. На стадии конструирования построение системы выполняется путем серии итераций. Каждая итерация является своего рода мини-проектом. На каждой итерации для конкретных вариантов использования выполняются анализ, проектирование, кодирование, тестирование и интеграция. Итерация завершается демонстрацией результатов пользователям и выполнением системных тестов с целью контроля корректности реализации вариантов использования. Назначением этого процесса является снижение степени риска. Причиной появления риска часто является откладывание решения сложных проблем на самый конец проекта. Тестирование и интеграция — это достаточно крупные задачи, они всегда занимают больше времени, чем ожидается. Чем позже выполнять тестирование и интеграцию, тем более трудными задачами они становятся и тем более способны дезорганизовать весь проект.

Помимо конструирования, итерации могут присутствовать во всех стадиях, однако конструирование — это ключевая стадия. Результатом стадии конструирования является продукт, готовый к передаче конечным пользователям. Как минимум, он содержит:

  • ПО, интегрированное на требуемых платформах
  • руководство пользователя
  • описание текущей реализации

Назначением стадии ввода в действие является передача готового продукта в распоряжение пользователей. Данная стадия включает:

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


На стадии ввода в действие продукт не дополняется никакой новой функциональностью (кроме самой минимальной и абсолютно необходимой). Здесь только вылавливаются ошибки. Хорошим примером для стадии ввода в действие может служить период времени между выпуском бета-версии и окончательной версии продукта.

Статическое измерение

Статический аспект RUP представлен четырьмя основными элементами:

  • роли
  • виды деятельности
  • рабочие продукты
  • дисциплины

Понятие « роль » (role) определяет поведение и ответственность личности или группы личностей, составляющих проектную команду. Одна личность может играть в проекте много различных ролей.

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

Дисциплина (discipline) соответствует понятию технологического процесса и представляет собой последовательность действий, приводящую к получения значимого результата. В рамках RUP определены шесть основных дисциплин:

  • построение бизнес — моделей
  • определение требований
  • анализ и проектирование
  • реализация
  • тестирование
  • развертывание

и три вспомогательных:

  • управление конфигурацией и изменениями
  • управление проектом
  • создание инфраструктуры.

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

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

UML — это стандартный язык изображения различных моделей; он не может подсказать, как разрабатывать программное обеспечение. Этот язык предоставляет словарь, но не объясняет, как написать книгу. Поэтому наряду с языком UML корпорация IBM Rational Software разработала взаимодополняющий продукт — Rational Unified Process . RUP — это консультант по вопросам эффективного использования языка UML в моделировании. Он рассказывает, какие модели необходимы, почему они необходимы и как их создавать.

При применении и внедрении RUP команды могут допустить распространенные ошибки. Основываясь на опыте специалистов по эксплуатации из компании Rational, приобретенном при работе с тысячами заказчиков в течение многих лет подведем итоги. RUP — это методология, позволяющая в широком диапазоне выбирать степень формализации и итеративности процесса разработки в зависимости от особенностей проектов и разрабатывающей организации. За счет правильного выбора показателей возможно существенное снижение стоимости и/или сроков разработке при гарантии необходимого качества ПО. С другой стороны, RUP позволяет легко поднять степень формализма разработки, если это нужно, например, для выполнения дополнительных требований заказчика или для успешной сертификации на достаточно высокий уровень CMM . Хорошо освоенный RUP является универсальным процессом, который можно успешно использовать в различных проектах. Для организации достаточно освоить RUP и способы его настройки, чтобы иметь в запасе несколько вариантов процесса разработки для разных типов проектов.

Использование RUP для небольших проектов: расширение экстремального программирования

Аннотация

Rational Unified Process (RUP) представляет собой целостную методологию организации процессов разработки программного обеспечения, которая включает в себя несколько заранее сформированных реферативных реализаций. Процессы, организуемые на основе RUP, варьируются от наиболее простых – предназначенных для небольших проектов с коротким циклом разработки – до более сложных процессов, покрывающих более широкий спектр потребностей больших, возможно даже распределенных, групп разработчиков. RUP успешно применяется в проектах любых типов и объемов. Данная статья описывает, как применять упрощенную версию RUP в небольших проектах. Мы описываем эффективные способы применения приемов экстремального программирования (XP – eXtreme Programming) в более широком контексте полного цикла проекта.

Введение

Короткая история

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

Все начиналось просто замечательно. Первые 6 месяцев я работал в основном в одиночку – долгие, приятные часы. Моя продуктивность была просто невероятной, и я сделал одну из лучших работ за всю свою карьеру. Циклы разработки были короткими, и я обычно выпускал несколько важных новых частей системы каждые пару недель. Взаимодействие с пользователями было простым и непосредственным – мы все были участниками одной сплоченной команды и не обращали внимания на формальности и документы. Также мало формальностей было и в проектировании. Код был проектом, и проект был кодом. Все было отлично!

Все было отлично. Пока… По мере роста системы появлялись новые работы. Существующий код нужно было изменять в соответствии с новыми проблемами, и мы пересмотрели наши представления о том, что же нам действительно нужно делать. Я нанял несколько человек для помощи в разработке. Мы работали как единый организм, часто попарно занимаясь разными частями проблемы. Это упрощало взаимодействие, и мы могли отбросить формальности.

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

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

Когда система выросла в объеме и усложнилась, случилось нечто неожиданное – оказалось, что архитектура системы требует пристального внимания. Вначале архитектура по преимуществу существовала в моей голове, позднее – в нескольких неразборчивых заметках или обрывочных схемах. Однако с увеличением количества участников проекта стало труднее сохранять контроль над архитектурой. Так как не все знали предысторию системы так же как я, они не могли видеть влияние отдельных конкретных изменений на архитектуру. Мы были вынуждены определить архитектурные ограничения системы в более строгих терминах. Любые изменения, которые могли повлиять на архитектуру, требовали группового консенсуса и, в конечном счете, моего одобрения. Мы обнаружили, что это тяжелый путь и нам пришлось пережить несколько болезненных ситуаций, прежде чем мы действительно осознали важность архитектуры.

Это реальная история. Она описывает лишь некоторые неприятные уроки этого проекта. Этот опыт отличается от общей практики только одним: некоторые из нас участвовали в этом от начала до конца в течение нескольких лет. Обычно люди приходят и уходят из проекта и не видят отдаленных результатов своих действий. Данному проекту могла помочь хотя бы небольшая формализация процесса. Слишком большая заорганизованность процессов засасывает, но отсутствие установленных процедур приводит к новым рискам. Также как человек, вкладывающий инвестиции в слишком рискованные акции ожидает только высоких дивидендов, группа, уделяющая слишком мало внимания процессам, игнорирует главные риски окружения своего проекта и “надеется на лучшее, но не готова к худшему”.

Общие положения

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

Мы посмотрим, как выбирать правильный уровень процессов, используя две популярные методологии: RUP (Rational Unified Process) фирмы Rational и XP (eXtreme Programming – экстремальное программирование). Мы покажем, как можно применять RUP в небольших проектах, и как это решает многие вопросы, не рассматриваемые в XP. Комбинация дает команде разработчиков методику, необходимую для устранения рисков и достижения своих целей по поставке программного продукта.

RUP – это схема процессов, разработанная в Rational Software. Это итеративная методология, основанная на шести признанных в отрасли лучших технологиях (см. RUP appendix). Разворачиваясь во времени, проект на основе RUP проходит через четыре фазы:

  • фаза обследования (Inception),
  • фаза проработки проекта (Elaboration),
  • фаза построения системы (Construction),
  • фаза передачи в эксплуатацию (Transition).

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

Рис. 1. Типичная последовательность итераций.

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

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

XP это упрощенный, ориентированный на кодирование процесс, для небольших проектов. Это интеллектуальное детище Кента Бека и привлекло внимание программной индустрии в результате выполнения проекта С3 в Chrysler Corporation где-то в 1997 году. Также как и RUP, эта технология основана на итерациях, объединяющих некоторые приемы, такие как небольшие релизы, простое проектирование, тестирование и постоянная интеграция. XP предлагает несколько подходов, которые эффективны для соответствующих проектов и обстоятельств, но содержит неочевидные предположения, работы и роли.

RUP и XP исходят из различных философских основ. RUP – это система процессных компонент, методов и техник, которые вы можете применить в любом конкретном программном проекте. Предполагается, что пользователь будет адаптировать RUP. С другой стороны XP – более ограниченный процесс, требующий дополнений для того, чтобы соответствовать полному циклу разработки проекта. Эта разница объясняет предпочтения в сообществе разработчиков программного обеспечения. Разработчики крупных систем рассматривают RUP в качестве решения своих проблем, в то время как сообщество разработчиков малых систем решение своих проблем видит в XP. Наш опыт показывает, что большинство программных проектов находится где-то посередине – в попытке достичь правильного уровня процессов для своей ситуации. Ни одна из границ спектра для них не является достаточной.

Когда вы объединяете универсальность RUP с некоторыми из техник XP, вы достигаете правильного соотношения процессов, что является привлекательным для всех членов команды проекта и служит предотвращению всех основных рисков проекта. Для команды небольшого проекта, работающей в окружении с относительно высоким уровнем доверия, где пользователь является участником команды, XP подходит чрезвычайно хорошо. По мере того, как команда становится более распределенной и объем кода возрастает, или при плохой проработке архитектуры, вам требуется что-то иное. Вам нужно нечто большее, чем XP, для проектов, в которых принят “контрактный” стиль взаимодействия с пользователем. RUP является базой, на которой вы можете построить XP с более надежным набором техник, чем обычно требуется для этого подхода.

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

Начало проекта – Inception

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

Во время первоначального обследования вы формируете бизнес прецеденты для разработки программного обеспечения. Ключевым артефактом, производимым в результате первоначального обследования, является концепция системы (Vision). Это описание системы на верхнем уровне. Оно объясняет всем, что собой представляет система, а также может определять, кто и для чего будет ее использовать, какие возможности должны в ней присутствовать и какие существуют ограничения. Концепция системы может быть очень короткой, возможно всего один – два параграфа. Часто в концепции сформулированы критически важные возможности программы, которые должны быть предоставлены заказчику.

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

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

RUP специфицирует четыре важных задачи, решаемых на этапе начального обследования:

  • Формулировка рамок проекта. Если мы собираемся разрабатывать систему, мы должны знать, что она собой представляет, и как она будет удовлетворять требованиям заказчиков. При решении этой задачи мы определяем контекст и наиболее важные требования с достаточной степенью детализации для формирования критериев приемки продукта.
  • Планирование и подготовка бизнес прецедентов. Руководствуясь виденьем, мы определяем свою стратегию устранения риска, разрабатываем предварительный план проекта и определяем известные затраты, календарный план и прибыльность работ.
  • Синтез предварительной архитектуры. Если в рассматриваемой системе достаточно мало новшеств, и она имеет ясную архитектуру, вы можете пропустить этот шаг. Как только нам становятся известны требования заказчика, мы выделяем время на рассмотрение потенциально возможных архитектурных решений. Новые технологии приносят возможность новых и улучшенных решений для проблем программного обеспечения. Требуемое время на ранних стадиях проекта на сравнительный анализ затрат на приобретение или собственную разработку, так же как и на выбор технологий и, возможно, разработку первоначального прототипа, могут снизить некоторые из значительных рисков проекта.
  • Подготовка инфраструктуры проекта.Для любого проекта требуется инфраструктура. Используете ли вы некоторые из техник XP, такие как парное программирование, или более традиционные подходы, вам необходимо определить физические ресурсы, программные средства и процедуры, которым должна следовать команда разработчиков.


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

Утвержденные бизнес прецеденты

Заинтересованные лица получают возможность согласиться, что с точки зрения бизнеса, проект имеет смысл выполнять. И RUP и XP сходятся в том, что лучше как можно раньше обнаружить, что проект выполнять не стоит, чем тратить ценные ресурсы на бессмысленный проект. XP, как это описано в Planning Extreme Programming, достаточно гибко относится к тому, как проект начинается и какие роли привлекаются (в контексте существующего бизнеса или системы это представляется очевидным), но в рамках своей фазы рассмотрения (Exploration) XP имеет дело с артефактами, эквивалентными получаемым на фазе начального обследования в RUP. Рассматриваете ли вы неформально вопросы предметной области в XP или формируете артефакты бизнес прецедентов первоклассного проекта в RUP, вам необходимо обратить на них внимание.

Список рисков

Вы ведете список рисков в течение всего проекта. Это может быть простой список рисков с планируемой стратегией их сокращения. Рискам присваиваются приоритеты. Все участники проекта могут видеть, что представляют собой риски, и как вы учитываете их в каждый конкретный момент. Кент Бек описывает набор рисков, которые снижаются с помощью XP и как обеспечивается их снижение, но не дает универсального подхода для борьбы с рисками.

Предварительный план проекта

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

План приемки проекта

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

План для начальной итерации проработки проекта (Elaboration)

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

Исходная модель прецедентов

Несмотря на кажущееся излишним усложнением и формализмом, это достаточно просто. Набор прецедентов соответствует “историям”, записываемым заказчиком в XP. Различие заключается в том, что модель прецедентов содержит полный набор действий, инициируемых актером (кем-то или чем-то внешним по отношению к системе), которые имеют очевидную значимость. Прецедент может включать несколько историй XP. Для определения функциональных границ проекта RUP рекомендует идентифицировать прецеденты и актеров во время начального обследования. Концентрация внимания на полном, с точки зрения пользователя, наборе действий помогает произвести декомпозицию системы на части, имеющие самостоятельное значение. Это, в свою очередь, дает возможность спланировать реализацию функциональности таким образом, чтобы передавать пользователю что-то в конце каждой итерации (возможно за исключением только итераций начального обследования и проработки проекта).

Как RUP, так и XP, помогают нам удостовериться, что мы не окажемся в ситуации, когда готово около 80% системы, но при этом нет ничего завершенного для передачи пользователю. Мы всегда предпочитаем иметь возможность разрабатывать системы, приносящие какую-либо пользу заказчику.

Модель прецедентов в этот момент идентифицирует прецеденты использования и актеров с минимальной детализацией или вообще без нее. Это может быть простой текст или диаграммы UML (Unified Modeling Language – универсальный язык моделирования), нарисованные от руки или с помощью графического редактора. Такая модель помогает нам убедиться, что мы включили необходимые заинтересованным лицам функции, ничего не забыв, и позволяет легко представить систему в целом. Для прецедентов назначаются приоритеты на основе таких факторов как риск, важность для заказчика и техническая сложность. Ни один из артефактов начального обследования не должен быть излишне формальным или объемным. Делайте их настолько простыми и строгими, насколько это вам необходимо. XP включает советы по планированию приемки системы. RUP привносит кое-что еще на ранних стадиях проекта. Эти небольшие дополнения могут примести существенные дивиденды при учете более полного набора рисков.

Проработка проекта – Elaboration

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

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

XP замещает представление архитектуры “метафорой”. Метафора отражает часть архитектуры, тогда как оставшиеся части являются естественным результатом разработки кода. В XP предполагается, что архитектура появляется в результате простейшего проектирования и постоянного реформирования (refactoring) кода.

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

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

Наряду с тем, что излишнее внимание к будущим возможностям, которые могут никогда и не возникнуть, действительно бесполезно, мы верим, что достаточное внимание к будущему – вещь предусмотрительная. Сколько компаний могут позволить себе постоянно переписывать или даже переформировывать код?

В любом проекте во время проработки проекта вы должны решить, как минимум, три задачи:

  • Определить, проверить и обосновать архитектуру.Используйте список рисков для разработки возможных архитектур, полученных на фазе первоначального обследования. Мы заинтересованы в том, чтобы проектируемое программное обеспечение было реализуемо. Если выбранная технология достаточно известна или система не очень сложна, этот этап не займет много времени. Если вы расширяете существующую систему, этот этап может вообще не потребоваться, если существующая архитектура не требует изменений. Когда присутствует реальный риск, связанный с архитектурой, вы не захотите оставить архитектуру на волю случая. Как часть решения этой задачи вы можете осуществить выбор некоторых компонент для принятия решений относительно их покупки, разработки или повторного использования. Если затраты будут велики, вы можете разбить их на несколько составляющих работ.
  • Уточнение Концепции системы. Во время фазы начального обследования вы разработали концепцию. После того как вы определили реализуемость проекта, и владельцы требований получили возможность просмотреть и прокомментировать систему, могут возникнуть изменения в документе, описывающем концепцию системы, и в требованиях. Пересмотр концепции и требований обычно выполняется во время проработки проекта. К концу проработки проекта у вас появится ясное понимание наиболее важных прецедентов, которые влияют на архитектурные и плановые решения. Заинтересованные лица должны согласиться с тем, что текущая версия концепции системы будет реализована, если вы выполните текущий план разработки полной системы в контексте текущей архитектуры. Количество изменений должно уменьшиться на последующих итерациях, но вы должны предусмотреть выделение некоторого времени на управление требованиями на каждой из итераций.
  • Создание и обоснование планов итераций для фазы построения системы (Construction). Теперь детализируйте ваш план. В конце каждой итерации вы возвращаетесь к плану и модифицируете его по необходимости. Модификации обычно случаются из-за неправильной оценки затрат, изменения бизнес окружения или изменения требований. Назначьте приоритеты для прецедентов, сценариев и технических затрат, а затем распределите их по итерациям. В конце каждой итерации вы планируете иметь рабочий продукт, имеющий значение для ваших владельцев требований.

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

Фаза проработки проекта в версии RUP охватывает элементы фаз исследования (Exploration) и утверждения (Commitment) по версии XP. Подход XP к техническим рискам, таким как новизна и сложность, – это “импульсное” решение. Выделите какое-то время на эксперименты для оценки затрат. Этот прием помогает во многих случаях. Когда существует больший риск, не покрывающийся одним прецедентом или историей, вам необходимо приложить больше усилий, чтобы убедиться в успехе системы и точной оценке затрат.

Обычно во время проработки проекта вы обновляете артефакты, полученные в ходе начального обследования, такие как требования и список рисков. Артефакты, которые могут появиться во время проработки проекта:

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

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

Заглавная страница

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

Проект wikipedia.green имеет одно важное преимущество. К каждой опубликованной статье есть качественное видео. Посетители нашего ресурса могут не только прочесть информацию, но и просмотреть видео-ролик. Для удобства пользователей создан поиск в правом верхнем углу. Чтобы редактировать или публиковать текстовый контент, нужно создать свою учетную запись.

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

Первое сражение при Булл-Ран

Первое сражение при реке Булл-Ран (англ. First Battle of Bull Run ), также Первое сражение при Манассасе) — первое крупное сухопутное сражение Гражданской войны в США. Состоялось 21 июля 1861 года возле Манассаса (штат Виргиния). Федеральная армия под командованием генерала Ирвина Макдауэлла атаковала армию Конфедерации под командованием генералов Джонстона и Борегара, но была остановлена, а затем обращена в бегство. Федеральная армия ставила своей целью захват важного транспортного узла — Манассаса, а армия Борегара заняла оборону на рубеже небольшой реки Булл-Ран. 21 июля Макдауэлл отправил три дивизии в обход левого фланга противника; им удалось атаковать и отбросить несколько бригад конфедератов. Через несколько часов Макдауэлл отправил вперёд две артиллерийские батареи и несколько пехотных полков, но южане встретили их на холме Генри и отбили все атаки. Федеральная армия потеряла в этих боях 11 орудий, и, надеясь их отбить, командование посылало в бой полк за полком, пока не были израсходованы все резервы. Между тем на поле боя подошли свежие бригады армии Юга и заставили отступить последний резерв северян — бригаду Ховарда. Отступление Ховарда инициировало общий отход всей федеральной армии, который превратился в беспорядочное бегство. Южане смогли выделить для преследования всего несколько полков, поэтому им не удалось нанести противнику существенного урона.

«Хлеб» (укр. «Хліб» ) — одна из наиболее известных картин украинской советской художницы Татьяны Яблонской, созданная в 1949 году, за которую ей в 1950 году была присуждена Сталинская премия II степени. Картина также была награждена бронзовой медалью Всемирной выставки 1958 года в Брюсселе, она экспонировалась на многих крупных международных выставках.

В работе над полотном художница использовала наброски, сделанные летом 1948 года в одном из наиболее благополучных колхозов Советской Украины — колхозе имени В. И. Ленина Чемеровецкого района Каменец-Подольской области, в котором в то время было одиннадцать Героев Социалистического Труда. Яблонская была восхищена масштабами сельскохозяйственных работ и людьми, которые там трудились. Советские искусствоведы отмечали, что Яблонская изобразила на своей картине «новых людей», которые могут существовать только в социалистическом государстве. Это настоящие хозяева своей жизни, которые по-новому воспринимают свою жизнь и деятельность. Произведение было задумано и создано художницей как «обобщённый образ радостной, свободной творческой работы». По мнению французского искусствоведа Марка Дюпети, эта картина стала для своего времени программным произведением и образцом украинской реалистической живописи XX столетия.

Введение В Rational Unified Process. Методология И Технология

Автор: Новичков Александр, СМ-Консалт

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

Подход к разработке

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

IBM Rational Unified Process — это итерационный процесс. Создавать современные сложные программные системы последовательно, т. е. сначала определять все проблемы, затем принимать все проектные решения, формировать ПС и, наконец, проверять изделие, невозможно. Такой подход (называемый каскадным подходом или «водопадом») в современной информационной индустрии не оправдывает себя, поскольку его использование часто приводит к непредсказуемому увеличению проектной стоимости и сроков выпуска ПС. Эффективной альтернативой «водопаду» служит итерационный процесс разработки ПС.

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

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

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

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

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

Четко определенный процесс


RUP создавался по методике, используемой при проектировании ПС. В частности, моделирование производилось с помощью Software Process Engineering Metamodel (SPEM) — стандарта моделирования процессов, основанного на Unified Modeling Language (UML). У процесса есть два измерения:
Динамическая структура. Горизонтальное измерение представляет собой динамическую структуру или временное измерение процесса. Оно показывает, как процесс, выраженный в форме циклов, фаз, итераций и вех, развертывается в ходе жизненного цикла проекта.

Статическая структура. Вертикальное измерение представляет собой статическую структуру процесса. Оно описывает, как элементы процесса — задачи, дисциплины, артефакты и роли — логически группируются в дисциплины или рабочие процессы (workflows).

Динамическая структура RUP состоит из четырех фаз: Inception, Elaboration, Construction и Transition. Фазы могут подразделяться на итерации. Переход с фазы на фазу возможен только после выполнения задач фазы и представляет собой контрольную точку (milestone) процесса.

Статическая структура RUP состоит из дисциплин, в которые группируются работы, задачи, артефакты и роли. Для описания осмысленной последовательности выполнения работ и задач используются рабочие процессы. Они описывают кто, что, как и когда выполняет в процессе. В RUP входят 6 основных дисциплин:
— Бизнес-моделирование (Business modeling);
— Управление требованиями (Requirements);
— Анализ и Проектирование (Analysis and Design);
— Реализация (Implementation);
— Тестирование (Test);
— Развертывание (Deployment).
И три вспомогательные:
— Управление проектом (Project management);
— Управление изменениями (Change management);
— Среда (Environment).

В отличие от каскадного подхода ( «водопада»), в RUP все дисциплины выполняются практически во всех фазах жизненного цикла ПС. Однако, в зависимости от фазы, меняются текущие цели проекта и соотношение между объемами работ, соответствующих различным дисциплинам.

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

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

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

Фаза Transition жизненного цикла посвящена подготовке разработанного продукта к передаче его заказчику или к тиражированию и распространению (если это «коробочный» продукт).

Готовый продукт

IBM Rational Unified Process представляет собой готовый продукт. Он состоит из нескольких частей.
Это:
— лучшие практические методики, предоставляемые разработчикам;
— веб сайт, содержащий описание процесса и интегрированный со многими инструментальными средствами;
— средства конфигурации, позволяющие настраивать процесс под нужды конкретного проекта;
— средства кастомизации, позволяющие создавать собственные процессы (IBM Rational Workbench);
— сообщество пользователей RUP, участие в котором поможет вам обмениваться опытом (в том числе и готовыми описаниями процессов) с другими разработчиками.
Пользователи RUP могут либо выбрать одно из типовых представлений процесса, либо создать свое собственное.

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

Использование инструментальных средств

Для обеспечения инструментальной поддержки всех процессов жизненного цикла разработки и сопровождения ПС RUP рекомендует использование специализированных инструментальных средств IBM Rational:
Управление требованиями – IBM Rational RequisitePro;
Визуальное моделирование и генерация объектного кода – IBM Rational Rose, IBM Rational XDE;
Разработка — IBM Rational RapidDeveloper
Конфигурационное управление – IBM Rational ClearCase;
Управление изменениями – IBM Rational ClearQuest;
Автоматизированное документирование – IBM Rational SoDA;
Автоматизированное тестирование – IBM Rational TeamTest, IBM Rational TestFactory, IBM Rational Robot, IBM Rational PurifyPlus, IBM Rational SiteCheck и IBM Rational SiteLoad.

RUP и другие подходы к разработке ПО

IBM Rational Unified Process позволяет компании-разработчику настраивать весь процесс разработки ПС. В отличие от большинства современных методологий или требований к процессу разработки, ориентированных на строго определенный уровень формализации процесса (как правило, либо очень высокий, либо напротив, очень низкий), RUP позволяет получить именно тот уровень формализации, который необходим в проекте.

При разработке ПС для государственных предприятий и в ряде других ситуаций компании-разработчику приходится выполнять формальные требования отечественных и международных стандартов (ГОСТы серий 19 и 34, ГОСТ ИСО/МЭК 12207 и др.). В этом случае можно настроить RUP на достаточно высокий уровень формализации процесса. Более того, при использовании инструментальных средств IBM Rational несложно разработать шаблоны документов, которые будут создаваться автоматически с помощью IBM Rational SoDA на основе стандартных моделей и артефактов и соответствовать требованиям ГОСТ.

Использование RUP с достаточно высоким уровнем формализации процесса также может помочь компании-разработчику выполнять требования сертификации CMM. Поскольку RUP представляет собой хорошо документированный процесс, внедрение RUP поможет вам достигнуть уровней 2 и 3 СММ. В еще большей степени RUP может помочь при внедрении CMMI, поскольку CMMI в большей степени соответствует современному итерационному подходу к разработке ПС.

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

Внедрение RUP

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

Компания CM-Consult предлагает услуги по адаптации и внедрению RUP в конкретной компании-разработчике. Мы можем подобрать для вас процесс требуемой степени формализации. Разработать шаблоны документов. Обучить ваших сотрудников как особенностям разработки ПС с использованием RUP, так и использованию в этом процессе многочисленных инструментальных средств IBM Rational. Все работы будут производиться с участием сотрудников компании-разработчика, что гарантирует передачу им всех необходимых знаний и навыков.

Компания CM-Consult предлагает осуществить на первом этапе обследование компании-заказчика и определить порядок внедрения RUP и необходимый набор инструментальных средств. Под методическим руководством опытных консультантов из компании CM-Consult специалисты компании-заказчика смогут выполнить оценку текущей организации разработки ПС в своей компании, выявить проблемы и причины их возникновения, а также способы устранения или уменьшения, ранжировать эти проблемы по тяжести последствий и важности разрешения.

На втором этапе предлагается силами сотрудников специализированного подразделения компании-заказчика выполнить один или несколько пилотных проектов под методическим руководством опытных консультантов-наставников.

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

В ходе пилотных проектов или после их завершения могут быть выработаны:
— описание порядка разработки и сопровождения ПС;
— шаблоны документов, выпускаемых в процессе разработки;
— указания по разработке артефактов проектов;
— указания по использованию инструментальных средств поддержки.

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

Читать дальше
Еще статьи автора

Унифицированный процесс Rational (RUP)

В фазе «Внедрение» создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.

См. также

Ссылки

  • Статьи о Rational Unified Process на русском языке на сайте компании СМ-Консалт (рус.)
Разработка программного обеспечения
Известные
деятели

Кент Бек • Гради Буч • Фред Брукс • Barry Boehm • Уорд Каннингем • Оле-Йохан Даль • Том Демарко • Эдсгер Вибе Дейкстра • Дональд Кнут • Мартин Фаулер • Чарльз Энтони Ричард Хоар • Watts Humphrey • Майкл Джексон • Ивар Якобсон • Craig Larman • James Martin • Мейер Бертран • Дэвид Парнас • Winston W. Royce • James Rumbaugh • Никлаус Вирт • Эдвард Йордан • Стив Макконнелл

Моделирование данных • Архитектура ПО • Функциональная спецификация • Язык моделирования • Парадигма • Методология • Процесс разработки • Качество • Обеспечение качества • Структурный анализ)

Направления
Модели
разработки
Другие модели

CMM • CMMI • Данных • Function model • IDEF • Информационная • Metamodeling • Object model • View model • UML

Wikimedia Foundation . 2010 .

Смотреть что такое «Rational Unified Process» в других словарях:

Rational Unified Process — Unified Process Processus unifié (PU ou UP en anglais pour Unified Process) est une méthode de prise en charge du cycle de vie d’un logiciel et donc du développement, pour les logiciels orientés objets. C’est une méthode générique, itérative et… … Wikipédia en Français

Rational Unified Process — Der Rational Unified Process (RUP) ist ein kommerzielles Produkt der Firma Rational Software, die seit 2003 Teil des IBM Konzerns ist. Es beinhaltet sowohl ein Vorgehensmodell zur Softwareentwicklung als auch die dazugehörigen… … Deutsch Wikipedia

IBM Rational Unified Process — The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable… … Wikipedia

Unified Process — The Unified Software Development Process or Unified Process is a popular iterative and incremental software development process framework. The best known and extensively documented refinement of the Unified Process is the Rational Unified Process … Wikipedia

Unified Process — Der Rational Unified Process (RUP) ist ein objektorientiertes Vorgehensmodell zur Softwareentwicklung und ein kommerzielles Produkt der Firma Rational Software, die seit 2002 Teil des IBM Konzerns ist. IBM entwickelt den RUP und die zugehörige… … Deutsch Wikipedia

Unified Process — Processus unifié (PU ou UP en anglais pour Unified Process) est une méthode de prise en charge du cycle de vie d’un logiciel et donc du développement, pour les logiciels orientés objets. C’est une méthode générique, itérative et incrémentale,… … Wikipédia en Français

Enterprise Unified Process — Der Enterprise Unified Process (kurz: EUP) ist eine erweiterte Variante des Rational Unified Process und wurde ab 1999 von Scott W. Ambler und Larry Constantine entwickelt. Eine grundlegende Überarbeitung und erneute Veröffentlichung wurde 2005… … Deutsch Wikipedia

Enterprise Unified Process — The Enterprise Unified Process (EUP) is an extension of the Rational Unified Process developed by Scott W. Ambler the Practice Leader in Agile development at IBM Corporation.PhasesThe Unified Process defines four project phases * Inception *… … Wikipedia

Agile Unified Process — Scott Ambler s Agile Unified Process (AUP) is a simplified version of the IBM Rational Unified Process (RUP). It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet… … Wikipedia

Open Unified Process — Der Open Unified Process (OpenUP) ist ein Open Source Softwareentwicklungsprozess, der an den Rational Unified Process angelehnt ist und von der Eclipse Foundation entwickelt wird. Er ist Teil des Eclipse Process Frameworks (EPF). Der Prozess… … Deutsch Wikipedia

Мастер Йода рекомендует:  Не вставляйте в консоль скопированный из Интернета код!
Добавить комментарий