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

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

Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.

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

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

– Однократный проход (водопадная стратегия) – линейная последовательность этапов конструирования.

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

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

Характеристики стратегий конструирования в соответствии с требованиями стандарта IEEE/EIA 12207.2[1] представлены в табл. 1.1.

Таблица 1.1. Характеристики стратегий конструирования

Стратегия конструирования	В начале процесса определены все требования?	Множество циклов конструирования?	Промежуточное ПО распространяется?
Однократный проход	Да	Нет	Нет
Инкрементная	Да	Да	Может быть
Эволюционная	Нет	Да	Да

Стратегия однократного прохода реализована в старейшей модели жизненного цикла – каскадной (водопадной) модели (рис. 1.1)

Рис. 1.1. Каскадная модель жизненного цикла

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

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

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

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

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

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

– реально в начале проектирования требования к системе определены лишь частично;

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

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

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

Рис. 1.2. Поэтапная модель с промежуточным контролем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– Проектирование – разработка проекта очередной версии.

– Реализация – создание очередного прототипа системы.

– Тестирование – тестирование прототипа.

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

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

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

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

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

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

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

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

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

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

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

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

Компонентно-ориентированная модель [3] является развитием спиральной моде­ли и тоже основывается на эволюционной стратегии конструирования. В этой модели конкретизируется содержание квадранта конструирования – новая разработка должна основы­ваться на повторном использовании существующих программных компонентов.

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

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

уменьшает на 30% время разработки программного продукта;

уменьшает стоимость программной разработки до 70%;

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