Добавлен: 25.10.2018
Просмотров: 6405
Скачиваний: 24
выполняемые в логической последовательности стадии работ
позволяют планировать сроки завершения всех работ и соответствующие
затраты.
Каскадный подход хорошо зарекомендовал себя при построении ЭИС, для
которых в самом начале разработки можно достаточно точно и полно
сформулировать все требования, с тем, чтобы предоставить разработчикам свободу
реализовать их технически как можно лучше.
В то же время этот подход обладает рядом недостатков, вызванных, прежде
всего тем, что реальный процесс создания программного обеспечения никогда
полностью не укладывается в такую жесткую схему. Процесс создания ПО носит,
как правило, итерационный характер: результаты очередной стадии часто
вызывают изменения в проектных решениях, выработанных на предыдущих
стадиях. Таким образом, постоянно возникает потребность в возврате к
предыдущим стадиям и уточнении или пересмотре ранее принятых решений. В
результате реальный процесс создания ПО принимает иной вид (рис.2).
Рис. 2. Итерационный процесс создания программного обеспечения
Изображенную схему можно отнести к отдельной модели – модели с
промежуточным
контролем,
в
которой
межстадийные
корректировки
обеспечивают большую надежность по сравнению с каскадной моделью, хотя
увеличивают весь период разработки.
Основным недостатком каскадной модели является существенное
запаздывание с получением результатов и, как следствие, высокий риск создания
Формирование
требований
Проектирование
Реализация
Тестирование
Ввод в действие
Эксплуатация и
сопровождение
системы, не удовлетворяющей и изменившимся потребностям пользователей. Это
объяснятся двумя причинами:
пользователи не в состоянии сразу изложить все свои требования и не
могут предвидеть, как они изменятся в ходе разработки;
за время разработки могут произойти изменения во внешней среде,
которые повлияют на требования к системе.
В рамках каскадного подхода требования к ЭИС фиксируются в виде
технического задания на все время ее создания, а согласование получаемых
результатов с пользователями производится только в точках, планируемых после
завершения каждой стадии (при этом возможна корректировка результатов по
замечаниям пользователей, если они не затрагивают требования, изложенные в
техническом задании). Таким образом, пользователи могут внести существенные
замечания только после того, как работа над системой будет полностью завершена.
Пользователи могут получить систему, не удовлетворяющую их потребностям. В
результате приходится начинать новый проект, который может постигнуть та же
участь.
Для преодоления перечисленных проблем в середине 80-х годов была
предложена спиральная модель ЖЦ (рис.3). Ее принципиальной особенностью
является следующее: прикладное ПО создается не сразу, как в случае каскадного
подхода, а по частям с использованием метода прототипирования. Под
прототипом понимается действующий программный компонент, реализующий
отдельные функции и внешние интерфейсы разрабатываемого ПО. Создание
прототипов осуществляется в несколько итераций, или витков спирали. Каждая
итерация соответствует созданию фрагмента или версии ПО, на ней уточняются
цели и характеристики проекта, оценивается качество полученных результатов и
планируются работы следующей итерации. На каждой итерации производится
тщательная оценка риска превышения сроков и стоимости проекта, чтобы
определить необходимость выполнения еще одной итерации, степень полноты и
точности понимания требований к системе, а также целесообразность прекращения
проекта. Спиральная модель избавляет пользователей и разработчиков от
необходимости точного и полного формулирования требований к системе на
начальной стадии, поскольку они уточняются на каждой итерации. Таким образом,
углубляются и последовательно конкретизируются детали проекта, и в результате
выбирается обоснованный вариант, который доводится до реализации.
Спиральная модель - классический пример применения эволюционной
стратегии конструирования. Спиральная модель (автор Барри Боэм, 1988)
базируется на лучших свойствах классического жизненного цикла и
макетирования, к которым добавляется новый элемент — анализ риска,
отсутствующий ранее.
Как показано на рис. 3, модель определяет четыре действия,
представляемые четырьмя квадрантами спирали:
1. Планирование — определение целей, вариантов и ограничений.
2. Анализ риска — анализ вариантов и распознавание/выбор риска.
3. Конструирование — разработка продукта следующего уровня.
4. Оценивание
—
оценка
заказчиком
текущих
результатов
конструирования.
Интегрирующий аспект спиральной модели очевиден при учете
радиального измерения спирали. С каждой итерацией по спирали
(продвижением от центра к периферии) строятся все более полные версии
ПО.
Планирование
Анализ риска
Рис. 3. Спиральная модель: 1 - начальный сбор требований и планирование
проекта; 2 - та же работа, но на основе рекомендаций заказчика; 3 - анализ
риска на основе начальных требований; 4 - анализ риска на основе реакции
заказчика; 5 - переход к комплексной системе; б - начальный макет системы;
7 - следующий уровень макета; 8 - сконструированная система; 9 -
оценивание заказчиком.
В первом витке спирали определяются начальные цели, варианты и
ограничения, распознается и анализируется риск. Если анализ риска
показывает неопределенность требований, на помощь разработчику и
заказчику
приходит
макетирование
(используемое
в
квадранте
конструирования). Для дальнейшего определения проблемных и уточненных
требований может быть использовано моделирование. Заказчик оценивает
инженерную (конструкторскую) работу и вносит предложения по
модификации (квадрант оценки заказчиком). Следующая фаза планирования
и анализа риска базируется на предложениях заказчика. В каждом цикле по
спирали результаты анализа риска формируются виде «продолжать, не
продолжать». Если риск слишком велик, проект может быть остановлен.
В большинстве случаев движение по спирали продолжается, с каждым
шагом продвигая разработчиков к более общей модели системы. В каждом
цикле по спирали требуется конструирование (нижний правый квадрант),
которое может быть реализовано классическим жизненным циклом или
макетированием. Заметим, что количество действий по разработке
(происходящих в правом нижнем квадранте) возрастает по мере
продвижения от центра спирали.
При итеративном способе недостающую часть работы можно выполнять на
следующей итерации. Главная же задача - как можно быстрее показать
пользователям системы работоспособный продукт, тем самым активизируя процесс
уточнения и дополнения требований.
Спиральная модель не исключает каскадного подхода на завершающих
стадиях проекта в тех случаях, когда требования к системе оказываются полностью
определенными.
Основная проблема спирального цикла - определение момента перехода на
следующую стадию. Для ее решения необходимо ввести временные ограничения на
каждую из стадий ЖЦ. Переход осуществляется в соответствии с планом, даже
если не вся запланированная работа закончена. План составляется на основе
статистических данных, полученных на предыдущих проектах, и личного опыта
разработчиков.
Достоинства спиральной модели:
наиболее реально (в виде эволюции) отображает разработку
программного обеспечения;
позволяет явно учитывать риск на каждом витке эволюции
разработки;
включает шаг системного подхода в итерационную структуру
разработки;
использует
моделирование
для
уменьшения
риска
и
совершенствования программного изделия.
Недостатки спиральной модели:
новизна (отсутствует достаточная статистика эффективности
модели);
повышенные требования к заказчику;
трудности контроля и управления временем разработки.
ПОДХОД RAD
Одним из возможных подходов к разработке прикладного ПО в рамках
спиральной модели ЖЦ является получивший широкое распространение способ так
называемой быстрой разработки приложений, или RAD (Rapid Application
Development). RAD предусматривает наличие трех составляющих:
небольших групп разработчиков (3-7 чел.), выполняющих работы по
проектированию отдельных подсистем ПО. Это обусловлено
требованием максимальной управляемости коллектива;
короткого, но тщательного проработанного производственного графика
(до 3 месяцев);
повторяющегося цикла, при котором разработчики по мере того, как
приложение начинает приобретать форму, запрашивают и реализуют в
продукте требования, полученные в результате взаимодействия с
заказчиком.
Команда разработчиков должна представлять собой группу профессионалов,
имеющих опыт в проектировании, программировании и тестировании ПО,
способных хорошо взаимодействовать с конечным пользователем и
трансформировать их предложения в рабочие прототипы.
ЖЦ ПО в соответствии с подходом RAD включает 4 стадии:
1. Анализ и планирование требований предусматривает действия:
определение функций, которые должна выполнять система;
выделение наиболее приоритетных функций, требующих проработки
в первую очередь;
описание
информационных
потребностей.
Формулирование
требований к системе осуществляется в основном силами пользователей под
руководством специалистов-разработчиков.
Кроме того, на данной стадии реализуются следующие задачи:
ограничивается масштаб времени;
устанавливаются временные рамки для каждой из последующих стадий.
Определяется сама возможность реализации проекта в заданных рамках
финансирования, на имеющихся аппаратных средствах.
Результатом стадии должны быть список расставленных по приоритету
функций будущего ПО ЭИС и предварительные модели ПО.
2. Проектирование. На этой стадии часть пользователей принимает участие
в техническом проектировании системы под руководством специалистов-
разработчиков. Для быстрого получения работающих прототипов приложений
используются соответствующие инструментальные средства (CASE – средства).
Пользователи, непосредственно взаимодействуя с разработчиками, уточняют и
дополняют требования к системе, которые не были выявлены на предыдущей
стадии:
более детально рассматриваются процессы системы;
при необходимости для каждого элементарного процесса создается
частичный прототип: экранная форма, диалог, отчет, устраняющий неясности
и неоднозначности;
устанавливаются требования разграничения доступа к данным;
определяется состав необходимой документации.
После детального определения состава процессов оценивается количество так
называемых функциональных точек разрабатываемой системы и принимается
решение о разделении ЭИС на подсистемы, поддающиеся реализации одной
командой разработчиков за приемлемое время (до 3 месяцев). Под
функциональной точкой понимается любой из следующих элементов
разрабатываемой системы:
входной элемент приложения (входной документ или экранная