Жизненный цикл разработки программного обеспечения. Сравнение различных типов жизненного

цикла и вспомогательные процессы.

Классический жизненный цикл (каскадная модель или водопад)

Старейшая парадигма, разработал Уинстон Ройс, 1970.

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

Содержание основных этапов.

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

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

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

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

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

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

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

структуры данных; • входного и выходного интерфейса (входных и выходных форм данных).

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

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

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

Сопровождение — это внесение изменений в эксплуатируемое ПО с целью:

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

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

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

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

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

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

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

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

Макетирование (портотипирование)

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

Основная цель макетирования — снять неопределенности в требованиях заказчика.

Макетирование (прототипирование) — это процесс создания модели требуемого программного продукта.

Модель может принимать одну из трех форм:

бумажный макет или макет на основе ПК

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

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

Макет оценивается заказчиком и используется для уточнения требований к

ПО.Итерации повторяются до тех пор, пока макет не выявит все требования заказчика.

Достоинство макетирования:

обеспечивает определение полных требований к ПО.

Недостатки макетирования: заказчик может принять макет за продукт; разработчик может принять макет за продукт.

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

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

Инкрементная модель

Инкрементная модель является классическим примером инкрементной стратегии конструирования (рис. 1.4). Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования.

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

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

Быстрая разработка приложений

Модель быстрой разработки приложений (Rapid Application Development) — второй пример применения инкрементной стратегии конструирования (рис. 1.5).

RAD-модель обеспечивает экстремально короткий цикл разработки. RAD — высокоскоростная адаптация линейной последовательной модели, в которой быстрая разработка достигается за счет использования компонентно-ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD-процесс позволяет группе создать полностью функциональную систему за очень короткое время (60-90 дней). RAD-подход ориентирован на разработку информационных систем и выделяет следующие этапы:

бизнес-моделирование. Моделируется информационный поток между бизнес-

функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнеспроцессом? Какая генерируется информация? Кто генерирует ее? Где информация применяется? Кто обрабатывает ее?

моделирование данных. Информационный поток, определенный на этапе

бизнес-моделирования, отображается в набор объектов данных, которые требуются для поддержкибизнеса. Идентифицируются характеристики (свойства, атрибуты) каждого объекта, определяются отношения между объектами моделирование обработки. Определяются преобразования объектов данных,

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

ориентированных на языки программирования 4-го поколения. Вместо создания ПО с помощью языков программирования 3-го поколения, RAD-процесс работает с повторно используемыми программными компонентами или создает повторно используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации; тестирование и объединение. Поскольку применяются повторно используемые

компоненты, многие программные элементы уже протестированы. Это уменьшает время тестирования (хотя все новые элементы должны быть протестированы).

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

Применение RAD имеет и свои недостатки, и ограничения.

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

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

RAD не применима в условиях высоких технических рисков (то есть при использовании новой технологии).

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

Спиральная модель — классический пример применения эволюционной стратегии конструирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

Компонентно-ориентированная модель

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

Рис. 1.7.

Компонентно-ориентированная модель

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

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

1) уменьшает на 30% время разработки программного продукта; 2) уменьшает стоимость программной разработки до 70%; 3) увеличивает в полтора раза производительность разработки.