Стандарты, регламентирующие жизненный цикл информационных систем

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

– стадии ЖЦ – отражают состояния ИС и их изменения;

– этапы ЖЦ – входят в состав стадий; предполагают выполнение определенного объема работ в течение ограниченного времени;

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

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

Среди наиболее известных стандартов можно выделить следующие.

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

ISO/IEC 12207:1995 Information Technology – Software Life Cycle Process (принят в качествероссийского стандарта ГОСТ Р ИСО/МЭК 12207-99 – Информационные технологии. Процессы жизненного цикла программных средств) – стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не привязан к определенной модели ЖЦ. Стандарт не содержит описания фаз, стадий и этапов. Процессы стандарта будут рассмотрены далее.

ISO/IEC 15288 Systems engineering. System life cycle processes (Системная инженерия. Процессы жизненного цикла систем). Принят в качестве российского стандарта ГОСТ Р ИСО/МЭК 15288-2005 – Информационная технология. Системная инженерия. Процессы жизненного цикла систем

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

В стандарте ISO/IEC 15288 предусмотрены следующие стадии создания систем (табл. 1.1).

Таблица 1.1. Стадии создания систем (ISO/IEC 15288)

№ п/п	Стадия	Описание
	Формирование концепции	Анализ потребностей, выбор концепции и проектных решений
	Разработка	Проектирование системы
	Реализация	Изготовление системы
	Эксплуатация	Ввод в эксплуатацию и использование системы
	Поддержка	Обеспечение функционирования системы
	Снятие с эксплуатации	Прекращение использования, демонтаж, архивирование системы

Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ следует включать следующие группы процессов:

1. Договорные процессы:

• приобретение (внутреннее или у внешнего поставщика решения);
• поставка (внутренняя или у внешнего поставщика решения).

2. Процессы предприятия:

• управление средой предприятия;
• управление инвестициями;
• управление жизненным циклом систем;
• управление ресурсами;
• управление качеством.

3. Проектные процессы:

• планирование проекта;
• оценка проекта;
• контроль проекта;
• управление рисками;
• управление конфигурацией;
• управление информационными потоками;
• принятие решений.

4. Технические процессы:

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

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

Rational Unified Process (RUP – Унифицированный процесс Rational) – предлагает итеративную модель разработки, включающую четыре фазы:

– начало,

– исследование,

– построение,

– внедрение.

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

Методика Oracle CDM (Custom Development Method) – технологический материал, рассчитанный на использование в проектах с применением продуктов фирмы Oracle.

Основу CASE-технологии и инструментальной среды фирмы Oracle составляют:

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

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

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

– наличие централизованной базы данных, репозитория, для хранения спецификаций проекта прикладной системы на всех этапах ее разработки. Такой репозиторий представляет собой базу данных специальной структуры, работающую под управлением СУБД Oracle;

– возможность одновременной работы с репозиторием многих пользователей;

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

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

Методика Oracle CDM определяет следующие фазы жизненного цикла информационной системы:

– стратегия – необязательный этап, связанный с анализом и моделированием бизнес-процессов организации;

­– анализ (формулирование детальных требований к прикладной системе);

­– проектирование (преобразование требований в детальные спецификации системы);

– реализация (написание и тестирование приложений);

– внедрение (установка новой прикладной системы, подготовка к началу эксплуатации);

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

Методика Oracle CDM выделяет следующие процессы, протекающие на протяжении жизненного цикла информационной системы:

– определение производственных требований;

– исследование существующих систем;

– определение технической архитектуры;

– проектирование и построение базы данных;

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

– конвертирование данных;

– документирование;

– тестирование;

– обучение;

– переход к новой системе;

– поддержка и сопровождение.

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

Особенностью Oracle CDM является возможность применения трех моделей жизненного цикла:

– классическая – предусматривает все этапы;

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

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

Microsoft Solution Framework (MSF) – методология разработки программного обеспечения от Microsoft. MSF опирается на практический опыт корпорации Майкрософт и описывает управление людьми и рабочими процессами в процессе разработки решения. MSF представляет собой согласованный набор концепций, моделей и правил.

MSF состоит из двух моделей и трех дисциплин. MSF содержит:

· модели:

• модель проектной группы
• модель процессов

· дисциплины:

• дисциплина управления проектами;
• дисциплина управления рисками;
• дисциплина управления подготовкой.

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

Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral). Модель процессов в MSF 3.0 была дополнена еще одним инновационным аспектом: она покрывает весь жизненный цикл создания решения, начиная с его отправной точки и заканчивая непосредственно внедрением. Такой подход помогает проектным группам сфокусировать свое внимание на бизнес-отдаче (business value) решения, поскольку эта отдача становится реальной лишь после завершения внедрения и начала использования продукта.

Процесс MSF ориентирован на " вехи " (milestones) – ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата. Этот результат может быть оценен и проанализирован, что подразумевает ответы на вопросы: "Пришла ли проектная группа к однозначному пониманию целей и рамок проекта?", "Соответствует ли продукт утвержденной спецификации?", "Удовлетворяет ли решение нужды заказчика?" и т. д.

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

Модель процессов включает следующие основные фазы процесса разработки:

– Выработка концепции (Envisioning).

– Планирование (Planning).

– Разработка (Developing).

– Стабилизация (Stabilizing) – обеспечение стабильной работы.

– Внедрение (Deploying).

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

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

Итеративный подход к процессу разработки требует использования гибкого способа ведения документации. " Живые " документы (living documents) должны изменяться по мере эволюции проекта вместе с изменениями требований к конечному продукту. В рамках MSF предлагается ряд шаблонов стандартных документов, которые могут быть использованы для планирования и контроля процесса разработки.

Решение не представляет бизнес-ценности, пока оно не внедрено. Именно по этой причине модель процессов MSF содержит весь жизненный цикл создания решения, включая его внедрение – вплоть до момента, когда решение начинает давать отдачу.

Дисциплина управления рисками в MSF (MSF risk management discipline) основана на превентивном подходе к работе с рисками в условиях неопределенности, на непрерывном оценивании рисков и использовании информации о рисках в рамках процесса принятия решений на протяжении всего жизненного цикла проекта. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием пошагового процесса для успешного активного управления рисками. Этот процесс включает в себя выявление и анализ рисков; планирование и реализацию стратегий по их профилактике и смягчению возможных последствий; отслеживание состояния рисков и извлечение уроков из приобретенного опыта. Девиз MSF – мы не боремся с рисками – мы ими управляем.

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

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

1.4. Процессы жизненного цикла согласно ГОСТ Р ИСО/МЭК 12207-99

Рассмотрим процессы жизненного цикла ГОСТ Р ИСО/МЭК 12207-99 "Информационная технология. Процессы жизненного цикла программных средств". Данный стандарт основан на выделении типовых процессов: заказ, поставка, разработка, эксплуатация, сопровождение и других. На данные процессы разработан базовый стандарт – ГОСТ Р ИСО/МЭК 12207-99. На основе базового стандарта разрабатываются профили стандарта – нормативные документы, регламентирующие требования, нормы и правила, выбранные из базового стандарта, и при необходимости, дополненные и уточненные применительно к определенным классам проектов, функций, процессов и компонентов информационных систем.

В стандарте реализован принцип структурной стандартизации жизненного цикла информационной системы на основе регламентации требований к процессам жизненного цикла информационной системы. Процессы жизненного цикла выделены по принципу ответственности субъекта (Заказчика, Поставщика, Исполнителя и др.), реализующего конкретный процесс. Каждый процесс состоит из ряда действий (работ), каждое действие состоит из ряда задач. Стандарт описывает структуру жизненных циклов, но не отражает детали входящих в них работ и задач. В стандарте не определены наименования, содержание, форматы и комплектность документации, выпускаемой в процессе ЖЦ. Данные вопросы должны решаться в рамках конкретного проекта на основе использования соответствующих методик и стандартов. Это делает стандарт универсальным и уменьшает вероятность устаревания стандарта в короткие сроки.

В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:

1. Основные процессы:

• заказ (приобретение);
• поставка;
• разработка;
• эксплуатация;
• сопровождение.

2. Вспомогательные процессы:

• документирование;
• управление конфигурацией;
• обеспечение качества;
• разрешение проблем;
• аудит;
• аттестация;
• совместная оценка;
• верификация.

3. Организационные процессы:

• создание инфраструктуры;
• управление;
• обучение;
• усовершенствование.

Рассмотрим основные процессы.

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

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

Процесс разработки – это действия разработчика. Данный процесс включает следующие работы.

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

2. Анализ требований к ИС.

3. Проектирование архитектуры системы, включающее определение состава подсистем, компонентов оборудования, компонентов ПО.

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

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

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

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

8. Интеграция ПО. Сборка разработанных компонентов в соответствии с планом интеграции и тестирование агрегированных компонентов.

9. Квалификационное тестирование ПО. Для каждого компонента (желательно в присутствии Заказчика) проводится тестирование, демонстрирующее соответствие ПО своим спецификациям и готовность к использованию.

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

11. Квалификационное тестирование ИС. Полная проверка системы, оформление и проверка полного комплекта документации на систему.

12. Установка ПО. Установка ПО в той среде и на том оборудовании, которые предусмотрены договором. В процессе установки проверяется работоспособность ПО и БД.

13. Приемка ПО. Оценка результатов квалификационного тестирования ПО и системы; документирование Заказчиком с помощью Разработчика результатов оценки; передача ПО Заказчику; необходимое обучение Заказчика.

Процесс эксплуатации – это работы эксплуатационного персонала, обеспечивающего обслуживание системы.

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

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

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

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

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

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

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

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

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

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

8. Процесс решения проблем – работы по анализу и устранению (решению) обнаруженных при реализации проекта проблем.

Рассмотрим организационные процессы.

1. Процесс управления – это управление каждым процессом.

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

3. Процесс усовершенствования – основные работы, выполняемые субъектом при усовершенствовании процессов жизненного цикла.

4. Процесс обучения – обучение и постоянное повышение квалификации персонала.

В таблице 1.1 приведены ориентировочные описания основных процессов ЖЦ.

Таблица 1.1. Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)

Процесс (исполнитель процесса)	Действия	Вход	Результат
Приобретение (заказчик)	· инициирование · Подготовка заявоч­ных предложений · Подготовка договора · Контроль деятельности поставщика · Приемка ИС	· Решение о начале работ по внедрению ИС · Результаты обследования деятельности заказчика · Результаты анализа рынка ИС/ тендера · План поставки/ разработки · Комплексный тест ИС	· Технико-экономи­ческое обоснование внедрения ИС · Техническое зада­ние на ИС · Договор на поставку/ разработку · Акты приемки этапов работы · Акт приемно-сда­точных испытаний
Поставка (разработчик ИС)	· инициирование · Ответ на заявочные предложения · Подготовка договора · Планирование исполнения · Поставка ИС	· Техническое задание на ИС · Решение руководст­ва об участии в разработке · Результаты тендера · Техническое задание на ИС · План управления проектом · Разработанная ИС и документация	· Решение об участии в разработке · Коммерческие предложения/ конкурсная заявка · Договор на поставку/ разработку · План управления проектом · Реализация/ корректировка · Акт приемно-сдаточных испытаний
Разработка (разработчик ИС)	· Подготовка · Анализ требований к ИС · Проектирование архитектуры ИС · Разработка требований к ПО · Проектирование архитектуры ПО · Детальное проектирование ПО · Кодирование и тестирование ПО · Интеграция ПО и квалификационное тестирование ПО · Интеграция ИС и квалификационное тестирование ИС	· Техническое задание на ИС · Техническое задание на ИС, модель ЖЦ · Техническое задание на ИС · Подсистемы ИС · Спецификации требования к компонентам ПО · Архитектура ПО · Материалы детального проектирования ПО · План интеграции ПО, тесты · Архитектура ИС, ПО, документация на ИС, тесты	· Используемая модель ЖЦ, стандарты разработки · План работ · Состав подсистем, компоненты оборудования · Спецификации требования к компонентам ПО · Состав компонентов ПО, интерфейсы с БД, план интеграции ПО · Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам · Тексты модулей ПО, акты автономного тестирования · Оценка соответствия комплекса ПО требованиям ТЗ · Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ

Для поддержки практического применения стандарта ISO/IEC 12207 разработан ряд технологических документов: Руководство для ISO/IEC 12207 (ISO/IEC TR 15271:1998 Information technology - Guide for ISO/IEC 12207) и Руководство по применению ISO/IEC 12207 к управлению проектами (ISO/IEC TR 16326:1999 Software engineering - Guide for the application of ISO/IEC 12207 to project management). В России принято руководство ИСО/МЭК 15271-98. Информационная технология. Руководство по ИСО/МЭК 12207.

Литература к подразделам 1.1 – 1.4

1. Грекул В. И. Проектирование информационных систем / В. И. Грекул, Н. Г. Денищенко, Н. Л. Коровкина. – Интернет-университет информационных технологий – ИНТУИТ.ру, 2008. – 300 с.

2. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. – М.: Финансы и статистика, 2006. – 544 с.

3. Орлов С. А. Технология разработки программного обеспечения. – СПб.: Питер, 2002. – 464 с.

4. Липаев В. В. Документирование и управление конфигурацией программных средств. – М.: СИНТЕГ, 1998. – 220 с.

5. Петров В. Н. Информационные системы. – СПб.: Питер, 2003. – 688 с.

6. Тернер М. С. В. Основы Microsoft Solution Framework. – СПб.: Питер, 2008. – 336 с.