Подходы разработки ПО

Сентябрь 2, 2022

Главная
Алгебра
Подходы разработки ПО

Содержание

2. Rational Unified Process Рациональный унифицированный процесс (РУП, RUP – Rational Unified Process) – унифицированный каркасный подход,
3. Rational Unified Process Исторически РУП является развитием подхода Objectory Process, созданный А. Якобсоном как развитие его
4. Rational Unified Process РУП является сложным, детально проработанным итеративным подходом разработки. Он представляет собой адаптируемый каркас
5. Rational Unified Process Этот продукт входит как составная часть в набор инструментальных средств IBM Rational для
6. Rational Unified Process Результатом исследований стало выделение лучших практик, позволяющих устранить первопричины провала проектов. Лучшая практика
7. Итеративная разработка Итеративная разработка заключается в создании требуемой системы итерациями, что обеспечивает: снижение воздействия серьёзных рисков
8. Управление требованиями Управление требованиями включает в себя выявление, организацию и документирование требований к системе и подразумевает:
9. Компонентная архитектура Использование компонентной архитектуры даёт возможность повысить эффективность процесса разработки за счёт: повышения гибкости архитектуры
10. Визуальное моделирование Визуальное моделирование – это способ представления проблемы с помощью моделей, построенных вокруг идей из
11. Проверка качества Проверка качества реализуется с помощью тестирования сценариев. Непрерывная проверка качества обеспечивает следующие выгоды: производит
12. Контроль изменений Контроль изменений включает в себя управление запросами на изменение, управление конфигурацией и управление измерением
13. Лучшие практики Лучшие практики послужили основой для создания подхода РУП. РУП основан на наборе из 6
14. Модель ЖЦ для РУП Модель ЖЦ для РУП отражает объём работ дисциплин в фазах (рис.10.1). В
15. Модель ЖЦ для РУП Основная цель фазы 3 – детальное прояснение требований и разработка системы, удовлетворяющей
16. Рис.10.1. Модель ЖЦ для подхода RUP
17. Модель ЖЦ для подхода RUP Конец каждой фазы является некоторой вехой Всего выделено 4 вехи, совпадающие
18. Основные дисциплины Бизнес-моделирование (в общем случае – моделирование ПрО) применяется, чтобы изучить ПрО, обеспечить единство понимания
19. Основные дисциплины Анализ и проектирование служат для последовательного преобразования выявленных требований к системе в спецификации особого
20. Основные дисциплины Реализация необходима для выявления порядка организации программного кода в терминах отдельных подсистем, преобразования исходного
21. Основные дисциплины Развёртывание предназначено для доставки разрабатываемого продукта к конечному пользователю. В ходе данного процесса производится
22. Вспомогательные дисциплины Управление конфигурацией и изменениями позволяет организовать эффективную командную работу с артефактами проекта, контролировать и
23. Вспомогательные дисциплины Управление проектом включает в себя непосредственное формирование условий для эффективного хода всего проекта, определение
24. Вспомогательные дисциплины Управление средой позволяет осуществить поддержку всех участников проекта. В эту поддержку входят выбор инструментария
25. Фазы ЖЦ По трудоёмкости и затратам времени (на один цикл) фазы ЖЦ распределяются следующим образом (рис.10.2):
26. Рис.10.2. Трудоёмкость и затраты времени на фазы
27. Нагрузка основных дисциплин РУП Нагрузка основных дисциплин РУП распределяется по фазам следующим образом: в фазе Начала
29. Скачать презентацию

Слайд 2

Rational Unified Process
Рациональный унифицированный процесс (РУП, RUP – Rational Unified Process) – унифицированный

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

Слайд 3

Rational Unified Process
Исторически РУП является развитием подхода Objectory Process, созданный А. Якобсоном как

развитие его методики Объектно-ориентированная инженерия ПО. В 1987 г. автор основал компанию Objectory AB. После вливания Objectory AB в Rational в 1995 г. подход Якобсона был объединён с Rational Approach. Этот подход основан на работах У. Ройса, Ф. Крухтена и Г. Буча. Объединённый подход вначале получил название Rational Objectory Process, лишь затем, после включения поддержки бизнес-моделирования, был переименован в РУП. Кроме этого в подход был включён развивавшаяся в это время сотрудниками Rational объектно-ориентированная методика анализа и проектирования, получившая название языка UML.

Слайд 4

Rational Unified Process
РУП является сложным, детально проработанным итеративным подходом разработки. Он представляет собой

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

Слайд 5

Rational Unified Process
Этот продукт входит как составная часть в набор инструментальных средств

IBM Rational для поддержки РУП. Некоторые из этих средств благодаря возможности их расширения оказываются применимыми в качестве инструментария для других подходов. В частности, подход MSF долгое время основывался на этом наборе до разработки собственного набора средств.
Исследование различных неудачных проектов привело авторов РУП к выявлению признаков и первопричин их провала. Провал проекта обычно связан с некоторой комбинацией признаков, вызванных рядом первопричин, хотя такие проекты заканчиваются неудачей каждый по‑своему.

Слайд 6

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

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

Слайд 7

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

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

Слайд 8

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

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

Слайд 9

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

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

Слайд 10

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

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

Слайд 11

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

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

Слайд 12

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

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

Слайд 13

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

из 6 ключевых принципов бизнес-управляемой разработки, сокращённо называемый ABCDEF:
1. Адаптация процесса;
2. Баланс приоритетов заинтересованных лиц;
3. Сотрудничество между командами;
4. Демонстрация результата итерационно;
5. Эволюция (рост) уровня абстракции;
6. Фокусировка непрерывно на качестве.
Эти принципы были определены Пером Кроллом и Уолкером Ройсом.

Слайд 14

Модель ЖЦ для РУП
Модель ЖЦ для РУП отражает объём работ дисциплин в фазах

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

Слайд 15

Модель ЖЦ для РУП
Основная цель фазы 3 – детальное прояснение требований и разработка системы,

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

Слайд 16

Рис.10.1. Модель ЖЦ для подхода RUP

Слайд 17

Модель ЖЦ для подхода RUP
Конец каждой фазы является некоторой вехой
Всего выделено 4 вехи, совпадающие

с вехами УП, кроме того указаны критерии прохождения этих вех.
На протяжении этих фаз по проекту выполняются дисциплины.
РУП выделяет 6 основных и 3 вспомогательные дисциплины (рис.10.1).
Основные дисциплины: 1. Бизнес-моделирование; 2. Определение требований; 3. Анализ и проектирование; 4. Реализация; 5. Тестирование; 6. Развёртывание.
Вспомогательные дисциплины, связанные с управлением разработкой: 1. Управление конфигурацией и изменениями; 2. Управление проектом. 3. Управление средой.

Слайд 18

Основные дисциплины
Бизнес-моделирование (в общем случае – моделирование ПрО) применяется, чтобы изучить ПрО, обеспечить единство понимания

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

Слайд 19

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

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

Слайд 20

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

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

Слайд 21

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

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

Слайд 22

Вспомогательные дисциплины
Управление конфигурацией и изменениями позволяет организовать эффективную командную работу с артефактами

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

Слайд 23

Вспомогательные дисциплины
Управление проектом включает в себя непосредственное формирование условий для эффективного

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

Слайд 24

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

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

Слайд 25

Фазы ЖЦ
По трудоёмкости и затратам времени (на один цикл) фазы ЖЦ распределяются следующим образом (рис.10.2):
Построение,
Уточнение,

Внедрение
Начало.

Слайд 26

Рис.10.2. Трудоёмкость и затраты времени на фазы

Слайд 27

Нагрузка основных дисциплин РУП
Нагрузка основных дисциплин РУП распределяется по фазам следующим образом:
в фазе Начала –

Бизнес-моделирование и Определение требований,
в фазе Уточнения – Анализ и проектирование и Реализация,
в фазе Построения – Реализация и Тестирование,
в фазе Внедрения – Развёртывание.

Подходы разработки ПО

Содержание

Rational Unified ProcessРациональный унифицированный процесс (РУП, RUP – Rational Unified Process) – унифицированный

Rational Unified ProcessИсторически РУП является развитием подхода Objectory Process, созданный А. Якобсоном как

Rational Unified ProcessРУП является сложным, детально проработанным итеративным подходом разработки. Он представляет собой

Rational Unified ProcessЭтот продукт входит как составная часть в набор инструментальных средств

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

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

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

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

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

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

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

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

Модель ЖЦ для РУП Модель ЖЦ для РУП отражает объём работ дисциплин в фазах

Модель ЖЦ для РУП Основная цель фазы 3 – детальное прояснение требований и разработка системы,