1 of 55

Методология проектирования и разработки АИС на примере RUP

МСПИСТ

17.02.2017 г.

Лекция 2

2 of 55

Методология разработки ПО

 

  • Толковый словарь русского языка" Ожегова:

"принципы и способы организации теоретической и практической деятельности" ;

"совокупность методов, применяемых в какой-либо науке".

  • А.Коберн:

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

3 of 55

Компоненты методологии разработки ПО

4 of 55

Rational Unifies Process

5 of 55

Rational Unified Process�(RUP)�процесс разработки программного обеспечения� фирмы IBM/�Rational Software Corporation

6 of 55

  • Айвором Якобсоном (Швеция) был разработан процесс Objectory
  • Модель процесса RUP унаследована от процесса Objectory
  • Итеративную разработку и архитектуру RUP унаследовал от Rational Software Corporation
  • Rational Objectory Process - результат объединения процессов Rational Approach и Objectory Process 3.8, произошедшего после слияния в 1995 г. корпорации Rational Software Corporation и Objectory AB
  • RUP (5.0) является прямым наследником Rational Objectory Process 4.1.

7 of 55

«Генеалогическое древо» RUP

8 of 55

9 of 55

История создания RUP

Objectory Process 3.8

Rational�Approach

Rational Objectory Process 4.0

1996

Rational Objectory Process 4.1

1997

SQA�Process

Requirements management

UML 0.8

Rational Unified Process 5.0

Configuration

& change Mgmt

1998

1995

Business

Engineering

Data Engineering

Objectory�UI design

Performance�testing

UML 1.1

OMT

Booch

Rational Unified Process 5.5

UML 1.3

Project management

Realtime

ROOM

1999

Rational Unified Process 2000 …

2000 …

10 of 55

Эта версия объединила управление требованиями от корпорации Requisite Inc. и процесс тестирования от корпорации SQA Inc.�В данной версии использовался UML 0.8.� В настоящее время доступна версия �RUP 2003.�Приобрести можно IBM RATIONAL Method Composer ( ~ 1000) �

11 of 55

  • RUP развивался десятилетиями и отражает коллективный опыт множества людей и компаний.
  • Процесс оформлен в виде базы знаний (гипертекст), которая снабжена поисковой системой

12 of 55

Внешний вид RUP 2002 при загрузке

13 of 55

Внешний вид RUP 2003 при загрузке

14 of 55

Диаграмма ответственности

15 of 55

RUP обеспечивает формализованный подход к определению задач и обязанностей по их решению внутри организации - разработчика программного обеспечения

16 of 55

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

17 of 55

Цель процеса RUP

 

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

18 of 55

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

19 of 55

Лучший опыт разработки ПО

20 of 55

RUP показывает:�- каким образом лучший опыт разработки ПО может быть применен в конкретных проектах��- как наиболее эффективно использовать существующие средства автоматизации в процессе разработки�

21 of 55

Процесс определяет Кто, Что, Когда и Как делает для достижения определенной цели.� С точки зрения RUP, процесс разработки – это процесс развития системы, направляемый требованиями. При этом создается либо новая система (начальный цикл проектирования), либо совершенствуется уже существующая� (цикл развития).

22 of 55

RUP.�Работники, действия, артефакты

23 of 55

Диаграмма краткого обзора действий RUP

24 of 55

RUP – процесс развития системы на основе определения первоначальных требований к системе (initial development cycle) или измененых требований (evolution cycle).

25 of 55

Для понимания RUP рассмотрим процесс разработки ПО одновременно с двух сторон:��1. Основные этапы разработки.��2. Фазы жизненного цикла.

26 of 55

27 of 55

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

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

28 of 55

RUP – обобщенная схема

29 of 55

Рассмотрение процесса разработки производится с двух точек зрения:��1. Технологической – рассматриваются различные модели и средства для разработки конечного программного продукта;��2. Административной – основное внимание уделяется срокам разработки, бюджету, работе с персоналом и др.

30 of 55

Статический аспект процесса разработки ПО формулируется в терминах основных потоков работ.

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

RUP включает в себя 9 потоков работ,

6 из которых являются основными, а оставшиеся 3 – административными (поддерживающими технологический процесс).

31 of 55

Жизненный цикл программного обеспечения (ПО)��Жизненный цикл ПО разбивается на отдельные циклы. Каждый отдельный цикл отражает очередной этап совершенствования версии программного продукта.

Отдельный цикл включает 4 фазы.

32 of 55

Завершение каждой фазы разработки заранее определено с точки зрения момента окончания – контрольной точки завершения фазы (milestone).

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

33 of 55

RUP. Стадии, вехи, выпуски

34 of 55

Структура процесса – Фазы ЖЦ

Inception

Elaboration

Construction

Transition

Rational Unified Process имеет 4 фазы:

Начальная фаза – Определение границ проекта

Фаза уточнения – Определение архитектуры

Фаза конструирования – Сборка продукта

Фаза ввода в действие – Передача продукта конечным пользователям

time

35 of 55

Inception

Elaboration

Construction

Transition

Границы фаз отмечены как важные вехи

Цели ЖЦ

Архитектура� ЖЦ

Первоначальные� возможности

Версия� продукта

время

36 of 55

Итерации и фазы

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

Preliminary

Iteration

Architect.

Iteration

Architect.

Iteration

Devel.

Iteration

Devel.

Iteration

Devel.

Iteration

Transition

Iteration

Transition

Iteration

Inception

Elaboration

Construction

Transition

Вехи: Релизы

37 of 55

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

38 of 55

Первая версия ПО (внендренная и поддерживаемая, не прототип !) является результатом первого цикла прохождения процесса разработки через 4 фазы. Этот первый цикл называется� начальным циклом �(initial development cycle).

39 of 55

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

40 of 55

Эти циклы называются циклами эволюции (совершенствования) ПО (evolution cycles). Результатом каждого такого цикла является новая работоспособная и внедренная версия ПО.

41 of 55

Процесс разработки версий ПО

42 of 55

Начальная фаза разработки (Inception Phase)��Основная задача начальной фазы разработки - определение конечных целей проекта.

43 of 55

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

44 of 55

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

45 of 55

Начальная фаза завершается принятием принципиального решения о целесообразности проведения дальнейшей разработки.

46 of 55

Фаза уточнения (Elaboration) �Основными задачами фазы уточнения являются:�1. Подробный анализ предметной области;� 2. Определение не противоречащих друг другу базовых элементов архитектуры разрабатываемой системы;

47 of 55

3. Детализация плана проекта;��4. Выявление факторов риска, в наибольшей степени влияющих на успешное завершение проекта.

48 of 55

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

49 of 55

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

50 of 55

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

51 of 55

Фаза конструирования�� В течение фазы конструирования итеративно и пошагово разрабатывается конечный программный продукт

52 of 55

При этом реализуются функции системы, завершается проектирование, кодирование и тестирование ПО.

53 of 55

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

54 of 55

Фаза внедрения конечного продукта��Основная задача фазы внедрения – доведение ПО до уровня, при котором оно может реально эксплуатироваться пользователями.

55 of 55

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