Общие подходы к организации проектирования ИС

Введение в каноническое проектирование и ГОСТ 34

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

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

Стандарт выделяет следующие стадии жизненного цикла информационной системы (ИС):
1. Исследование и обоснование
2. Разработка концепции
3. Разработка технического задания (ТЗ)
4. Эскизное проектирование
5. Техническое проектирование
6. Рабочее проектирование (включает разработку, автономное тестирование и создание документации)
7. Ввод в действие (включает опытную эксплуатацию и приемочное тестирование)
8. Сопровождение системы

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

Стадия 1: Исследование и обоснование. Предварительное обследование

Конечная цель этой стадии — сформировать задание на создание информационной системы (не путать с техническим заданием). Чтобы определить объем, сроки и стоимость проекта, необходимо провести предварительное обследование деятельности компании.

Выбор исполнителя и связанные риски

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

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

Виды и методы организации обследования

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

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

Важно понимать, что эти документы могут быть устаревшими или не отражать реального положения дел. Они служат лишь основой для подготовки вопросов, а не для построения итоговой модели.

Классификация методов организации обследования:
• По целям:
o Локальное: автоматизация отдельных задач. Рекомендуется избегать, так как это ведет к "лоскутной автоматизации".
o Системное: комплексная автоматизация. Предпочтительный подход, даже если проект реализуется поэтапно.
• По числу исполнителей:
o Индивидуальное: возможно только для ограниченных задач. Один аналитик способен охватить одно-два направления бизнеса за две недели.
o Бригадное: обязательно для крупных проектов. Ключевая задача при этом — координация работы аналитиков через единые правила сбора, систематизации и согласования информации.
• По степени охвата объекта:
o Сплошное.
o Выборочное: обследование одного из однотипных подразделений (например, если на трех складах действуют одинаковые правила). Возможность применения определяется на этапе общения с заказчиком.
• По технологии проведения:
o Последовательное: информация собирается, фиксируется, а в конце предпринимается попытка ее объединения. Недостаток — велик риск возвратов на дообследование при обнаружении пробелов.
o Параллельное: аналитики периодически сводят данные воедино, что позволяет выявлять и устранять нестыковки в процессе сбора информации, сокращая общее время работ.

Методы сбора информации

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

Структура анкеты должна включать следующие блоки вопросов:
1. Общая характеристика деятельности и представление сотрудника о целях автоматизации.
2. Детальное описание исполняемых бизнес-процессов (действия, временные интервалы и затраты).
3. Используемая информация (входные и выходные данные).
4. Техническая база рабочего места.

Проблемы объективности данных, полученных через интервью и анкеты:
• Анкета может не охватывать важные аспекты деятельности просто потому, что аналитик о них еще не знает.
• Высока доля субъективизма респондентов, их представления могут сильно расходиться.
• Сотрудники склонны давать ответы строго по инструкции, а не описывать фактическое положение дел.
• Часто упускаются управленческие бизнес-процессы, из-за чего роль руководителя подразделения на схемах становится не видна.

Результаты предварительного обследования

По итогам формируется отчет об экспресс-обследовании, который включает:
• Перечень бизнес-процессов верхнего уровня.
• Основные требования и приоритеты автоматизации.
• Оценку ресурсов с очень высокой погрешностью (200–400%). К таким цифрам следует относиться критически, требуя обоснования на опыте аналогичных проектов.
• Общую идею реализации проекта.

На основе этого отчета создается Технико-экономическое обоснование (ТЭО). Стандарт 1980 года на него устарел, и сейчас используются отраслевые рекомендации. ТЭО сильно зависит от сферы деятельности, но должно отвечать на главные вопросы: Что получит заказчик? Когда? Сколько это будет стоить?

Ключевой раздел ТЭО — «Что не будет реализовано в рамках проекта». Его отсутствие — источник серьезных конфликтов на поздних стадиях, когда заказчик ожидает функционал, который разработчик и не планировал делать. Пример: автоматизация бухгалтерии без блока финансового управления. Доработка системы после сдачи проекта может стоить значительно дороже, чем ее изначальное включение в рамки работ.

Стадия 2: Разработка концепции. Детальное обследование

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

Все выявленные задачи необходимо ранжировать по степени важности. Для этого используется принцип, схожий с методом MoSCoW:
1. Обязательные (Must have): функции, без которых система не имеет смысла.
2. Опциональные (Should/Could have): желательные и возможные функции, которые реализуются при наличии ресурсов.
3. Отсутствующие (Won't have): то, что точно не будет делаться. Здесь критически важно вовремя остановиться как заказчику, раздувающему требования, так и разработчику, стремящемуся из энтузиазма сделать "систему на все случаи жизни". Реализация функций за рамками требований — это нерациональная трата ресурсов.

Документирование результатов детального обследования

Вся информация из моделей или описаний бизнес-процессов сводится в две таблицы для каждого процесса:
1. Таблица операций бизнес-процесса (фиксирует действия).
2. Таблица документов бизнес-процесса (фиксирует информационные блоки: кто составляет, на основании чего и для какой операции).

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

Последующие стадии: от технического задания к вводу в действие

Стадия 3. Техническое задание (ТЗ). Документ с четко прописанной в ГОСТ 34 структурой. В нем также фиксируются правила и методика приемо-сдаточных испытаний системы. После разработки ТЗ согласовывается и утверждается обеими сторонами.

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

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

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

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

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

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

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

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