Модели разработки ПО (лекция № 11)

1.

Лекция №11
Модели разработки ПО

2.

Виды моделей
Модель разработки ПО (Software Development Model, SDM) — структура,
систематизирующая различные виды проектной деятельности, их взаимодействие и последовательность в процессе разработки ПО. Выбор той или иной
модели зависит от масштаба и сложности проекта, предметной области,
доступных ресурсов и множества других факторов.
Моделей разработки ПО много, но, в общем случае, классическими можно
считать каскадную, v-образную, итерационную, инкрементальную, спиральную
и гибкую.

3.

Водопадная модель (waterfall model)
Общее планирование
Пользовательские требования
Системные требования
Техническая архитектура
Детализированный дизайн
Разработка и отладка
Интеграция и модульные тесты
Инсталляционное тестирование
Тестирование в явном виде
появляется лишь с середины
развития проекта, достигая
своего максимума в самом конце.
Системное тестирование
Приёмочное тестирование
Итоговая отчетность
https://vimeo.com/18951935?embedded=true&source=vimeo_logo&owner=5781173

4.

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

5.

Таблица
Модель
Водопадная
+
У каждой стадии
есть чёткий
проверяемый
результат.
В каждый момент
времени команда
выполняет один вид
работы.
Хорошо работает
для небольших
задач.
-
-
Полная
неспособность
адаптировать
проект к
изменениям в
требованиях.
Крайне позднее
создание
работающего
продукта.
Тестирование
С середины
проекта.

6.

V-образная модель (V-model)
Общее
планирование
Итоговая
отчетность
Тестирование
появляется с
самого начала
проекта
Пользовательские
требования
Системные
требования
Приёмочное
тестирование
Системное
тестирование
Инсталляционное
тестирование
Детализированный
дизайн
Техническая
архитектура
Интеграция и
модульные тесты
Разработка и отладка

7.

Когда использовать?
Если требуется тщательное тестирование продукта,
то V-модель оправдает заложенную в себя идею:
validation and verification.
Для малых и средних проектов, где требования четко
определены и фиксированы.
В условиях доступности инженеров необходимой
квалификации, особенно тестировщиков.

8.

Таблица
Модель
V-образная
+
У каждой стадии
есть чёткий
проверяемый
результат.
Внимание
тестированию
уделяется с первой
же стадии.
Хорошо работает
для проектов со
стабильными
требованиями.
-
-
-
Тестирование
Недостаточная На переходах
гибкость и
между стадиями.
адаптируемость
Отсутствует
раннее
прототипирован
ие.
Сложность
устранения
проблем,
пропущенных
на ранних
стадиях
развития
проекта.

9.

Итерационная инкрементальная модель (iterative model, incremental model)
Общее
планирование
Архитектура и
дизайн
Разработка и отладка
Интеграция и
модульные тесты
Планирование
+ требования
Установка билда
Отчётность
Итоговая
отчетность
Оценка
результатов
Тестирование

10.

Итерационная инкрементальная модель (iterative model, incremental model)

11.

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

12.

Таблица
Модель
Итерационная
инкрементальная
+
Достаточно раннее
прототипирование.
Простота
управления
итерациями.
Декомпозиция
проекта на
управляемые
итерации.
-
-
Недостаточная
гибкость внутри
итераций.
Сложность
устранения
проблем,
пропущенных
на ранних
стадиях
развития
проекта.
Тестирование
В определённые
моменты итераций.
Повторное
тестирование (после
доработки) уже
проверенного ранее.

13.

Проработка целей,
альтернатив и
ограничений
Эксплуатации
продукта
Процесса
разработки
проекта
Жизненного
цикла
проекта
Продуктных
Нарастание общей ценности продукта
Спиральная модель (spiral model)
Анализ рисков и
прототипирование
Оценка промежуточных результатов
Проекта и
продукта
Жизненного
цикла
Общей
концепции
Уточненных
требований
Архитектуры
Дизайна
Детализация
Детализация
Кодирование
Кодирование
Разработки,
интеграции и
тестирования
Планирование
следующего цикла
Внедрения и
сопровождения
Интеграция
Интеграция
Тестирование
Тестирование
Разработка
(промежуточной
версии) продукта

14.

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

15.

Таблица
Модель
Спиральная
+
Глубокий анализ
рисков.
Подходит для
крупных проектов.
Достаточно раннее
прототипирование.
-
-
-
Высокие
накладные
расходы.
Сложность
применения для
небольших
проектов.
Высокая
зависимость
успеха от
качества
анализа рисков.
Тестирование
В определённые
моменты итераций.
Повторное
тестирование (после
доработки) уже
проверенного ранее.

16.

Гибкая модель(Agile model)

17.

Гибкая модель(Agile model)
1.Наивысшим приоритетом для нас является удовлетворение
потребностей заказчика благодаря регулярной и ранней
поставке ценного программного обеспечения.
2.Изменение требований приветствуется даже на поздних
стадиях разработки. Agile-процессы позволяют использовать
изменения для обеспечения заказчику конкурентного
преимущества.
3.Работающий продукт следует выпускать как можно чаще, с
периодичностью от пары недель до пары месяцев.

18.

Гибкая модель(Agile model)
4. На протяжении всего проекта разработчики и
представители бизнеса должны ежедневно работать
вместе.
5.Над проектом должны работать мотивированные
профессионалы. Чтобы работа была сделана, создайте
условия, обеспечьте поддержку и полностью доверьтесь им.
6.Непосредственное общение является наиболее практичным
и эффективным способом обмена информацией как с самой
командой, так и внутри команды.

19.

Гибкая модель(Agile model)
7. Работающий продукт — основной показатель прогресса.
8.Инвесторы, разработчики и пользователи должны иметь
возможность поддерживать постоянный ритм бесконечно.
Agile помогает наладить такой устойчивый процесс
разработки.
9.Постоянное внимание к техническому совершенству и
качеству проектирования повышает гибкость проекта.

20.

Гибкая модель(Agile model)
10.Простота — искусство минимизации лишней работы —
крайне необходима.
11. Самые лучшие требования, архитектурные и технические
решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать
возможные способы улучшения эффективности и
соответственно корректировать стиль своей работы.

21.

Гибкая модель(Agile model)
Ценности
Адаптивность
Бюджет
Прозрачность
Соглашения
Простота
Оценка
Цели
Единство
Планирование
План выпуска
СТРАТЕГИЯ
Ретроспектива
Оценка
ВЫПУСК
Видение
ИТЕРАЦИЯ
Бэклог
"Стендап"
собрание
Тестирование
ЕЖЕДНЕВНО
Наглядность
НЕПРЕРЫВНО
Осталось сделать
Билд
Производительность
TDD
Билд
Рефакторинг
Интеграция
Сделано
Сотрудничество
тесты

22.

Гибкая модель
SCRUM

23.

Гибкая модель

24.

Когда использовать?
Когда потребности пользователей постоянно
меняются в динамическом бизнесе.
Изменения на Agile реализуются за меньшую
цену из-за частых инкрементов.
В отличие от модели водопада, в гибкой модели
для старта проекта достаточно лишь небольшого
планирования.

25.

Таблица
Модель
Гибкая
+
Максимальное
вовлечение
заказчика.
Много работы с
требованиями.
Тесная интеграция
тестирования и
разработки.
Минимизация
документации.
-
-
Сложность
реализации для
больших
проектов.
Сложность
построения
стабильных
процессов
Тестирование
В определённые
моменты итераций и
в любой
необходимый
момент.

26.

Таблица

27.

Жизненный цикл тестирования

28.

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

29.

Жизненный цикл тестирования
Стадия 2 (уточнение критериев приёмки) позволяет
сформулировать или уточнить метрики и признаки возможности или
необходимости начала тестирования (entry criteria), приостановки
(suspension criteria) и возобновления (resumption criteria)
тестирования, завершения или прекращения тестирования (exit
criteria).
Стадия 3 (уточнение стратегии тестирования) представляет собой
ещё одно обращение к планированию, но уже на локальном уровне:
рассматриваются и уточняются те части стратегии тестирования
(test strategy), которые актуальны для текущей итерации.

30.

Жизненный цикл тестирования
Стадия 4 (разработка тест-кейсов) посвящена разработке,
пересмотру, уточнению, доработке, переработке и прочим
действиям с тест-кейсами, наборами тест-кейсов, тестовыми
сценариями и иными артефактами, которые будут использоваться
при непосредственном выполнении тестирования.
Стадия 5 (выполнение тест-кейсов) и стадия 6 (фиксация
найденных дефектов) тесно связаны между собой и
фактически выполняются параллельно: дефекты
фиксируются сразу по факту их обнаружения в процессе
выполнения тест-кейсов.

31.

Жизненный цикл тестирования
Стадия 7 (анализ результатов тестирования) и стадия 8
(отчётность) также тесно связаны между собой и выполняются
практически параллельно. Формулируемые на стадии анализа
результатов выводы напрямую зависят от плана тестирования,
критериев приёмки и уточнённой стратегии, полученных на стадиях
1, 2 и 3. Полученные выводы оформляются на стадии 8 и служат
основной для стадий 1, 2 и 3 следующей итерации тестирования.
Таким образом, цикл замыкается.