Планирование Анализ риска
Рис. 3. Спиральная модель:
1 - начальный сбор требований и планирование проекта;
2 - та же работа, но на основе рекомендаций заказчика;
3 - анализ риска на основе начальных требований;
4 - анализ риска на основе реакции заказчика;
5 - переход к комплексной системе;
6 - начальный макет системы;
7 - следующий уровень макета;
8 - сконструированная система;
9 - оценивание заказчиком.
В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование (используемое в квадранте конструирования). Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен.
В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим жизненным циклом или макетированием. Заметим, что количество действий по разработке (происходящих в правом нижнем квадранте) возрастает по мере продвижения от центра спирали.
При итеративном способе недостающую часть работы можно выполнять на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Спиральная модель не исключает каскадного подхода на завершающих стадиях проекта в тех случаях, когда требования к системе оказываются полностью определенными.
Основная проблема спирального цикла - определение момента перехода на следующую стадию.
Для ее решения необходимо ввести временные ограничения на каждую из стадий ЖЦ. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных на предыдущих проектах, и личного опыта разработчиков.
Достоинства спиральной модели:
наиболее реально (в виде эволюции) отображает разработку программного обеспечения;
позволяет явно учитывать риск на каждом витке эволюции разработки;
включает шаг системного подхода в итерационную структуру разработки;
использует моделирование для уменьшения риска и совершенствования программного изделия.
Недостатки спиральной модели:
новизна (отсутствует достаточная статистика эффективности модели);
повышенные требования к заказчику;
трудности контроля и управления временем разработки.
Понятие модели жизненного цикла программного обеспечения. Прототипная модель жизненного цикла программного обеспечения.
Модель на основе создания прототипов. В связи с тем что заказчик достаточно часто не является специалистом в области ПО, он обычно плохо воспринимает «голые» спецификации продукта. Для того чтобы преодолеть информационный барьер между заказчиком и разработчиком и снизить риск получения продукта, который не соответствует выдвигаемым требованиям, стал применяться подход, направленный на создание прототипов, представляющих собой полностью или частично рабочие модели готовой системы. Он позволяет значительно улучшить взаимопонимание между всеми участниками процесса за счет последовательного, эволюционного развития системы на основе итеративного уточнения прототипов.
Применение последних подобно использованию уменьшенных макетов зданий в архитектуре – они дают возможность наглядно представить конечный результат, их построение и изменение гораздо менее трудоемко по сравнению с возведением и изменением самого здания.
Однако, несмотря на все преимущества, данная модель также не стала панацеей. Основные ее проблемы лежали в плоскости взаимоотношений «заказчик–исполнитель»: первый был заинтересован в создании как можно более подробных прототипов для того, чтобы снизить риск получения неадекватной системы, в то же время для второго каждый новый прототип означал дополнительные затраты времени и ресурсов, а в итоге – снижение рентабельности проекта.
Модель быстрого прототипирования. Модель быстрого прототипирования предназначена для быстрого создания прототипов продукта с целью уточнения требований и поэтапного развития прототипов в конечный продукт. Скорость (высокая производительность) выполнения проекта обеспечивается планированием разработки прототипов и участием заказчика в процессе разработки.
Начало жизненного цикла разработки помещено в центре эллипса. Совместно с пользователем разрабатывается предварительный план проекта на основе предварительных требований. Результат начального планирования - документ, описывающий в общих чертах примерные графики и результативные данные.
Следующий уровень – создание исходного прототипа на основе быстрого анализа, проекта базы данных, пользовательского интерфейса и некоторых функций. Затем начинается итерационный цикл быстрого прототипирования.
Разработчик проекта демонстрирует очередной прототип, пользователь оценивает его функционирование, совместно определяются проблемы и пути их преодоления для перехода к следующему прототипу. Этот процесс продолжается до тех пор, пока пользователь не согласится, что очередной прототип в точности отображает все требования.
Получив одобрение пользователя, быстрый прототип преобразуют детальный проект, и систему настраивают на производственное использование. Именно на этом этапе настройки ускоренный прототип становится полностью действующей системой.
При разработке производственной версии программы, может понадобиться более высокий уровень функциональных возможностей, различные системные ресурсы, необходимых для обеспечения полной рабочей нагрузки, или ограничения во времени.
После этого следуют тестирование в предельных режимах, определение квалификационных критериев и настройка, а затем, как обычно, функциональное сопровождение.
Понятие модели жизненного цикла программного обеспечения. Пошаговая модель жизненного цикла программного обеспечения.
Инкрементная модель. ПО в отличие, например, от микросхемы можно вводить в эксплуатацию по частям, а значит, разрабатывать и поставлять его заказчику также можно постепенно. Именно на этом основана инкрементная модель, предусматривающая дробление продукта на относительно независимые составляющие, которые разрабатываются и вводятся в эксплуатацию по отдельности.
Такая модель выгодна как для заказчика, так и для создателя системы, поскольку позволяет продвигаться вперед, соблюдая интересы обеих сторон. Однако у нее есть свои недостатки. Деление на функциональные блоки в целом замедляет процесс, так как возникает необходимость обеспечения их взаимодействия. Для многих решений этот метод неприменим, поскольку из них нельзя вычленить отдельные составляющие, которые могут быть поставлены и функционировать независимо. Существенно возрастает нагрузка и на руководящий персонал в связи с усложнением задач по координированию работ над отдельными составляющими системы, увеличивается стоимость внесения изменений в готовые компоненты, которые уже установлены и работают у заказчика.
Фазы жизненного цикла ПО: концептуализация проекта ПИ, планирование разработки, разработка требований, проектирование ПИ, кодирование и отладка, системное тестирование, сопровождение.