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