Каскадный жизненный цикл

При классическом жизненном цикле ПО (каскадная или водопадная модель) разработка рассматривается как последовательность этапов, в которой переход на следующий, иерархически нижний этап происходит только после полного завершения работ на текущем этапе.

Рис. 1.1.Классический жизненный цикл разработки ПО

Характеристика основных этапов:

Разработка начинается на системном уровне и проходит через анализ, проектирование, кодирование, тестирование и сопровождение. При этом моделируются действия стандартного инженерного цикла.

Системный анализ задает роль каждого элемента в компьютерной системе и взаимодействие элементов друг с другом. Поскольку ПО является частью большой системы, то анализ начинается с определения требований ко всем системным элементам и назначения подмножества этих требований ПО.

На этапе системного анализа начинается решение задачи планирования проекта ПО. В ходе планирования проекта определяются:

- объем проектных работ и их риск,

- необходимые трудозатраты,

- формируются рабочие задачи и план-график работ.

Анализ требований относится к программному элементу – уточняются и детализируются функции ПО, его характеристики и интерфейс.

Все определения документируются в спецификации анализа. На этапе анализа требований завершается решение задачи планирования проекта.

Проектирование состоит в создании следующих представлений:

- архитектуры ПО;

- модульной структуры ПО;

- алгоритмической структуры ПО;

- структуры данных;

- входного и выходного интерфейса (входных и выходных форм данных).

Исходные данные для проектирования содержатся в спецификации анализа.

В ходе проектирования выполняется трансляция требований к ПО во множество проектных представлений.

При решении задач проектирования основное внимание уделяется качеству будущего программного продукта.

Кодирование состоит в переводе результатов проектирования в текст на языке программирования.

Тестирование – выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

Сопровождение - это внесение изменений в эксплуатируемое ПО.

Цели изменений:

- исправление ошибок;

- адаптация к изменениям внешней для ПО среды;

- усовершенствование ПО по требованиям заказчика.

Сопровождение ПО состоит в повторном применении каждого из предшествующих шагов (этапов) жизненного цикла к существующей программе, но не в разработке новой программы.

Достоинства классического жизненного цикла:

- дает план и временной график по всем этапам проекта,

- упорядочивает ход конструирования.

Недостатки классического жизненного цикла:

- реальные проекты часто требуют отклонения от стандартной последовательности шагов;

- цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично);

- результаты проекта доступны заказчику только в конце работы.

Спиральная модель

Спиральная модель включает следующие этапы:

1 – начальный сбор требований и планирование проекта;

2 – та же работа, но на основе рекомендаций заказчика;

3 – анализ риска на основе начальных требований;

4 —анализ риска на основе реакции заказчика;

5 —переход к комплексной системе;

6 – начальный макет системы;

7 – следующий уровень макета;

8 – сконструированная система;

9 —- оценивание заказчиком

Рис. 1.6. Спиральная модель:

Модель определяет четыре действия, представленные четырьмя квадрантами спирали:

Планирование – определение целей, вариантов и ограничений.

Анализ риска – анализ вариантов и распознавание/выбор риска.

Конструирование – разработка продукта следующего уровня.

Оценивание – оценка заказчиком текущих результатов конструирования.

С каждой итерацией по спирали строятся все более полные версии ПО.

В первом витке спирали:

- определяются начальные цели, варианты и ограничения;

- распознается и анализируется риск.

- если анализ риска показывает неопределенность требований, то осуществляется макетирование (используется в квадранте конструирования).

- для определения проблемных и уточненных требований может быть использовано моделирование.

- заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации (квадрант оценки заказчиком).

Следующая фаза планирования и анализа риска базируется на предложениях заказчика.

В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать».

Если риск слишком велик, проект может быть остановлен.

В большинстве случаев движение по спирали продолжается с каждым шагом продвигает разработчиков к более общей модели системы.

В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим жизненным циклом или макетированием.

Количество действий по разработке (происходящих в правом нижнем квадранте) возрастает по мере продвижения от центра спирали.

Достоинства спиральной модели:

- наиболее реально (в виде эволюции) отображает разработку программного обеспечения;

- позволяет явно учитывать риск на каждом витке эволюции разработки;

- включает шаг системного подхода в итерационную структуру разработки;

- использует моделирование для уменьшения риска и совершенствования программного изделия.

Недостатки спиральной модели:

- повышенные требования к заказчику;

- трудности контроля и управления временем разработки.

Подход RAD

Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений, или RAD (Rapid Application Development). RAD предусматривает наличие трех составляющих:

– небольших групп разработчиков (3-7 чел.), выполняющих работы по проектированию отдельных подсистем ПО. Это обусловлено требованием максимальной управляемости коллектива;

– короткого, но тщательного проработанного производственного графика (до 3 месяцев);

– повторяющегося цикла, при котором разработчики по мере того, как приложение начинает приобретать форму, запрашивают и реализуют в продукте требования, полученные в результате взаимодействия с заказчиком.

Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в проектировании, программировании и тестировании ПО, способных хорошо взаимодействовать с конечным пользователем и трансформировать их предложения в рабочие прототипы.

ЖЦ ПО в соответствии с подходом RAD включает 4 стадии:

1. Анализ и планирование требований предусматривает действия:

– определение функций, которые должна выполнять система;

– выделение наиболее приоритетных функций, требующих проработки в первую очередь;

– описание информационных потребностей. Формулирование требований к системе осуществляется в основном силами пользователей под руководством специалистов-разработчиков.

Кроме того, на данной стадии реализуются следующие задачи:

– ограничивается масштаб времени;

– устанавливаются временные рамки для каждой из последующих стадий. Определяется сама возможность реализации проекта в заданных рамках финансирования, на имеющихся аппаратных средствах.

Результатом стадии должны быть список расставленных по приоритету функций будущего ПО ЭИС и предварительные модели ПО.

2. Проектирование. На этой стадии часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. Для быстрого получения работающих прототипов приложений используются соответствующие инструментальные средства (CASE – средства). Пользователи, непосредственно взаимодействуя с разработчиками, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей стадии:

– более детально рассматриваются процессы системы;

– при необходимости для каждого элементарного процесса создается частичный прототип: экранная форма, диалог, отчет, устраняющий неясности и неоднозначности;

– устанавливаются требования разграничения доступа к данным;

– определяется состав необходимой документации.

После детального определения состава процессов оценивается количество так называемых функциональных точек разрабатываемой системы и принимается решение о разделении ЭИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое время (до 3 месяцев). Под функциональной точкой понимается любой из следующих элементов разрабатываемой системы:

– входной элемент приложения (входной документ или экранная форма);

– выходной элемент приложения (отчет, документ, экранная форма)

– запрос (пара «вопрос/ответ»);

– логический файл (совокупность записей данных, используемых внутри приложения);

– интерфейс приложения (совокупность записей данных, передаваемых другому приложению или получаемых от него).

Далее проект распределяется между различными командами разработчиков. (Опыт показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций).

Результатом данной стадии должно быть:

– общая информационная модель системы;

– функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

– точно определенные интерфейсы между автономно разрабатываемыми подсистемами;

– построенные прототипы экранных форм, отчетов, диалогов.

3. На стадии реализации выполняется непосредственно сама быстрая разработка приложения.

Разработчики производят итеративное построение реальной системы на основе полученных на предыдущей стадии моделей, а также требований нефункционального характера (требования к надежности, производительности и т.д.).

Пользователи оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется в процессе разработки.

После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения, а затем тестирование системы в целом. Реализация системы завершается выполнением работ:

– Осуществляется анализ использования данных и определяется необходимость их распределения.

– Производится физическое проектирование базы данных

– Формируются требования к аппаратным ресурсам.

– Устанавливаются способы увеличения производительности.

– Завершается разработка документации проекта.

Результатом стадии является готовая система, удовлетворяющая всем согласованным требованиям.

4. На стадии внедренияпроизводится обучение пользователей, организационные изменения и параллельно с внедрением новой системы продолжается эксплуатация существующей системы (до полного внедрения новой). Так как стадия реализации достаточно продолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на стадии проектирования системы. Приведенная схема разработки ЭИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка:

– разрабатывается совершенно новая система;

– уже было проведено обследование организации и существует модель ее деятельности.

В организации уже существует некоторая ЭИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой системой.

Следует отметить, что подход RAD, как и любой другой подход, не может претендовать на универсальность. Он хорош в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается крупномасштабная система (например, масштаба отрасли), которая не является законченным продуктом, а представляет собой комплекс программных компонентов, адаптируемых к программно-аппаратным платформам, системам управления базами данных (СУБД), средствам телекоммуникаций, то на первый план выступают такие показатели проекта как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.

Подход RAD не применим для построения сложных расчетных программ, операционных систем.

Не годится этот подход и для приложений, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы и приложений, от которых зависит безопасность людей, так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается.

Перечислим основные принципы подхода RAD.

– Разработка приложений итерациями.

– Необязательность полного завершения работ на каждой стадии ЖЦ ПО.

– Обязательность вовлечения пользователей в процесс разработки ЭИС.

– Целесообразность применения CASE – средств, обеспечивающих целостность проекта и генерацию кода приложений.

– Целесообразность применения средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы.

– Использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности пользователей.

– Тестирование и развитие проекта, осуществляемые одновременно с разработкой.

– Ведение разработки немногочисленной хорошо управляемой командой профессионалов.

– Грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.