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

Введение: важность документирования

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

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

В-третьих, существуют риски неформальных каналов коммуникации. Мы воспринимаем не только данные, но и то, как они поданы: голос, внешний вид собеседника, качество оформления документа. Согласно исследованиям, наименьшей убедительностью обладают «голые» объективные данные (степень убедительности 7%). Гораздо выше убедительность у голоса (38%) и визуальных факторов, например, дорогого костюма или качественной бумаги с золотым тиснением (55%). Нельзя забывать и о человеческом факторе: амбициозные сотрудники в конкурентной борьбе могут скрывать или искажать информацию, а культурные различия и разный уровень подготовки приводят к тому, что каждый понимает всё «в меру своей образованности». Наконец, часто нарушаются неформальные договорённости.

В пользу документирования есть и эмоциональный довод. Исследование, опубликованное в газете USA Today, показало: среди людей, которые записывали свои планы на год, успеха добились 46%. Среди тех, кто планы не фиксировал, — лишь 4%. Разница составляет более 1100%, что значительно превышает, например, долю успешных ИТ-проектов (32%).

Стадия 1: Формирование требований к АС

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

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

Стадия 2: Разработка концепции АС

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

Результат — документ «Концепция АС», который включает: результаты изучения объекта; альтернативные варианты создания АС с преимуществами и недостатками; сопоставительный анализ требований и возможностей; обоснование выбора и описание оптимального варианта; ожидаемый результат и эффективность; план реализации и затраты ресурсов; требования к качеству АС и условиям приёмки.

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

Стадия 3: Техническое задание (ТЗ)

Неформальная задача — для исполнителя это возможность «разработать экзаменационный билет для самого себя». Исполнитель сам фиксирует требования, которым затем должна будет удовлетворять система, подобно тому, как студент мечтает сам написать и изучить свой экзаменационный билет.

Стадия состоит из одного этапа: разработка и утверждение технического задания. Сначала создаётся проект ТЗ, который после утверждения становится полноценным документом.

Содержание ТЗ регламентировано и включает разделы: общие сведения; назначение и цели создания; характеристика объектов автоматизации; требования к системе; состав и содержание работ; порядок контроля и приёмки; требования к документированию; источники разработки. Ключевой момент — каждый пункт раздела «Требования к системе» должен быть подтверждён в ходе приёмочных испытаний.

Стадия 4: Эскизный проект

Неформальные задачи стадии: обосновать выбор производителя оборудования или ПО; дополнительно сузить пространство проектных решений, если ТЗ носит слишком общий характер; получить от заказчика сведения, которые не удалось добыть на предыдущих этапах. Анализируя эскизный проект, заказчик, указывая на пробелы, фактически предоставляет необходимую информацию для следующей стадии.

Стадия состоит из двух этапов: разработка предварительных проектных решений и разработка документации (обычно это «Пояснительная записка к эскизному проекту»). ГОСТ прямо допускает исключение этой стадии
.
Пояснительная записка включает: общие положения; описание процесса деятельности; описание технических решений; мероприятия по подготовке объекта автоматизации к вводу системы в действие. Последний раздел — это, по сути, напоминание заказчику о его зоне ответственности. Например, при создании центра обработки данных (ЦОД) исполнитель может отвечать за монтаж оборудования в стойках, а обеспечение электропитания, вентиляции и кондиционирования остаётся задачей заказчика.

Стадия 5: Технический проект

Задача — детализировать и утвердить проектное решение, уточнить его сметную стоимость.

Включает четыре этапа: разработка проектных решений; разработка документации на систему; разработка документации на поставку изделий (или технических требований для их разработки); разработка заданий на проектирование в смежных областях.

Состав работ: разработка общих решений по алгоритмам, функционально-алгоритмической инфраструктуре и структуре системы; разработка, оформление, согласование и утверждение проектной документации; подготовка документации на поставку. Важно отметить, что на этой стадии уже нет «защиты» — только согласование и утверждение.

Стадия 6: Рабочая документация

Задача — детализировать процедуры внедрения и эксплуатации разработанных решений. Именно на этой стадии начинается разработка или адаптация программного обеспечения (ПО). ГОСТ допускает объединение этой стадии с техническим проектом в одну — техно-рабочий проект.

На данном этапе разрабатываются программы и методики испытаний согласно перечню испытаний из ТЗ. Делать это раньше не имеет смысла (состав аппаратных и программных средств еще не утвержден окончательно), а позже — уже некогда (идёт поставка и монтаж).

Состав работ: разработка, оформление, согласование и утверждение рабочей эксплуатационной документации; разработка организационной документации; разработка ПО и программной документации (или адаптация приобретаемого ПО).

Стадия 7: Ввод в действие

ГОСТ предполагает, что внедрение выполняется «сразу и правильно», за один раз, после чего следует тщательная проверка. Стадия включает подготовку объекта и персонала, комплектацию системы, строительно-монтажные и пусконаладочные работы, а также три этапа испытаний: предварительные, опытную эксплуатацию и приёмочные.
• Предварительные испытания определяют работоспособность аппаратно-программного комплекса и возможность приёмки в опытную эксплуатацию.
• Опытная эксплуатация нужна для сбора данных о фактических характеристиках и эффективности, а также для проверки готовности персонала и качества документации. Это время, когда заказчик детально изучает документацию.
• Приёмочные испытания проверяют соответствие системы требованиям ТЗ. Каждый пункт раздела «Требования» должен быть проверен.

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

Стадия 8: Сопровождение АС

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

Такая обобщённость не противоречит современным методологиям (ITIL, ITSM), позволяя совместно использовать ГОСТ и эти практики.

Заключение

Если требуется жертвовать стадиями, ГОСТ рекомендует исключать именно проектные: допускается исключить эскизный проект, а технический проект и рабочую документацию — объединить в техно-рабочий проект. Но ни в коем случае нельзя пренебрегать обследованием и разработкой концепции.

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

Наконец, документирование — важнейший фактор успеха. Статистика неумолима: люди, которые записывают свои планы, достигают их в 12 раз чаще.

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

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

Логика развития проекта по ГОСТ 34 раскрывается через призму двойственности формальных и неформальных задач. Каждая стадия последовательно сужает поле неопределённости. Сначала через анализ вторичных, часто неполных данных формируется обоснование необходимости проекта. Затем на стадии концепции происходит переход к сбору первичной информации и отсеиванию «хотелок» — требований, нереализуемых на практике, что защищает проект от непродуктивных трат в будущем. Примечательно переосмысление роли эмоций: факторы убеждения, которые на старте считаются источником рисков, при защите концепции перед высшим руководством становятся узаконенным и необходимым инструментом для принятия решений в условиях дефицита времени и технической подготовки слушателя.

Центральным событием проектирования является создание технического задания. Метафора «экзаменационного билета», который исполнитель пишет для себя, обнажает суть ответственного подхода: ТЗ становится эталоном, по которому в финале будут судить результаты. Это диктует жёсткие требования к формулировкам — максимальная чёткость и измеримость, чтобы на приёмочных испытаниях можно было однозначно ответить на вопрос о соответствии системы. На практике это означает необходимость исключать из ТЗ непроверяемые требования, например, связанные с динамическими характеристиками виртуальных сред.

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