Модели жизненного цикла программного обеспечения

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

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

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

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

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

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

2. Проектирование состоит в создании:

1) архитектуры программного обеспечения;

2) модульной структуры программного обеспечения;

3) алгоритмической структуры программного обеспечения;

4) структуры данных;

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

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

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

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

5. Сопровождение – это внесение изменений в эксплуатируемое программное обеспечение с целью:

1) исправления ошибок;

2) адаптации к изменениям внешней для программного обеспечения среды;

3) усовершенствование программного обеспечения в соответствии с требованиями заказчика.

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

1) дает план и временной график по всем этапам проекта, упорядочивая, таким образом, ход разработки;

2) на каждом этапе формируется законченный набор проектной документации, проверенный на полноту и согласованность;

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

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

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

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

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

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

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

Рисунок 2 – Процесс разработки программного обеспечения на основе каскадной модели

Макетирование

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

Основная цель макетирования – снять неопределенности в требованиях заказчика. Макетирование (прототипирование) – это процесс создания модели требуемого программного продукта. Модель может принимать одну из трех форм:

1) бумажный макет, на котором изображен человеко-машинный диалог;

2) работающий макет, который выполняет некоторую часть требуемых функций;

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

Макетирование основано на многократном повторении операций, в которых участвуют разработчик и заказчик.

Рисунок 3 – Последовательность действий при макетировании

Макетирование начинается со сбора и уточнения требований, задаваемых программному обеспечению. Разработчик и заказчик определяют все цели создания программного обеспечения, устанавливают, какие требования известны, а какие предстоит доопределить. Затем выполняется быстрое проектирование, при котором внимание сосредотачивается на тех характеристиках программного обеспечения, которые должны быть видимы пользователю. Быстрое проектирование приводит к построению макета. Макет оценивается заказчиком и используется для уточнения требований к программному обеспечению. Итерации повторяются до тех пор, пока макет не выявит все требования заказчика и тем самым не даст возможность разработчику понять, что должно быть сделано.

Достоинство макетирования заключается в том, что оно дает возможность определить полные требования к программному обеспечению.

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

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

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