Змеев О.А. Три кита унифицированного процесса разработки

«Введение в Унифицированный
процесс разработки ПО».
Лекция № 3.
Есть три кита и больше ни черта …
Строки из песенки к фильму «Трест, который
лопнул …»
Унифицированный процесс.
Итеративный и инкрементный подход:
Начало
Проектирование
Определение
требований
Анализ
Проектирование
Реализация
Тестирование
Ит
№1
Ит
№2
-
Реализация
Внедрение
Системный
аналитик
Найти актеров и
варианты
использования
Планировать
тестирование
Структурировать
модель ВИ
Разработать
тест
Оценить результаты
тестирования
Инженер по
тестированию
Определение
требований
Спецификатор ВИ
Тестирование
Детализировать
варианты
использования
Интегрировать
систему
Системный
интегратор
Реализация
Разработать
интерфейс
пользователя
Разработчик GUI
Провести
тестирование
целостности
Тестер
целостности
Проектирование
Архитектор
Раставить ВИ по
приоритетам
Анализировать
архитектуру
Проектировать
архитектуру
Провести
системные
тесты
Реализовать
архитектуру
Системный
тестор
Анализ
Аналитик ВИ
Разработчик ПО
Анализировать
вариант
использования
Анализировать
класс
Анализировать
пакет
Проектировать
вариант
использования
Проектировать
класс
Реализовать
класс
Проектировать
подсистему
Реализовать
подсистему
Реализовать
тест
Провести
тестирование
модулей
UML и UP – близнецы-братья.
Разработка артефактов  разработке моделей:
Определение требований
Модель вариантов
использования
Анализ
Модель
анализа
Проектирование
Модель
проектирования
Модель
развертывания
Реализация
Модель
реализации
О
к
Тестирование
О
к
О
О к
О
к
к
Модель
тестирования
Первый кит.
Процесс, управляемый вариантами использования:
Вспомним все, ну или почти все…:
Вариант использования (прецедент) (use case) - это описание
последовательности выполняемых системой действий, которая
производит наблюдаемый результат, значимый для какого-то
определенного актера (actor).
МуUseCase
MyActor
Первый кит.
Процесс, управляемый вариантами использования:
Означает следующее – команда разработчиков
использует варианты использования на протяжении
всего процесса от начального сбора информации до
написания кода, и даже более, до процесса
тестирования и написания заключительной
проектной документации.
Варианты использования являются очень удобным
инструментом для уточнения функциональных
требований, анализа, проектирования реализации и
тестирования программной системы.
Первый кит.
Процесс, управляемый вариантами использования:
Причины:
 Варианты использования пишутся с точки зрения конечных
пользователей системы.
 Вариант использования пишется на родном языке
пользователя.
 Варианты использования предоставляют гораздо больше
возможностей для понимания действительных функциональных
требований к системе, чем стандартные спецификации.
 Варианты использования обеспечивают высокий уровень
оперативного контроля преобразования требований в процессе
разработки.
 Варианты использования позволяют преобразовывать
функциональные требования в задачи, которые можно
распределять между командами или отдельными
исполнителями, упрощая, таким образом, организацию
выполнения проекта.
История процессов разработки ПО.
Модель «водопада» - предполагалось следующее:
Модель вариантов
использования
Проверяются на полноту и непротиворечивость.
Приводят к определению основных сущностей и
первичному распределению обязанностей.
Модель
полученные
на
анализа
Сущности
этапе анализа
уточняются и становятся
элементами модели
проектирования.
Выполняет анализ
Модель
правильности полученных
развертывания
результатов с т.з. ЗС
Ок
Ок
Ок
Ок
Модель
проектирования
Ок
Рассматривает вопросы,
Модель
связанные с
тестирования
развертыванием в рамках
вычислительной среды.
Реализуется в виде кода. По сути
Модель
выполняется операция прямого
реализации
проектирования.
Проверяются на полноту и непротиворечивость.
Приводят к определению основных сущностей и
первичному распределению обязанностей
История процессов разработки ПО.
Спиральная (эволюционная модель):
1988 год Барри Боем (Barry Boehm). Основная идея:
проект в ходе своей разработке состоит из
независимых частей, которые определяются и
объединяются с помощью анализа рисков проекта.
 Сначала серии прототипов, основанных на рисках;
 В конце структурированный процесс построения
конечной системы.
 Недостатки:
 Метод проб и ошибок;
 Процесс создания постоянно переделываемого
кода;
 Интересно, когда все это закончится?
История процессов разработки ПО.
Некоторые итоги:


Независимо от процесса основные виды
работ в рамках процесса остаются
неизменными..
Недостатки каждого из рассмотренных
подходов, являются достоинствами его
альтернативы.
Чтобы выжить, надо уметь
приспосабливаться к меняющимся ситуациям.
Тираннозавр