Основные методологии разработки ПО
Коробейник А.Н. Краткие основы тестирования программного обеспечения. Киев, 2012
Каскадная Модель (Модель “водопада”).
В данной модели разработки ПО процесс разработки построен как очередность действий, причем следующее действие не может быть начато до тех пор, пока не закончится предыдущее.
Такой подход применялся в 70-х годах прошлого столетия и сейчас очень редко используется, так как является негибким и не применим в текущих условиях рынка программного обеспечения. Изначально эта методология унаследовалась от конвейерного производства деталей на фабриках и заводах, когда одна деталь многократно дублировалась на производственных линиях для дальнейшего распространения.
Каскадная Модель (Модель “водопада”).
Основные методологии разработки ПО
V-образная модель
V-образная модель, это каскадная модель разработки, результат усовершенствования предыдущей модели водопада. Поскольку тестирование стало важным этапом процесса разработки ПО, его необходимо было внедрить в общую схему процесса. Эта методология добавляет к процессу разработки фазы тестирования, которые проверяют соответствующие им этапы разработки.
V-образная модель
Основные методологии разработки ПО
V-образная модель
В этой модели тестировщики подключаются на этапе разработки. Если какой-то этап тестирования провален, то он возвращает процесс создания программы к соответствующему этапу планирования (например, провал тестирования всей системы в целом вернёт процесс к этапу концептуального дизайна системы согласно рисунку). Эта модель содержит все недостатки предыдущей за исключением того, что она уже включает в себя планы по тестированию продукта.
Две предыдущие модели – каскадные. Главный их
недостаток – изменения в одном шаге требуют заново начинать работу над всеми последующими, даже если они уже были закончены. В больших проектах это приводит к значительным затратам.
Основные методологии разработки ПО
Спиральная модель
Для того чтобы смягчить ущерб от возможных изменений на определенных этапах создания продукта, были изобретены
итерационные модели разработки.
Самая первую из них – спиральную модель. Спиральная модель разработки.
Эта модель разработки базируется на принципе прототипирования продукта. Тоесть, сначала выпускается первый прототип (версия 1) с основными затребованными функциями, проходя через стадии разработки требований, проектирования, реализации, тестирования и ввода в действие (демонстрационного показа). Дальше относительно увиденного результата корректируются требования, дополняются новыми и начинается проектирование версии 2. И так пока не будет достигнут желаемый результат. Каждая такая итерация на диаграмме отображается одним полным витком спирали.
Спиральная модель
Основные методологии разработки ПО
Спиральная модель
Тестировщики задействованы в этой модели ещё до начала стадии разработки. В то время, как дизайнеры и архитекторы готовят требования к продукту, тестировщики проверяют корректность этих требований на то что они выполнимы (мы можем выполнить то, что от нас требуют), понятны (мы понимаем, что от нас требуют), тестируемые (мы можем проверить что требование выполнено), не противоречивы (требования не противоречат друг другу), не двусмысленны (одно требование нельзя понять как-то двусмысленно), отслеживаемые (мы можем следить за реализацией требования), закончены (требования полностью описаны и не вызывают вопросов).
Основные методологии разработки ПО
RUP
Развитием спиральной модели разработки стал RUP (Rational Unified Process) – методология разработки ПО созданная компанией Rational Software.
Это итеративная модель разработки. В конце каждой итерации команда должна выполнить поставленные перед собой на эту итерацию цели. Если цели не достигнуты, то итерация либо начинается заново, с учетом и корректировкой предыдущих ошибок в планировании, либо продлевается на небольшой срок. Полный жизненный цикл разработки программы в методологии RUP состоит из 4-х фаз (Начальная стадия, уточнение, конструирование, внедрение), каждая фаза содержит одну или более итерацию. Планирование разработки проводится на весь период работы над продуктом, но после каждой итерации возможны корректировки требований к продукту и пересчет ресурсов необходимых на выполнение поставленных целей.
RUP