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

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

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

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

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

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

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

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

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

Ниже рассматривается  основное содержание стадий и этапов жизненного цикла ИС.

Системный анализ. Основными целями этапа являются:

* формулировка потребностей  в новой ИС (определение всех  недостатков существующей ИС);

* выбор направления и  определение экономической обоснованности  проектирования ИС.

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

Этап проектирования предполагает:

* проектирование функциональной  архитектуры ИС, которая отражает  структуру выполняемых функций;

* проектирование системной  архитектуры ИС (состав обеспечивающих  подсистем);

* реализацию проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 10. Классический жизненный цикл ИС

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

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

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

Где, 1. начальный сбор требований и планирование проекта; 2. та же работа, но на основе рекомендаций заказчика; 3. анализ риска на основе начальных  требований; 4. анализ риска на основе реакции заказчика; 5. переход к  комплексной системе; 6. начальный  макет системы; 7. следующий уровень  макета; 8. сконструированная система; 9. оценивание заказчиком.

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

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

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

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

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

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

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

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

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

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

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

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

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

1.       бизнес-моделирование. Моделируется информационный поток между бизнес-функциями. Определяются ответы на вопросы: Какая информация руководит бизнес-процессом? Какая информация генерируется? Кто генерирует ее? Где информация применяется? Кто обрабатывает информацию?

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

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

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

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

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

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

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

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