Модели разработки программного обеспечения
Существует несколько видов разработки программного обеспечения, которые основываются на разных моделях. Перечислим 5 самых распространенных из них.
Waterfall (каскадная модель, или «водопад»)
Преимущества:
- Простота контроля. Заказчик будет всегда понимать, что в данный момент делают исполнители, сможет регулировать сроки и бюджет.
- Возможность расчёта стоимости проекта ещё на начальной стадии. Каждый нюанс прописывается во время стадии согласования договора.
- Отсутствие необходимости привлечения очень опытных тестировщиков. Специалисты смогут базироваться на подробной технической документации.
- Тестирование осуществляется лишь на заключительных стадиях создания ПО. Исходя из этого, если при разработке были допущены ошибки, то на их устранение может уйти много времени и средств. Дело в том, что неполадки будут выявлены уже после написания кода и документации.
- Заказчик может рассмотреть продукт только на заключительных этапах его создания. Таким образом, обратная связь реализуется лишь под конец разработки. Вполне вероятно, что заказчик останется недовольным.
- Модель предполагает написание большого количества технической документации. Это снижает скорость выполнения работ, ведь разработчикам приходится выносить и согласовывать множество решений.
Waterfall предназначена для создания проектов в медицинской и космической сферах. В данных областях уже имеется крупная база данных (включая СНиПы и спецификации). Благодаря этим документам можно гораздо быстрее формировать требования к будущему продукту.
Важнейшая цель в процессе работы с «водопадом» заключается в скрупулезном описании требований к разработке. Необходимо избежать ситуации, при которой на стадии тестирования будет выявлена серьезная ошибка.
V-образная модель (разработка через тестирование)
Данную модель можно назвать улучшенной версией «водопада». Заказчик совместно с командой разработчиков формирует требования к системе и описывает, каким образом будет выполняться ее тестирование на каждой стадии. V-образную модель начали использовать в 1980-х.
Преимущества:
- Минимальное количество ошибок в архитектуре программного обеспечения.
- Как и при использовании каскадной модели, если во время создания архитектуры были допущены ошибки, то будет довольно сложно их устранить.
Разработка через тестирование является оптимальным вариантом для проектов, в которых нужна повышенная надежность. Скажем, при создании подушек безопасности для автомобилей или систем наблюдения за пациентами в медицинских учреждениях.
Incremental Model (инкрементная модель)
Английское слово increment можно перевести как «приращение». Данную модель начали использовать ещё в 1930-х. В качестве примера возьмём разработку социальной сети.
Заказчику необходимо создать соцсеть. Он сформировал подробное техзадание. Разработчики предложили сначала создать основные функции в виде страницы с личной информацией и чата. После этого будет проводиться тестирование на реальных пользователях.
Заказчик оценивает продукт и принимает решение о его выпуске. В том случае, если заказчик и пользователи довольны результатом, то дальнейшая работа осуществляется по частям.
Разработчики одновременно организовывают функциональность для загрузки фотографий, обмена документами, прослушивания музыки и прочих операций, которые предварительно согласовываются с заказчиком. Шаг за шагом продукт становится все более совершенным, становясь все более похожим на сформированный эталон.
- Отсутствие необходимости больших материальных вложений на начальной стадии. Заказчику нужно лишь оплатить разработку базового функционала. После этого он получает продукт и может его выпустить. Решение о продолжении разработки будет приниматься на основе обратной связи с реальными клиентами.
- Возможность своевременного получения обратной связи для быстрого обновления техзадания. Благодаря такому подходу вероятность получить невостребованный продукт сводится к минимуму.
- Меньшая цена ошибки. При выявлении каких-либо проблем в архитектуре, их можно исправить за меньшую стоимость в сравнении с двумя предыдущими моделями.
- Каждая из команд разработчиков занимается созданием отдельных функций. Это может привести к несогласованной реализации интерфейса ПП. Во избежание такой ситуации следует ещё на стадии обсуждения технического задания точно определить конечный результат.
- Программисты могут замедлять процесс создания продукта, откладывая настройку основных функций и излишне заостряясь на мелких деталях. Таким образом, необходимо сосредоточиться на управлении разработкой программного обеспечения. По этой причине менеджеру проекта необходимо осуществлять строгий контроль над действиями каждой команды.
Iterative Model (итеративная модель)
Данная технология разработки программного обеспечения подразумевает, что заказчик может не разбираться в том, какой именно продукт ему нужен. Иными словами, от него не требуется скрупулезно прописывать техническое задание.
Преимущества:
- Возможность оперативно получить обратную связь за счет выпуска минимального продукта. Таким образом, разработчики могут сосредоточиться на фундаментальных функциях программного обеспечения и совершенствовать их, опираясь на стандарты рынка и отзывы пользователей.
Благодаря непрекращающемуся тестированию самими пользователями, программисты могут своевременно выявлять и нивелировать различные ошибки.
Недостатки:
- Применение на старте баз данных или серверов. Проблема заключается в том, что базы данных довольно сложно масштабировать, а серверы зачастую не выдерживают нагрузку. Из-за этого может сложиться ситуация, при которой нужно будет переделывать весомую часть продукта.
- Отсутствие фиксированного бюджета и сроков. Заказчик не имеет четкого представления о том, каким должен быть итоговый результат и в какое время необходимо завершить создание продукта.
Данная модель будет предпочтительна в том случае, если предполагается работа над крупномасштабным проектом с нечеткими требованиями. Кроме того, итеративный вариант подойдёт для задач с инновационным подходом, когда заказчик не может знать, что получится в конечном итоге.
Spiral Model (спиральная модель)
При применении спиральной модели заказчик и исполнители производят тщательный анализ рисков проекта и реализуют его итерациями. Каждая следующая стадия базируется на предыдущей. При этом в конце каждого цикла итераций необходимо принять решение относительно того, будет ли осуществляться разработка дальше.
Модель начали применять ещё в 1988 году. Она схожа с инкрементным вариантом, однако здесь упор делается именно на оценку всевозможных рисков. Каждый новый цикл спирали все больше усложняет процесс.
Преимущества:
- Сосредоточение внимания на анализе рисков.
Недостатки:
- Вероятность того, что разработка слишком зациклится на самой начальной стадии.
- Повышенная стоимость и длительность разработки.
