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

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

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

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

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

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

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

ГОСТ 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)

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

Согласно стандарту 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) – это совкупность знаний, навыков, инструментария и приемов, используемых для достижения целей проектов в рамках согласованных параметров качества, бюджета, сроков и прочих ограничений.

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