2) Модели разработки - Часть 1

Модели процесса разработки

Scrum-модель

Является еще одним примером адаптивного процесса разработки (ранее мы рассматривали xp-разработку)
Основные идеи модели сформулировали Хиротака Такеути и Икудзиро Нонака в 1986 году

Основная идея Scrum-модели

Экспериментальный факт: проекты, над которыми работают небольшие, кросс-функциональные команды, обычно систематически производят лучшие результаты

Такеуки и Ноната объяснили это как «подход регби» и ввели и сам термин

«scrum» - «толкотня; схватка вокруг мяча (в регби)»

Впервые метод Scrum был представлен в документированном виде в 1996 году совместно Сазерлендом и Швабером

Роли

Главные действующие роли:

1. ScrumMaster, тот кто занимается процессами и работает в качестве руководителя проекта,
2. Владелец Продукта, человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон,
3. Команда, которая включает разработчиков

Этапы разработки

Процесс разработки разбивается на отдельные этапы определенной длительности – спринты (обычно,15-30 дней)
Каждому спринту предшествует этап, который называется product backlog –документирование запросов на выполнение работ

Планирование спринта

Запросы на выполнение работ определяются на этапе совета по планированию спринта – sprint planning meeting

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

Выполнение спринта

Во время спринта команда выполняет определенный фиксированный список заданий - backlog items, наращивая функциональность программного продукта

На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать, как заморозку требований (requirements) во время спринта

Scrum схема =

RUP-процесс разработки По

Одна из лучших методологий разработки программного обеспечения, «де-факто» получившая статус классической

"Реклама" RUP-процесса

Рациональный унифицированный процесс (Rational Unified Process, RUP ) разработки программных средств вобрал в себя все лучшее, что есть на сегодняшний день в области организации разработки ПО

Создана корпорацией Rational Software и выпущена на рынок в виде структурированной базы знаний под соответствующим названием

RUP-процесс разработки ПС (без рекламы - без перерыва =)))

RUP является развитием спиральной модели и представляет процесс разработки ПО в виде эволюционно-инкрементного цикла

• Эволюционная составляющая цикла основывается на дополнении требований в ходе работы
• Инкрементная составляющая – на планомерном приращении реализации требований

Концепция RUP

Концептуальные основы этого подхода формировались авторами UML А. Джекобсоном и Г. Бучем при участии У.Ройса (Walker Royce, сына автора "классической" каскадной модели) и Ф.Крухтена (Philippe Kruchten)

RUP основан на трех ключевых идеях

1-я идея

Весь ход работ направляется итоговыми целями проекта, выраженными в виде вариантов использования (use cases)
Разработка начинается с выделения вариантов использования и на каждом шаге контролируется степенью приближения к их реализации

2-я идея

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

Архитектура устанавливает:

1. набор компонентов, из которых будет построено ПО,
2. ответственность каждого из компонентов (т.е. решаемые им подзадачи в рамках общих задач системы),
3. четко определяет интерфейсы, через которые могут взаимодействовать компоненты

2-я идея

Архитектура является одновременно =

• основой для получения качественного ПО
• и базой для планирования работ и оценок проекта

Она оформляется в виде набора графических моделей на языке UML

3-я идея

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

Этапы и итерации

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

RUP выделяет в процессе разработки 4 этапа:

1. начало (Inception)
2. развитие (Elaboration)
3. конструирование (Construction)
4. внедрение (Transition)

Этапы и итерации

В рамках каждого из этапов возможно проведение нескольких итераций

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

Этапы, итерации и циклы

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

Рабочие потоки

Каждая итерация включает несколько рабочих потоков:

1. моделирование предметной области (Business Modeling);
2. определение требований (Requirements);
3. анализ и проектирование (Analysis and Design);
4. реализация (Implementation);
5. тестирование (Test);
6. развертывание (Deployment);
7. управление конфигурациями и изменениями (Configuration and Change Management);
8. управление проектом (Project Management);
9. управление средой проекта (Environment)

Первые пять рабочих потоков считаются основными, остальные - поддерживающими (подробнее об этих потоках читайте далее)

Структура типовой итерации (изображение схемы)=

Моделирование предметной области

Задачи этой деятельности:

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

Моделирование предметной области

В результате моделирования предметной области должна появиться ее модель в виде набора диаграмм классов (объектов предметной области) и деятельностей (представляющих бизнес-операции и бизнес-процессы)

Модель предметной области служит основой модели проектирования

Определение требований

Задачи этого рабочего потока:

1. понять, что должна делать система, и убедиться во взаимопонимании по этому поводу между заинтересованными лицами;
2. определить границы системы;
3. создать основу для планирования проекта и оценок затрат ресурсов в нем.

Требования принято фиксировать в виде модели вариантов использования

Анализ и проектирование

Задачи этого рабочего потока:

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

В результате проектирования должна появиться модель проектирования, включающая:

1. диаграммы классов системы,
2. диаграммы ее компонентов,
3. диаграммы взаимодействий между объектами в ходе реализации вариантов использования,
4. диаграммы состояний для отдельных объектов,
5. диаграммы развертывания

Реализация

Задачи рабочего потока Реализация:

1. определить структуру исходного кода системы,
2. разработать код ее компонентов
3. протестировать компоненты,
4. интегрировать систему в работающее целое

Тестирование

Задачи рабочего потока Тестирование:

1. поиск и описание дефектов системы (проявления недостатков ее качества),
2. оценка ее качества в целом,
3. оценка степени выполнения гипотез, лежащих в основе проектирования,
4. оценка степени соответствия системы требованиям

Развертывание (Deployment)

Задачи рабочего потока Развертывание:

1. установка системы в ее рабочем окружении,
2. оценка ее работоспособность на том месте, где она должна будет работать

Управление конфигурациями и изменениями

Задачи данного этапа:

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

Управление проектом

Задачи потока Управление проектом :

1. планирование,
2. управление персоналом,
3. обеспечение взаимодействия на благо проекта между всеми заинтересованными лицами,
4. управление рисками,
5. отслеживание текущего состояния проекта

Управление средой проекта

Задачи потока—

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

[2-ая часть лекции ЗДЕСЬ]