1.2 Структура жизненного цикла программы

1.2 Структура жизненного цикла программы

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

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

Каскадная модель демонстрирует классический подход к разработке различных систем в любых прикладных областях. Для разработки программных продуктов данная модель широко использовалась в 70-х и первой половине 80-х годов.

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

Основные этапы разработки по каскадной модели:

1) анализ требований заказчика; задает роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. В ходе планирования проекта определяются объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ. Анализ требований относится к программному элементу — программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс. На этом этапе проводится исследование проблемы, которая должна быть решена, четко формулируются все требования заказчика. Результатом, получаемым на данном этапе, является техническое задание (задание на разработку), согласованное со всеми заинтересованными сторонами.

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

3) разработка; реализация проекта. Здесь осуществляется разработка программного обеспечения (кодирование) в соответствии с проектными решениями, полученными на предыдущем этапе. Методы, используемые для реализации, не имеют принципиального значения. Результатом выполнения данного этапа является готовый программный продукт.

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

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

Этапы работ в рамках каскадной модели часто также называют частями «проектного цикла» системы. Такое название возникло потому, что этапы состоят из многих итерационных процедур уточнения требований к системе и вариантов проектных решений. Жизненный цикл самой системы существенно сложнее и больше. Он может включать в себя произвольное число циклов уточнения, изменения и дополнения уже принятых и реализованных проектных решений. В этих циклах происходит развитие информационной системы и модернизация отдельных ее компонентов.

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

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

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

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

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

· существенная задержка получения результатов

· ошибки и недоработки на любом из этапов, выясняются, как правило, на последующих этапах работ, что приводит к необходимости возврата на предыдущие стадии;

· сложность распараллеливания работ по проекту;

· чрезмерная информационная перенасыщенность каждого из этапов;

· сложность управления проектом;

· высокий уровень риска и ненадежность инвестиций.

Спиральная модель. Спиральная модель (автор Барри Боэм, 1988) базируется на лучших свойствах классического жизненного цикла, к которым добавляется новый элемент — анализ риска. Спиральная модель, также в отличие от каскадной, предполагает итерационный (итерация – повторное применение) процесс разработки программного продукта. Каждая итерация представляет собой законченных цикл разработки, приводящий к выпуску внутренней или внешней версии изделия (или подмножества конечного продукта), которое совершенствуется от итерации к итерации, чтобы стать законченным продуктом.

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

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

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

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

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

С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии программного продукта.

В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит процесс создания модели требуемого программного продукта (макетирование) (используемое в квадранте конструирования). Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется па предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен.

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

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

Использование спиральной модели позволяет осуществлять переход на следующий этап выполнения проекта, не дожидаясь полного завершения работы на текущем — недоделанную работу можно будет выполнить на следующей итерации. Главная задача каждой итерации — как можно быстрее создать работоспособный продукт, который можно показать пользователям системы. Таким образом, существенно упрощается процесс внесения уточнений и дополнений в проект.

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

1) наиболее реально (в виде эволюции) отображает разработку ПП;

2) итерационная разработка существенно упрощает внесение изменений в проект при изменений требований заказчика;

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

4) обеспечивает большую гибкость в управлении проектом, давая возможность внесения тактических изменений в разрабатываемое изделие;

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

6) позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации;

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

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

1) новизна (отсутствует достаточная статистика эффективности модели);

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

3) трудности контроля и управления временем разработки. Основная проблема спирального цикла — определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каж­дый из этапов жизненного цикла. Иначе процесс разработки может превратиться в бесконечное совершенствование уже сделанного.

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

Таким образом, можно выделить три основные стратегии конструирования программных продуктов:

· однократный подход – линейная последовательность этапов конструирования;

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

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

Дата добавления: 2015-10-21