Содержание этапов ЖЦ ИС

Введение в стандарты процессов жизненного цикла

Стандарт ISO/IEC 12207 (ранее упоминаемый как серия 127) выделяет три группы процессов:
• Основные процессы — непосредственно реализуют процедуры проектирования и разработки.
• Вспомогательные процессы — обеспечивают качество создаваемой системы.
• Организационные процессы — управляют деятельностью команды, формируют и поддерживают её работу.

Стандарт ISO/IEC 15288 предназначен для сложных технических систем и предлагает иную группировку процессов. Некоторые из них пересекаются с ISO/IEC 12207 (приобретение, поставка, разработка, эксплуатация), однако ряд процессов детализирован значительно глубже. Процессы управления инфраструктурой, на которой разворачивается система, вынесены в отдельную группу процессов предприятия. Управление сложными командами в 15288 реализуется как проектные процессы, использующие специфические процедуры и средства проектного управления.

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

Стандарт ISO/IEC 12207 описывает процессы, их исполнителей и задачи, решаемые в рамках процессов. Однако он не фиксирует, с чего конкретно начинается и чем заканчивается каждая задача. Поэтому при практическом применении стандарта организации вынуждены дополнять описания процессов данными о входах и выходах каждой задачи. Эти столбцы не регламентированы стандартом и могут определяться для каждого предприятия или проекта индивидуально.

Сравнение стандартов и корпоративных методик

Стандарты серии ГОСТ 34 и ISO/IEC 12207 во многом пересекаются по перечню процессов. В то же время корпоративные методики (например, Oracle) могут не включать целые группы процессов, что связано с их спецификой и ограничениями применения.

Принципиальное различие: ГОСТ 34-й серии жёстко привязывает процессы и задачи к конкретным этапам жизненного цикла, тогда как в ISO/IEC 12207 подобная привязка отсутствует. В международном стандарте процессы могут выполняться на разных этапах, а из них выбираются отдельные задачи. Это позволяет гибко адаптировать состав работ под проект.

Методика Oracle CDM

В корпоративной методике Oracle CDM выделены процессы со сквозной идентификацией. В каждом процессе определены задачи, имеющие чёткие входы и выходы: документы, настройки модулей, характеристики системы. Выход одной задачи служит входом для другой, образуя жёсткие цепочки. Таким способом описаны разные сценарии — от начальной разработки до доработки системы.

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

Критерии выбора стандарта

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

Характеристика рассмотренных документов

Методика Oracle CDM:
• Очень высокая детализация: по каждой задаче известны входные/выходные документы, настройки, образцы.
• Ориентирована исключительно на деятельность разработчика; обязанности заказчика не описаны.
• Низкая гибкость: исключение или добавление задачи разрушает цепочку из-за жёсткой стыковки входов и выходов.
• Применяется в основном к базам данных Oracle и Oracle Business Suite.
• Обязательна для партнёров, распространяющих решения Oracle, в рамках контрактных соглашений.

ISO/IEC 12207:
• Кажется недостаточно конкретным, но содержит полный перечень того, что нужно делать, без указания когда и как именно.
• Не привязан к этапам жизненного цикла — задачи можно свободно распределять по проекту.
• Отсутствует жёсткая связь между процессами — их можно комбинировать, добавлять или исключать безболезненно.
• Описывает как действия разработчика, так и заказчика.
• Добровольный стандарт; обязательным становится после включения (полностью или фрагментарно) в договор.

ГОСТ 34-й серии:
• Комплекс стандартов с чёткой привязкой работ к стадиям и этапам; не требуется самостоятельно распределять процессы по жизненному циклу.
• Допускает исключение или совмещение стадий (например, эскизного проекта), использование частных технических заданий для повышения гибкости.
• Отсутствует жёсткая связь «выход-вход» между задачами, как в Oracle CDM.
• Обязателен в той мере, в какой это зафиксировано в контракте.

Модели жизненного цикла в зарубежной практике

В зарубежной литературе распространены:
• Каскадная модель (waterfall) — соответствует классической поэтапной модели со строгой последовательностью стадий.
• Модель расширения системы — требования фиксируются по отдельным аспектам, работы ведутся по независимым цепочкам (параллельно или последовательно) без модификации требований.
• Эволюционная модель — аналог спиральной модели; требования итеративно уточняются, под каждую версию требований создаются промежуточные версии системы.

Роль моделирования деятельности

Все рассмотренные стандарты сходятся в том, что первым шагом должно быть описание деятельности, подлежащей автоматизации. Текстовое описание на естественном языке неоднозначно, поэтому требуется формализация — создание моделей по определённым правилам. Модели дают однозначное представление, как для разработчика, так и для заказчика. Моделирование полезно не только при проектировании информационных систем, но и при реинжиниринге бизнес-процессов и подготовке к сертификации по стандартам ISO 9000.

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

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

Организационно-функциональное моделирование

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

Эти модели дают ответы на вопросы: с какими подразделениями предстоит работать, где размещать рабочие места автоматизированной системы. Инструментом для такого моделирования может служить программа BIG-Master, позволяющая в удобной форме описывать иерархии, устанавливать связи, делать свёртки и проекции.

Моделирование бизнес-процессов

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

Бизнес-процесс — это цепочка действий, приводящая к конкретному полезному результату (добавленная стоимость, продукт, информация). Процесс без измеримого выхода моделировать нецелесообразно.
При моделировании необходимо выявить:
• Функции (действия), выполняемые в процессе.
• Данные, передаваемые между действиями.
• Динамику — ветвления и альтернативные сценарии выполнения.

Методологии моделирования

Основные подходы к построению моделей деятельности:
• Структурный анализ — сложная функция декомпозируется на более простые, образуя иерархию «чёрных ящиков». Допускает субъективность при разбиении.
• Объектное моделирование — деятельность описывается как взаимодействие объектов. Отправная точка — внешние действующие лица (заказчики, поставщики), порождающие бизнес-прецеденты. Субъективность минимальна, так как перечень окружения объективен.
• Методология ARIS — цепочки событий и порождаемых ими действий, окружённые документами и исполнителями.

Эти методологии поддерживаются различными программными продуктами: структурное — BPwin, объектное — Rational Rose, универсальные — ARIS и др. В случаях, когда приобретение специализированного ПО невозможно, используют Visio, однако Visio не контролирует корректность модели.

Семейство стандартов IDEF

В 1981 году появились стандарты IDEF (Integrated Definition), из которых наиболее востребованы:
• IDEF0 — методология функционального моделирования (описание функций и связей).
• IDEF1 — описание потоков данных.
• IDEF1X — модель данных для генерации реляционных баз данных.
• IDEF3 — описание последовательности выполнения процессов (динамика).
• IDEF4 — объектно-ориентированное моделирование.

Нотация IDEF0

Основной элемент — функциональный блок (прямоугольник), обозначающий действие (отглагольная форма, например «Управление кадрами», но не «Отдел кадров»). К блоку подходят четыре типа стрелок:
• Слева — входы (Input) — то, что преобразуется.
• Сверху — управление (Control) — правила, инструкции.
• Справа — выходы (Output) — результаты.
• Снизу — механизмы (Mechanism) — исполнители и инструменты.

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

При декомпозиции могут возникнуть туннели: стрелки, не имеющие продолжения на родительской или дочерней диаграмме. Туннель в квадратных скобках сигнализирует о потенциальной ошибке. Его можно «разрешить», автоматически перенеся стрелку на соседний уровень, или преобразовать в круглые скобки, если деталь признана излишней.

Рекомендации по построению диаграмм IDEF0:
• Количество блоков на одной диаграмме — от двух до семи (меньше двух — повод задуматься о необходимости декомпозиции, больше семи — трудночитаемо).
• К каждому блоку желательно подводить не более одной стрелки каждого типа — идеал, к которому следует стремиться для сохранения наглядности.
• Для описания отдельной бизнес-функции обычно достаточно двух-трёх уровней декомпозиции, для крупной организации — до шести-семи.

Модели IDEF0 фиксируют статические функциональные связи. Для описания динамики (как именно функции выполняются во времени) предназначен стандарт IDEF3. Именно модели IDEF3 становятся основой для детальных функциональных требований к информационной системе.

Краткие итоги

Анализ содержания выявляет сквозную логику: от макроуровня стандартизации процессов разработки к микроуровню формального моделирования деятельности, без которого невозможно корректное проектирование информационной системы. Первоначально слушателю даётся карта нормативных документов, каждый из которых задаёт свою степень свободы и ответственности участников. Сравнение ISO/IEC 12207, ГОСТ 34 и методики Oracle не является академическим упражнением — оно напрямую определяет, какую меру адаптивности и детализации получит команда, а также объём контрактных обязательств. Прагматический вывод в том, что жёсткие детализированные цепочки Oracle эффективны лишь в гомогенной среде её продуктов, тогда как международные стандарты оставляют пространство для манёвра ценой необходимости самостоятельно проектировать входы, выходы и распределение задач по жизненному циклу.

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

Центральное место занимает методология IDEF0 как инструмент функционального структурирования. Освоение её нотации — с четырьмя типами стрелок, механизмом туннелей и дисциплиной декомпозиции — формирует у будущего аналитика навык строгого мышления: любая сложная деятельность может быть представлена иерархией «чёрных ящиков» с чёткими интерфейсами. Практическое значение этих правил выходит за рамки одной нотации: они приучают к однозначности, проверяемости и согласованности описаний, что критически важно при взаимодействии с заказчиком. Наконец, переход от статических IDEF0-диаграмм к поведенческим моделям IDEF3 очерчивает траекторию дальнейшей работы — от понимания структуры функций к детальным требованиям, на основе которых строится автоматизированная система.