Итерационная модель жизненного цикла
Итак, опыт показал, что программные проекты в корне отличаются от строительных проектов и, следовательно, управлять ими тоже нужно по-другому. Наглядным подтверждением этого является тот факт, что к концу 1980-х гг. Министерство обороны США начало испытывать серьезные трудности с разработкой ПО в соответствии с жесткой, основанной на директивных документах и предусматривающей один проход модели, как это требовалось стандартом DoD-Std-2167A. Проведенная позже в 1999 г. проверка по выборке ранее утвержденных в Министерстве обороны проектов дала удручающие результаты. Из общего числа входящих в выборку проектов, на реализацию которых было выделено 37 млрд. долл., 75% проектов закончились неудачей или выделенные на них средства не были использованы, и только 2% выделенных средств были использованы без значительной модификации проектов. В результате в конце 1987 г. министерство отступило от стандартов на базе каскадной модели и допустило применение итерационного подхода.
Истоки концепции итерационной разработки прослеживаются в относящихся к 1930-м годам работах эксперта по проблемам качества продукции Уолтера Шеварта из компании Bell Labs, который предложил ориентированную на повышение качества методику, состоящую из серии коротких циклов шагов по планированию, реализации, изучению и действию (plan-do-study-act, PDSA). С 1940-х годов энергичным поборником PDSA стал известный авторитет в области качества Эдвардс Деминг. В более поздних работах PDSA была исследована применительно к разработке ПО.
В середине 1980-х годов Барри Боэм предложил свой вариант итерационной модели под названием «спиральная модель»(spiral model) (рис. 1.6).
Принципиальные особенности спиральной модели:
· отказ от фиксации требований и назначение приоритетов пользовательским требованиям;
· разработка последовательности прототипов, начиная с требований наивысшего приоритета;
· идентификация и анализ риска на каждой итерации;
· использование каскадной модели для реализации окончательного прототипа;
· оценка результатов по завершении каждой итерации и планирование следующей итерации.
При использовании спиральной модели прикладное ПО создается в несколько итераций (витков спирали) методом прототипирования. Под прототипомпонимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО. Создание прототипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта, чтобы определить необходимость выполнения еще одной итерации, степень полноты и точности понимания требований к системе, а также целесообразность прекращения проекта.
Рис. 1.6. Спиральная модель жизненного цикла ПО
Спиральная модель избавляет пользователей и разработчиков ПО от необходимости полного и точного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждой стадии позволяет переходить на следующую стадию, не дожидаясь полного завершения работы на текущей. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Достоинствами спиральной модели являются:
· ускорение разработки (раннее получение результата за счет прототипирования);
· постоянное участие заказчика в процессе разработки;
· разбиение большого объема работы на небольшие части;
· снижение риска (повышение вероятности предсказуемого поведения системы).
Спиральная модель не исключает использования каскадного подхода на завершающих стадиях проекта в тех случаях, когда требования к системе оказываются полностью определенными.
К недостаткам спиральной модели можно отнести:
· сложность планирования (определения количества и длительности итераций, оценки затрат и рисков);
· сложность применения модели с точки зрения менеджеров и заказчиков (из-за привычки к строгому и детальному планированию);
· напряженный режим работы для разработчиков (при краткосрочных итерациях).
Основная проблема спирального цикла — определение момента перехода на следующую стадию. Для ее решения необходимо ввести временные ограничения на каждую из стадий жизненного цикла.
Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
При использовании итерационной модели существует риск впасть в другую (по отношению к каскадной модели) крайность. Рассмотрим ее на примере следующей схемы, получившей название «быстрого макетирования». Разработчики обсуждают требования к проекту с заказчиком. Затем в течение короткого промежутка времени, от четырех до шести недель, на основе понимания этих требований создается прототип системы. Разработчики вместе с заказчиком анализируют его работу. Заказчик может обнаружить, что для удовлетворения реальным потребностям прототип необходимо модифицировать. Выполнив оценку прототипа, разработчики получают возможность уточнить предъявляемые к системе требования путем детализации входных параметров. Например, заказчик может сказать, что необходимо изменить интерфейс или что отчеты, создаваемые программой, имеют неверный формат. На основе входных параметров в течение нескольких недель проводится корректировка прототипа, устраняются ошибки и добавляются определенные функции. Полученное ПО снова проверяется вместе с заказчиком. Процесс продолжается до тех пор, пока заказчик не согласится с тем, что продукт — удовлетворительный.
Легко объяснить, почему такой подход кажется привлекательным. Все усилия, направленные на удовлетворение нужд заказчика, являются позитивными. Кроме того, такая схема имеет и другие преимущества:
· Производительность работы коллектива очень высока. Разработчики тратят время не на создание большого количества спецификаций, которые никто и никогда не будет читать и которые станут бесполезными на следующий же день после своего выхода, а на разработку ПО. Кроме обеспечения обратной связи с заказчиком, разработчики не будут тратить время на работу, основанную на неправильном наборе допущений. Такое преимущество становится очевидным даже на ранней стадии развития проекта. В этом случае создание рабочего кода будет вопросом всего лишь нескольких недель.
· Взаимосвязи с заказчиком являются конструктивными. Всегда очень трудно завершить дискуссию о том, как в точности должна работать программа. Заказчик может не иметь четкого представления о том, что требуется, до тех пор, пока не начнется процесс разработки. Следовательно, сторонники такого процесса могут сказать: «Зачем составлять спецификации? Требования станут понятными в процессе работы».
Хотя процесс быстрого макетирования имеет определенные преимущества, его применимость ограничивается следующими недостатками.
· При быстром макетировании очень тяжело привести проект к завершающей фазе. Из-за наличия непрерывной обратной связи с заказчиком условие завершения проекта может ни когда не быть достигнуто. У разработчиков и заказчика могут возникать идеи по улучшению каждой из итераций. Постоянное усовершенствование приводит к постоянному добавлению или модификации существующих требований, и процесс может выйти из-под контроля. Заказчик никогда не удовлетворен полностью, и проект не завершится. При этом руководителю проекта требуется приложить огромные усилия для его завершения.
· Проект, выполняемый с помощью метода быстрого макетирования, сложно планировать и финансировать. Это положение прочно связано с предыдущим. Если проект тяжело завершить, то также тяжело составить график его выполнения и смету расходов. Не существует способа предсказать, какое время потребуется для завершения проекта.
· Метод быстрого макетирования неприменим для разработки ПО большим коллективом разработчиков. Этот метод хорош для небольшой группы разработчиков, работающих только с одним заказчиком. Гораздо тяжелее применить его к разработке больших систем, к которой привлекаются сотни разработчиков.
· В результате быстрого макетирования можно не получить ничего, кроме прототипа системы. Метод быстрого макетирования направлен в основном на достижение заданной функциональности. В конце концов, код может обладать правильными характеристиками и интерфейсами, но он никогда не станет пригодным для широкого применения.
Быстрое макетирование имеет много общего с подходом быстрой разработки ПО, рассмотренным во введении, и точно так же имеет ограниченное применение.
Еще одним примером реализации итерационной модели ЖЦ является получивший широкое распространение в 90-е годы XX века способ так называемой «быстрой разработки приложений», или RAD (Rapid Application Development).Подход RAD предусматривает наличие трех составляющих:
· небольших групп разработчиков (от 3 до 7 человек), выполняющих работы по проектированию отдельных подсистем ПО. Это обусловлено требованием максимальной управляемости коллектива;
· короткого, но тщательно проработанного производственного графика (до трех месяцев);
· повторяющегося цикла, при котором разработчики по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные в результате взаимодействия с заказчиком.
Основные принципы подхода RAD:
· разработка приложений итерациями;
· необязательность полного завершения работ на каждой из стадий жизненного цикла ПО;
· обязательность вовлечения пользователей в процесс разработки;
· применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
· использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности пользователей;
· тестирование и развитие проекта, осуществляемые одновременно с разработкой;
· ведение разработки немногочисленной хорошо управляемой командой профессионалов;
· грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в проектировании, программировании и тестировании ПО, способных хорошо взаимодействовать с конечными пользователями и трансформировать их предложения в рабочие прототипы.
Жизненный цикл ПО в соответствии с подходом RAD состоит из четырех стадий:
· анализ и планирование требований;
· проектирование;
· реализация;
· внедрение.
RAD наиболее хорошо подходит для относительно небольших проектов, разрабатываемых для конкретного заказчика, и не применим для построения сложных расчетных программ, операционных систем или программ управления сложными объектами в реальном масштабе времени, т.е. программ, содержащих большой объем (сотни тысяч строк) уникального кода, а также систем, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией).
Естественное развитие каскадной и спиральной моделей привело к их сближению и появлению современного итерационного подхода, который по существу представляет собой рациональное сочетание этих моделей. Различные варианты итерационного подхода реализованы в большинстве современных технологий и методов: Rational Unified Process (RUP), Microsoft Solutions Framework (MSF), XP
1.4.