 |
Водопадная модель процесса разработки
|
|
|
|
Водопадная модель процесса разработки
К середине 80-х годов наибольшее распространение получил " водопадный" (waterflow) или " каскадный" процесс создания программного обеспечения. Схема " водопадного" процесса приведена на рис. 1. 1. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Рис 1. 1. " Водопадный" процесс
Применение " водопадного" процесса эффективно для систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако, в процессе использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания программных систем никогда полностью не укладывался в такую жесткую схему. В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания систем принимал следующий вид (рис. 1. 2):
Данный процесс обладает рядом существенных недостатков, основным из которых является, пожалуй, то, что требования к создаваемой системе " заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания системы, пользователи получают систему, не удовлетворяющую их потребностям.
|
|
|
Рис 1. 2. Реальный процесс " водопадной" схемы
Спиральная модель процесса разработки
В реальной жизни оказывается, что на стадии формулировки требований заказчик не может точно определить все требования к программному продукту. Для преодоления данной проблемы во второй половине 80-х годов был предложен " спиральный" процесс создания программ (рис. 1. 3), делающий упор на этапы анализа и проектирования. Разработка системы по данной методологии происходит итерациями, и после прохождения каждого витка спирали пользователь получает очередную версию системы. После получения заказчиком каждой версии
уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали.
Рис 1. 3. Спиральная модель Итерации по спирали
Спиральная модель разработки ПО, в тех или иных версиях используемая во множестве конкретных прикладных методик, построена на следующем шаблоне. Прежде всего в ходе общения с заказчиком определяется набор наиболее важных и критичных возможностей будущей системы. Далее совместными усилиями определяются желаемые сроки для реализации этой базовой функциональности. Формируется план, начинаются работы, и отслеживается их выполнение.
В основу спиральной модели заложены две посылки. Многочисленными исследованиями подтверждено, что и заказчик и исполнитель обычно слишком оптимистично относятся к срокам и бюджету, даже при использовании хороших методик оценки объема работ (по функциональным точкам и т. п. ). Поэтому результаты таких оценок предлагается увеличивать (ухудшать) достаточно серьезно - примерно на 50%. Кроме того, заказчик обычно слабо представляет архитектуру будущей системы, поэтому ее следует проектировать, закладываясь на открытые технологии и максимально гибкие возможности расширения и наращивания функциональности. Уточнение конкретных требований выполняется итерационно, при этом на каждом витке проектной спирали создается все более точная версия, соответствующая пожеланиям заказчика.
|
|
|
Шесть шагов спиральной модели
1. В процессе общения с заказчиком формируется общее видение проекта, а также
описываются функциональные возможности, которые необходимо реализовать в определенные
сроки с нужным качеством.
2. Расставляются приоритеты, задающие порядок реализации основных функциональных
возможностей.
3. Согласовываются временные рамки проекта. Часто для этого применяются методики
стоимостного прогнозирования. Далее исполнитель решает, сколько функциональных
возможностей в соответствии с их приоритетами удастся реализовать в оговоренный срок.
4. На данном этапе определяются архитектура и ядро будущей системы. Это наиболее
ответственный момент, так как здесь необходимо учесть пока еще не детализированные
полностью требования к проекту - а они вполне могут быть противоречивыми.
Ядро должно представлять собой законченный работающий вариант системы с небольшим набором необходимых возможностей. Не исключено, что заказчик видит архитектуру как жесткую конструкцию и не предусматривает средств ее расширения для обеспечения дополнительной или менее приоритетной функциональности. Поэтому далее определяется способ реализации требований с более низкими приоритетами - это можно делать, например, с помощью встроенного языка сценариев или подключением динамических библиотек, для чего необходимо определить внутренние интерфейсы ядра.
Этот шаг выполняется, как правило, в два и большее число итерационных циклов.
5. Готовится план работ. Он ориентирован на сроки, определенные на третьем этапе, и
нацелен на скорейшую реализацию ядра системы. Взаимодействуя с работающим прототипом,
заказчик быстрее и точнее вырабатывает и уточняет дальнейшие требования и корректирует
приоритеты.
|
|
|
6. Разработка системы в соответствии с планом.
Для этого этапа характерны три типичных класса проблем:
- изменения в требованиях к проекту;
- изменения параметров самого проекта (сроков, бюджета, качества);
- временные задержки, связанные с текущими вопросами (техникой, персоналом).
В ходе их решения приходится избавляться от задач с меньшими приоритетами и, возможно, изменять критический путь проекта. Все изменения вносятся с учетом основного критерия -сохранения сроков проекта.
Данный подход, конечно, не гарантирует соблюдения сроков - они могут быть сорваны, например, в случае резкого сокращения бюджета или серьезного изменения требований.
|
|
|
