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

Мы уже касались таких понятий как «жизненный цикл изделия» и «жизненный цикл ИС».

Определение. Жизненный цикл (ЖЦ) информационной системы — это множество событий, происходящих с системой в процессе ее создания и использования.

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

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

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

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

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

Этапы и стадии проектирования Часто смешивают понятия «этап» и «стадия» проектирования. Иногда говорят об этапах или фазах жизненного цикла, шагах проектирования. Возникает вопрос: как правильно?

Следует помнить, что в разных международных стандартах используемая терминология может отличаться. Мы будем, по возможности, ориентироваться на терминологию отечественных ГОСТов. Этапом проектирования будем называть часть процесса создания ИС, ограниченную некоторыми временными рамками и заканчивающуюся выпуском конкретного продукта (модели, документации, текста программы и т. п.). По общности целей этапы проектирования могут объединяться в стадии. Например, стадия «Технический проект», стадия «Внедрение» и т. п.

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

• · Формирование требований к системе (предпроектная стадия, стадия системного анализа). В рамках данной стадии проводится исследование и анализ деятельности автоматизируемого объекта; значение имеют, разумеется, только те процессы, которые соответствуют целям и задачам этого объекта. В результате получается модель объекта, которую обычно описывают в терминах бизнес-процессов и бизнес-функций. Параллельно с этим выявляются недостатки существующих информационных систем (вспоминаем принцип преемственности) и формулируются потребности в совершенствовании системы управления объектом и/или автоматизации его отдельных функций. Требования должны быть экономически обоснованными. Результатом выполнения описанных этапов стадии является оформление технико-экономического обоснования (ТЭО) и технического задания (ТЗ) на разработку ИС. Обычно ТЭО оформляется как часть ТЗ. Кроме того, в ТЗ обязательно отражаются требования к ИС и ограничения на ресурсы проектирования (в первую очередь, сроки исполнения). Требования к ИС определяются как множество функций, реализуемых системой, а также описание предоставляемой ей информации.
• · Проектирование (техническое проектирование, логическое проектирование). В соответствии с полученными требованиями проектировщики разрабатывают функциональную архитектуру ИС, которая отражает структуру выполняемых ей функций, и системную архитектуру ИС, которая представляет собой состав обеспечивающих подсистем. Построение системной архитектуры проводится на базе описания функциональной архитектуры ИС и фактически заключается в составлении технологии обработки информации с участием всех обеспечивающих подсистем ИС (в первую очередь, информационного, технического, и программного обеспечения). Результатом выполнения стадии проектирования обычно являются: 1) концептуальная, логическая и физическая модели данных ИС; 2) спецификации модулей ИС; 3) спецификация пользовательских интерфейсов ИС; 4) множество выбранных проектных решений, определяющих архитектуру ИС — в том числе выбранная платформа ПО, количество звеньев в архитектуре (однозвенная, двухзвенная [клиент-сервер или файл-сервер], трехзвенная) и др. Итоговый документ, завершающий стадию проектирования, — технический проект (ТП).
• · Реализация (рабочее проектирование, физическое проектирование, программирование). Заключается в разработке и настройке программ информационной системы и наполнении информацией соответствующих баз данных. Важным этапом реализации является составление инструкций по эксплуатации для персонала ИС. Стадия завершается оформлением рабочего проекта (РП).
• · Тестирование и внедрение (опытная эксплуатация). На этой стадии производится комплексная отладка ИС, проверка на соответствие модулей системы их спецификациям (наличие всех необходимых функций, отсутствие лишних функций), проверка надежности работы (восстанавливаемость после сбоев программного и аппаратного обеспечения, наработка на отказ и т. п.), обучение персонала. Сложные информационные системы обычно требуют опытного внедрения: например, сначала ИС устанавливается в одном отделе организации, затем постепенно к автоматизации подключаются остальные подразделения. Стадия внедрения завершается подписанием акта приемо-сдаточных испытаний — который устанавливает соответствие реализованной ИС требованиям заказчика.
• · Эксплуатация (сопровождение). На этой стадии обеспечивается процесс штатной эксплуатации ИС, который помимо всего прочего включает в себя сбор рекламаций (претензий) и статистики о функционировании ИС, исправление ошибок и недоработок, оформление требований к модернизации ИС.

Стадии технического и рабочего проектирования иногда объединяют в одну и называют стадией системного синтеза.

Модели жизненного цикла В настоящее время известны и используются следующие модели жизненного цикла:

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

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

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

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

Достоинства каскадного подхода:

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

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

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

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

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

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

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

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

• · Организация проектирования ИС по спиральной модели обычно имеет высокую стоимость (поэтому ее имеет смысл использовать для сложных и дорогостоящих систем);
• · Модель имеет сложную структуру, что может затруднить ее применение на практике неподготовленными специалистами и заказчиками (которые иногда «в силу привычки» предпочитают каскадную модель);
• · Спираль может продолжаться до бесконечности, поскольку каждая ответная реакция заказчика на созданную версию может порождать новый цикл работ;
• · Большое количество промежуточных стадий усложняет ведение документации проекта;
• · Возникают затруднения в определении момента перехода на следующую итерацию цикла. Обычно вводят временные ограничения на выполнение итерации и каждого из ее этапов. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. Планирование сроков производится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
• · Необходимость в специальных средствах и методологии прототипирования (конструирования прототипов), без которых использование модели становится неудобным.
• · Проблема внедрения. В некоторых ситуациях применение спиральной модели невозможно или ограничено, поскольку невозможно использование/тестирование продукта, обладающего неполной функциональностью (например, военные разработки, атомная энергетика и т. д.). Поэтапное итерационное внедрение корпоративных информационных систем обычно сопряжено с организационными сложностями (перенос данных, интеграция систем, изменение бизнес-процессов, учетной политики, обучение пользователей). Трудозатраты при поэтапном итерационном внедрении оказываются значительно выше, а неграмотное управление процессом внедрения может свести на нет все полученные результаты. По этой причине на этапе внедрения часто обходятся без итерационных моделей, внедряя систему «раз и навсегда».

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

Процесс ЖЦ = Перечень решаемых задач + Исходные данные + Результаты.

На сегодняшний день существует немало стандартов, регламентирующих жизненный цикл информационных систем:

• · ГОСТ 34.601−90. Введен в действие 01.01.1992. Устанавливает стадии и этапы создания автоматизированных систем и дает содержание работ на каждой стадии. Стадии и этапы работы, закрепленные в стандарте, соответствуют каскадной модели жизненного цикла.
• · ISO/IEC 12 207:1995. Международный стандарт, описывающий процессы жизненного цикла программного обеспечения. Содержит описание более, чем 220 базовых работ, выполнение которых может потребоваться в процессе создания ИС. Все процессы ЖЦ ПО подразделяются на три большие группы:
• o Основные процессы (приобретение, поставка, разработка, эксплуатация, сопровождение);
• o Вспомогательные процессы (документирование, управление конфигурацией, обеспечение качества, разрешение проблем, аудит, аттестация, совместная оценка, верификация);
• o Организационные процессы (создание инфраструктуры, управление, обучение, усовершенствование).

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

• o ISO/IEC TR 15 271:1998 — руководство по применению ISO/IEC 12 207;
• o ISO/IEC TR 16 326:1999 — руководство по управлению проектами при использовании ISO/IEC 12 207.
• · ISO/IEC 15 288:2002. Международный стандарт, описывающий возможные процессы жизненного цикла систем, созданных человеком. Был создан с учетом опыта проектирования автоматизированных информационных систем, а также с привлечением специалистов различных областей: системной инженерии, программирования, администрирования, управления качеством, безопасностью и т. д. Предполагается, что стандарт содержит полное множество процессов, которые могут протекать в ходе жизненного цикла системы. Таким образом, задача разработчика ИС заключается в формировании необходимого ему множества — среды процессов. В обзоре стандарта отмечается, что в нем не содержится описания методов и процедур, необходимых для обеспечения выполнения целей, задач и результатов указанных процессов. В 2003 году выпущено руководство по применению стандарта (ISO/IEC TR 19 760:2003). В настоящее время продолжается работа над подготовкой новой редакции стандарта серии 15 288.
• · Rational Unified Process (RUP) — концепция итеративной (спиральной) разработки программного обеспечения, предложенная фирмой Rational Software (ныне — подразделение IBM). Жизненный цикл ИС представляет собой четыре фазы: начало (inception), исследование (elaboration), конструирование (construction) и внедрение (transition). Каждая фаза может содержать в себе несколько итераций. Кроме того, завершение всех четырех фаз не всегда означает завершение работы над проектом — его развитие может продолжится новым циклом. В рамках итераций производится создание взаимосогласованных моделей, которые описываются на специально разработанном языке UML (Unified Modeling Language).
• · Microsoft Solution Framework (MSF). Итерационная методология разработки приложений, аналогичная RUP. Так же включает четыре фазы: анализ, проектирование, разработка, стабилизация и предполагает использование объектно-ориентированного моделирования. По сравнению с RUP в большей степени ориентирована на разработку ИС для бизнеса.
• · Extreme Programming (XP). Экстремальное программирование — это самая новая среди рассматриваемых методологий (первые идеи были сформированы в середине 1990;ых). Основные принципы: командная работа, эффективное взаимодействие между заказчиком и исполнителем в течение всего времени разработки ИС, использование последовательно дорабатываемых прототипов, достижение максимальной гибкости разработки (адаптация к изменяющимся требованиям заказчика).