История RUP

Содержание

Слайд 2

Rational Unified Process Rational Objectory Process Подход компании Ericsson Подход компании

Rational Unified Process

Rational Objectory Process

Подход компании Ericsson

Подход компании Rational

UML

Objectory Process

1967

1987

1995

1995 -

1997

1998

Слайд 3

Подход компании Ericsson. 1967 год. Ивар Якобсон разработал подход основанный на

Подход компании Ericsson. 1967 год.
Ивар Якобсон разработал подход основанный на проектировании

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

Objectory. 1987 - 1995 год. Ивар Якобсон покинул Эриксон и основал

Objectory. 1987 - 1995 год.
Ивар Якобсон покинул Эриксон и основал компанию

Objectory AB.
Компания разрабатывала процесс, названный Objectory (сокращение от Object Factory).
Последовательные рабочие процессы были представлены в виде набора требований, вариантов использования, анализа, проектирования, реализации и тестирования.
Работа над Objectory привяла к прояснению того, как работает инженер и как в основном работает бизнес.
Процесс распространили на другие области промышленности, помимо телекоммуникации и другие страны.
Слайд 5

Подход копании Rational. 1995 год. Компания Rational Software Corporation приобретает Objectory

Подход копании Rational. 1995 год.
Компания Rational Software Corporation приобретает Objectory AB.


Objectory стал частью системы Rational. Система имела упор на архитектуру и итеративную разработку.
В 1996 году Гради Буч в сформулировал два
основных принципа для архитектуры и итераций:
управляемая архитектурой разработка обычно является наилучшим способом создания очень сложных программных проектов.
чтобы стать успешным, объектно-ориентированный проект должен применять инкрементный и итеративный процесс.
Слайд 6

Rational Objectory Process (ROP). 1995 – 1997 год. В 1994 году

Rational Objectory Process (ROP). 1995 – 1997 год.
В 1994 году Гради

Буч и Джеймс Рамбо, работавшие в компании Rational Software, объединили свои усилия для создания нового языка объектно-ориентированного моделирования. В 1995 году к ним присоединился Ивар Якобсон.
Совместно разрабатывают Rational Objectory Process (ROP) и Unified Modeling Language
(UML) который использовался в качестве языка моделирования для ROP.
Слайд 7

Rational Unified Process (RUP). 1998 год. Основные принципы: Ранняя идентификация и

Rational Unified Process (RUP). 1998 год.
Основные принципы:
Ранняя идентификация и непрерывное (до

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

RUP и другие методологии.

RUP и другие методологии.

Слайд 9

Общая модель RUP Модель жизненного цикла RUP является довольно сложной, детально

Общая модель RUP

Модель жизненного цикла RUP является довольно сложной, детально проработанной

итеративно – инкрементной моделью с элементами каскадной модели. В модели RUP выделяются 4 основные фазы, 9 видов деятельности (процессов). Кроме того, в модели описывается ряд практик, которые следует применять или руководствоваться для успешного выполнения проекта. RUP ориентирован на поэтапное моделирование создаваемого продукта с помощью языка UML
Слайд 10

Общая модель RUP Основными фазами RUP являются: Фаза начала проекта (Inception).

Общая модель RUP

Основными фазами RUP являются:
Фаза начала проекта (Inception). Определяются основные

цели проекта, бюджет проекта, основные средства его выполнения – технологии, инструменты, ключевой персонал, составляются предварительные планы проекта. Основная цель этой фазы – достичь компромисса между всеми заинтересованными лицами относительно задач проекта.
Фаза проработки (Elaboration). Основная цель этой фазы – на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта, которая позволяет решать поставленные перед системой задачи и в дальнейшем используются как основа разработки системы.
Фаза построения (Construction). Основная цель этой фазы – детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры.
Фаза передачи (Transition). Цель фазы – сделать систему полностью доступной конечным пользователям. Здесь происходит окончательное развертывание системы в ее рабочей среде, подгонка мелких деталей под нужды пользователей.
В рамках каждой фазы возможно проведение нескольких итераций, количество которых определяется сложностью выполняемого проекта.
Деятельности (основные процессы) RUP делятся на 5 рабочих и 4 поддерживающие.
Слайд 11

Процессы RUP Моделирование предметной области (Business Modeling) Определение требований (Requirements) Анализ

Процессы RUP
Моделирование предметной области (Business Modeling)
Определение требований (Requirements)
Анализ и проектирование

(Analysis and Design)
Реализация (Implementation)
Тестирование (Test)
Развертывание (Deployment).
Управление конфигурациями (Configuration and Change Management).
Управление проектом (Project Management).
Управление средой проекта (Environment).
Слайд 12

Процесс итерации RUP RUP предлагает итеративный подход к проектированию и разработке

Процесс итерации RUP
RUP предлагает итеративный подход к проектированию и разработке ПС,

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

Команда RUP В моделировании бизнеса участвуют: бизнес-аналитик – специалист организации-разработчика, который

Команда RUP

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

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

Применимость RUP Для переработки устаревших систем (http://www.finecosoft.ru/ibm_rational_userupreveng)

Применимость RUP

Для переработки устаревших систем (http://www.finecosoft.ru/ibm_rational_userupreveng)