Методология проектирования и разработки АИС на примере RUP
МСПИСТ
17.02.2017 г.
Лекция 2
Методология разработки ПО
"принципы и способы организации теоретической и практической деятельности" ;
"совокупность методов, применяемых в какой-либо науке".
роли, навыки, команды разработчиков, инструментарий, техники, виды деятельности, стандарты, рабочие продукты, меры качества и система ценностей, принятых в команде разработчиков
Компоненты методологии разработки ПО
Rational Unifies Process
Rational Unified Process�(RUP)�процесс разработки программного обеспечения� фирмы IBM/�Rational Software Corporation
«Генеалогическое древо» RUP
История создания 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 …
Эта версия объединила управление требованиями от корпорации Requisite Inc. и процесс тестирования от корпорации SQA Inc.�В данной версии использовался UML 0.8.� В настоящее время доступна версия �RUP 2003.�Приобрести можно IBM RATIONAL Method Composer ( ~ €1000) �
Внешний вид RUP 2002 при загрузке
Внешний вид RUP 2003 при загрузке
Диаграмма ответственности
RUP обеспечивает формализованный подход к определению задач и обязанностей по их решению внутри организации - разработчика программного обеспечения
RUP создавался как настраиваемый процесс, адаптируемый для широкого диапазона программных проектов и организаций.
Цель процеса RUP
RUP вобрал в себя многое из хорошо зарекомендовавших себя методов, применяемых в индустрии разработки ПО.
Лучший опыт разработки ПО
RUP показывает:�- каким образом лучший опыт разработки ПО может быть применен в конкретных проектах��- как наиболее эффективно использовать существующие средства автоматизации в процессе разработки�
Процесс определяет Кто, Что, Когда и Как делает для достижения определенной цели.� С точки зрения RUP, процесс разработки – это процесс развития системы, направляемый требованиями. При этом создается либо новая система (начальный цикл проектирования), либо совершенствуется уже существующая� (цикл развития).
RUP.�Работники, действия, артефакты
Диаграмма краткого обзора действий RUP
RUP – процесс развития системы на основе определения первоначальных требований к системе (initial development cycle) или измененых требований (evolution cycle).
Для понимания RUP рассмотрим процесс разработки ПО одновременно с двух сторон:��1. Основные этапы разработки.��2. Фазы жизненного цикла.
На вертикальной оси виден статический аспект процесса разработки: как он выглядит с точки зрения осуществления деятельности, необходимой для достижения поставленной цели.
Фазы жизненного цикла показаны на горизонтальной оси и отражают динамический аспект процесса разработки � (фазы, итерации, окончания этапов).
RUP – обобщенная схема
Рассмотрение процесса разработки производится с двух точек зрения:��1. Технологической – рассматриваются различные модели и средства для разработки конечного программного продукта;��2. Административной – основное внимание уделяется срокам разработки, бюджету, работе с персоналом и др.
Статический аспект процесса разработки ПО формулируется в терминах основных потоков работ.
Потоки работ описываются последовательностью действий, различными моделями и документацией.
RUP включает в себя 9 потоков работ,
6 из которых являются основными, а оставшиеся 3 – административными (поддерживающими технологический процесс).
Жизненный цикл программного обеспечения (ПО)��Жизненный цикл ПО разбивается на отдельные циклы. Каждый отдельный цикл отражает очередной этап совершенствования версии программного продукта.
Отдельный цикл включает 4 фазы.
Завершение каждой фазы разработки заранее определено с точки зрения момента окончания – контрольной точки завершения фазы (milestone).�
При этом должны быть реализованы запланированные принципиальные решения, отражающие основную цель создания ПО на данной фазе.
RUP. Стадии, вехи, выпуски
Структура процесса – Фазы ЖЦ
Inception
Elaboration
Construction
Transition
Rational Unified Process имеет 4 фазы:
Начальная фаза – Определение границ проекта
Фаза уточнения – Определение архитектуры
Фаза конструирования – Сборка продукта
Фаза ввода в действие – Передача продукта конечным пользователям
time
Inception
Elaboration
Construction
Transition
Границы фаз отмечены как важные вехи
Цели ЖЦ
Архитектура� ЖЦ
Первоначальные� возможности
Версия� продукта
время
Итерации и фазы
Итерация – этап создания ПО, направленный на достижение запланированных на данную итерацию целей. В течение итерации необходимо создать или доработать требования, проектные артефакты, получить версию программного продукта (для внешнего или внутреннего использования). Программный продукт наращивается от итерации к итерации, до тех пор пока не будет создан окончательный вариант системы.
Preliminary
Iteration
Architect.
Iteration
Architect.
Iteration
Devel.
Iteration
Devel.
Iteration
Devel.
Iteration
Transition
Iteration
Transition
Iteration
Inception
Elaboration
Construction
Transition
Вехи: Релизы
Каждая итерация включает в себя все аспекты разработки и все основные виды работ. При этом, в зависимости от фазы разработки, тому или иному виду работ уделяется различное внимание.
Первая версия ПО (внендренная и поддерживаемая, не прототип !) является результатом первого цикла прохождения процесса разработки через 4 фазы. Этот первый цикл называется� начальным циклом �(initial development cycle).
До тех пор, пока продукт сопровождается, производится его модернизация. Процесс модернизации может включать несколько циклов, сходных по структуре с начальным циклом разработки.
Эти циклы называются циклами эволюции (совершенствования) ПО (evolution cycles). Результатом каждого такого цикла является новая работоспособная и внедренная версия ПО.
Процесс разработки версий ПО
Начальная фаза разработки (Inception Phase)��Основная задача начальной фазы разработки - определение конечных целей проекта.
Для этого выявляются все активные субъекты (actors), с которыми система должна взаимодействовать, определяется суть их деятельности и основные функции.
С административной точки зрения, должны быть установлены критерии успешного завершения проекта, произведена оценка требуемых ресурсов для реализации проекта, а также определен календарный план (план проекта).
Начальная фаза завершается принятием принципиального решения о целесообразности проведения дальнейшей разработки.
Фаза уточнения (Elaboration) �Основными задачами фазы уточнения являются:�1. Подробный анализ предметной области;� 2. Определение не противоречащих друг другу базовых элементов архитектуры разрабатываемой системы;
3. Детализация плана проекта;��4. Выявление факторов риска, в наибольшей степени влияющих на успешное завершение проекта.
Для принятия на этой фазе архитектурных решений, необходимо понимание системы в целом. Это предполагает что проанализировано большинство функций субъектов предметной области и учтены ограничения предметной области, сформулированные в виде дополнительных требований.
Для подтверждения правильности архитектурных решений разрабатывается прототип системы, демонстрирующий эти решения в действии.
В завершении фазы уточнения подвергаются проверке детализированные характеристики системы, формируется окончательное описание архитектуры и решаются проблемы, связанные с основными рисками проекта.
Фаза конструирования�� В течение фазы конструирования итеративно и пошагово разрабатывается конечный программный продукт
При этом реализуются функции системы, завершается проектирование, кодирование и тестирование ПО.
О завершении фазы конструирования свидетельствует готовность программного обеспечения, организации – заказчика и пользователей к началу эксплуатации.
Фаза внедрения конечного продукта��Основная задача фазы внедрения – доведение ПО до уровня, при котором оно может реально эксплуатироваться пользователями.
При завершении фазы внедрения определяется, достигнуты или нет цели проекта и, возможно, принимается решение об осуществлении следующего цикла разработки. Здесь также уместно извлечь уроки из предыдущего опыта разработки в целях улучшения процесса в будущем.