Жизненный цикл информационной системы

Жизненный цикл информационной системы

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

Содержание  жизненного цикла разработки ИС сводится к выполнению следующих стадий:

1. Планирование  и анализ требований (предпроектная  стадия) ─ системный анализ. Проводится  исследование и анализ существующей  информационной системы, определяются  требования к создаваемой ИС, формируются технико-экономическое обоснование (ТЭО) и техническое задание (ТЗ) на разработку ИС;

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

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

4. Внедрение  (опытная эксплуатация). Комплексная  отладка подсистем ИС, обучение  персонала, поэтапное внедрение  ИС в эксплуатацию по подразделениям  организации, оформление акта  о приемо-сдаточных испытаниях ИС;

5. Эксплуатация  ИС (сопровождение, модернизация). Сбор  рекламаций и статистики о  функционировании ИС, исправление  недоработок и ошибок, оформление  требований к модернизации ИС  и ее выполнение (повторение стадий 2-5).

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

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

·        каскадная модель (до 70-х годов) ─ последовательный переход на следующий этап после завершения предыдущего;

·        итерационная модель (70-80-е годы) ─ с итерационными возвратами на предыдущие этапы после выполнения очередного этапа;

·        спиральная модель (80-90-е годы) ─ прототипная модель, предполагающая постепенное расширение прототипа ИС.

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

Достоинство каскадной модели заключается в планировании времени осуществления всех этапов проекта, упорядочении хода конструирования.

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

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

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

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

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

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

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

·        планирование ─ определение целей, вариантов и ограничений;

·        анализ риска ─ анализ вариантов и распознавание (выбор) риска;

·        конструирование ─ разработка продукта следующего уровня;

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

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

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

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

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

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

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

В основе спиральной модели жизненного цикла лежит применение прототипной технологии или RAD-технологии (rapid application development ─ технологии быстрой разработки приложений). Основная идея этой технологии заключается в том, что ИС разрабатывается путем расширения программных прототипов, повторяя путь от детализации требований к детализации программного кода. Для более точного соответствия проектной документации разработанной ИС все большее значение придается ведению общесистемного репозитария и использованию CASE-технологий.

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

1.       бизнес-моделирование

2.       моделирование данных.

3.       моделирование обработки

4.       генерация приложения

5.       тестирование и объединение. 

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

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

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

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