1.10 Модели разработки ПО

Модель разработки ПО (Software Development Model, SDM) — структура, систематизирующая различные виды проектной деятельности, их взаимодействие и последовательность в процессе разработки ПО. [Куликов]

В курсе мы рассмотрим следующие модели разработки:

Водопадная / Каскадная (Waterfall)

Водопадная модель (waterfall model) сейчас представляет скорее исторический интерес, т.к. в современных проектах практически неприменима, исключая авиастроение, военную или космическую отрасли, медицину и финансовый сектор. Она предполагает однократное выполнение каждой из фаз проекта, которые, в свою очередь, строго следуют друг за другом. Очень упрощенно можно сказать, что в рамках этой модели в любой момент времени команде «видна» лишь предыдущая и следующая фаза. В реальной же разработке ПО приходится «видеть весь проект целиком» и возвращаться к предыдущим фазам, чтобы исправить недоработки или что-то уточнить.

Т.е. вернуться на предыдущую фазу в случае ошибки нельзя, все нужно начинать сначала (уточнение автора курса).

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

Плюсы каскадной модели:

Документирование каждого этапа.
Всегда будут доступны четкие требования.
Можно четко спланировать сроки и затраты.
Для заказчика все процессы будут достаточно прозрачны.

Минусы каскадной модели:

До начала проекта нужно утвердить полный набор требований к системе.
В случае изменений требований в процессе разработки нельзя вернуться к первой стадии т.к. нужно полностью переделывать систему.
Увеличение затрат и времени в случае необходимости изменения требований.

V-образная модель (V-model)

V-образная модель (V-model) является логическим развитием водопадной. Можно заметить (рисунок 2.1.b), что в общем случае как водопадная, так и v-образная модели жизненного цикла ПО могут содержать один и тот же набор стадий, но принципиальное отличие заключается в том, как эта информация используется в процессе реализации проекта. Очень упрощенно можно сказать, что при использовании v-образной модели на каждой стадии «на спуске» нужно думать о том, что и как будет происходить на соответствующей стадии «на подъёме». Тестирование здесь появляется уже на самых ранних стадиях развития проекта, что позволяет минимизировать риски, а также обнаружить и устранить множество потенциальных проблем до того, как они станут проблемами реальными.

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

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

Плюсы:

Строгие этапы.
Тестирование и верификация проходит на ранних этапах.
Есть промежуточное тестирование.

Минусы:

Негибкость модели разработки.
Написание кода только в середине разработки.
Нет возможности динамического внесения изменений.

Используется в проектах, в которых существуют временные и финансовые ограничения и для задач, которые подразумевают более широкое тестовое покрытие.

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

Итерационная инкрементальная модель (iterative model, incremental model) является фундаментальной основой современного подхода к разработке ПО. Как следует из названия модели, ей свойственна определённая двойственность:

с точки зрения жизненного цикла модель является итерационной, т.к. подразумевает многократное повторение одних и тех же стадий;
с точки зрения развития продукта (приращения его полезных функций) модель является инкрементальной.

Ключевой особенностью данной модели является разбиение проекта на относительно небольшие промежутки (итерации), каждый из которых в общем случае может включать в себя все классические стадии, присущие водопадной и v-образной моделям (рисунок 2.1.c). Итогом итерации является приращение (инкремент) функциональности продукта, выраженное в промежуточном билде (build).

Длина итераций может меняться в зависимости от множества факторов, однако сам принцип многократного повторения позволяет гарантировать, что и тестирование, и демонстрация продукта конечному заказчику (с получением обратной связи) будет активно применяться с самого начала и на протяжении всего времени разработки проекта.

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

Каждый этап итерации соответствует модели PDCA (Plan --> Do --> Check --> Act).
1. Plan - это этап Планирования (Plan) и Сбора требований (Requirements).
2. Do - это этапы Анализа и Дизайна (Analysis & Desing) и Написания кода (Implementation).
3. Check - это этап Тестирования (Testing).
4. Act - фаза ревью - оценка текущий требований и предложений к ним.

Плюсы:

Раннее создание работающего ПО.
Такие системы очень гибкие, требования можно изменить на любом этапе разработки.
Для каждой итерации проще провести тестирование и анализ рисков.

Минусы:

Каждая фаза самостоятельна.
Не всегда все требования известны к началу проектирования.

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

Спиральная модель (spiral model)

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

Обратите внимание на то, что здесь явно выделены четыре ключевые фазы:

проработка целей, альтернатив и ограничений;
анализ рисков и прототипирование;
разработка (промежуточной версии) продукта;
планирование следующего цикла.

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

Гибкая модель (agile model), в частности Scrum

Гибкая модель представляет собой совокупность различных подходов к разработке ПО и базируется на т.н. «agile-манифесте».

Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.

Стоит понимать, что левая часть утверждения не отменяет наличие правой. Речь лишь про то, что является более приоритетным для данной модели. (примечание автора курса)

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

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