Перейти к основному содержимому

Навигатор по нормативной документации

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Аналитику Архитектору Руководителю Техническому писателю

Навигатор - карта раздела технического письма​

В отечественных ИТ-проектах часто встречаются два параллельных «языка» документации:

  • комплект на программное изделие (единая система программной документации, серия 19);
  • комплект на автоматизированную систему (серия 34, плюс уточняющие требования к содержанию документов).

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

Два контура — когда что выбирать​

СитуацияБазовый контурТипичный «якорный» документ
Разработка или поставка ПО как изделия (модуль, библиотека, десктопное/серверное приложение, микросервисный продукт)Серия 19 (ЕСПД)Техническое задание на программу
Создание АС целиком: бизнес-процессы + люди + оборудование + ПО + эксплуатацияСерия 34Техническое задание на создание АС
Госзаказ, ОПК, энергетика, медицина, ЖКХ — в договоре прямо указан комплект по 34-й серииСерия 34 (+ программные документы как часть АС)ТЗ на АС + проектная документация по стадиям
Стартап, внутренний продукт, SaaS без формального ГОСТ в договореВнутренний регламент (часто «ГОСТ-подобный»)BRD / PRD / backlog + выборочно формальные акты

Правило для аналитика: если заказчик автоматизирует организацию и процессы, а не только «код в репозитории», почти всегда в игру входит 34-я серия. Если предмет договора — поставка и сопровождение программы, опорой остаётся 19-я серия.

Ошибка, которую видят на приёмке: ТЗ на программу (серия 19) подают вместо ТЗ на АС (серия 34), когда в контракте фигурирует «автоматизированная система» или «АСУ». Документ может быть грамотным, но юридически не тем.

Стадии создания АС и роль аналитика​

Стадии создания автоматизированной системы (классическая модель) задают очередность решений, а не «бумаги ради бумаги»:

СтадияСмысл для проектаГде чаще всего участвует аналитик
1. ОбоснованиеНужна ли АС, эффект, риски, альтернативыФормулировка целей, KPI, границ
2. Техническое заданиеДоговорённость «что и при каких условиях»Требования, объекты автоматизации, приёмка
3. Эскизный проектВыбор варианта архитектуры и составаВарианты, схемы, оценка трудозатрат
4. Технический проектДетальные проектные решения до разработкиРазделы по подсистемам, ИО, техсредства, ПО
5. Рабочая документацияРеализация и комплект поставкиУточнение спецификаций, трассировка к ТЗ
6. Ввод в эксплуатациюОбучение, опытная эксплуатация, актыСценарии приёмки, критерии «система жива»

На стадиях 1–4 аналитик — соавтор смысла; на 5–6 — хранитель трассируемости (требование из ТЗ → тест в ПМИ → пункт руководства).

Комплект документов технического проекта (для АС)​

На стадии технического проекта заказчик ожидает не один файл, а набор взаимосвязанных разделов. Типичная логика (имена в договорах могут отличаться):

Раздел / документЧто фиксируетЧем помогает команде
Пояснительная записка к ТПОбоснование выбранных решений, сравнение вариантовСогласование с заказчиком и экспертизой
Схемы (структурные, функциональные, информационные)Архитектура «на одном взгляде»Связь с разработкой и интеграцией
Описание информационного обеспеченияДанные, справочники, потоки, качествоERD, словари, миграции
Описание программного обеспеченияСостав ПО, версии, зависимостиСпецификация, CI/CD, лицензии
Описание технических средствСерверы, сеть, отказоустойчивостьИнфраструктура и ИБ
Описание организационного обеспеченияРоли, регламенты, обучениеОргизменения при внедрении
Описание метрологического / метрологически значимого обеспеченияИзмерения, поверка (если применимо)Отраслевые ниши
Ведомость документов ТППеречень всего комплектаКонтроль полноты при сдаче

Практический совет: не смешивайте в одном PDF «всё про всё». Разделение по типам обеспечения снижает дублирование и упрощает приёмку: эксперт по ИБ читает свой блок, эксплуатация — свой.

Подробные разборы отдельных видов документов — в материалах раздела по техническому письму (ТЗ, спецификация, ПМИ, руководства по ролям).

Комплект на программное изделие (ЕСПД)​

Для программы как изделия ключевые типы документов (не обязательно все в каждом проекте):

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

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

Обозначения и версии (кратко)​

Единые правила обозначения документов и программ нужны, чтобы:

  • не путать «ТЗ v3» с «ТЗ от 2023»;
  • однозначно ссылаться в спецификации и актах;
  • вести лист регистрации изменений, а не править утверждённый PDF «тихо».

Рабочая схема для команды:

  1. Код системы + тип документа (ТЗ, СП, ПМИ, РП…) + порядковый номер + номер изменения.
  2. Любая правка после утверждения — новая строка в листе изменений или оформленное дополнение, а не перезапись файла без следа.
  3. В wiki/Confluence — зеркальная метка «соответствует обозначению X.ТЗ.001-02».

Это особенно важно при субподряде: исполнитель сдаёт не «папку с Word», а идентифицируемый комплект.

Мост к современной практике (Agile, API, wiki)​

Формальный комплект и «живая» документация не враги, если явно разделить статусы:

Артефакт agile / продуктовыйЧасто соответствует по смыслуКак не потерять трассировку
Epic / FeatureРаздел требований ТЗID требования в ТЗ ↔ ID в трекере
User StoryФункциональное требованиеМатрица «история — пункт ТЗ — тест»
OpenAPI / SwaggerОписание программных интерфейсовВерсия API в спецификации поставки
ADRФрагмент пояснительной записки / ТПНомер ADR в ПЗ или в приложении к ТП
Test plan в JiraПМИ (внутренняя часть)Экспорт сценариев в формальную ПМИ к релизу
Runbook / playbookРуководство оператора / администратораСверка ролей и процедур
README в репозиторииНе заменяет РП для госзаказаСсылка из РП: «исходники и сборка — см. репозиторий тега v…»

Принцип: wiki ускоряет работу; утверждённый комплект фиксирует обязательства. Аналитик следит, чтобы критичные решения из обсуждений не оставались только в чате.

Испытания — два уровня​

УровеньО чёмКто опирается
Испытания программыМодули, регресс, модульные/интеграционныеРазработка, QA
Испытания АСКомплексные, приёмо-сдаточные, опытная эксплуатацияЗаказчик, комиссия

Виды испытаний АС (предварительные, опытные, приёмочные и др.) задают разные протоколы и акты. ПМИ должна покрывать пункты ТЗ, иначе приёмка превращается в «покажите демо».

Чек-лист перед сдачей комплекта​

  • В договоре назван правильный контур: программа или АС.
  • ТЗ согласовано до начала ТП (или зафиксировано дополнение с подписью).
  • Спецификация перечисляет все программы и документы в поставке, включая сторонние и заимствованные.
  • Руководства не дублируют друг друга: у каждой роли свой документ.
  • ПМИ ссылается на конкретные пункты требований, а не на «система должна работать хорошо».
  • Обозначения и лист изменений согласованы между PDF, печатью и электронной копией.
  • Внутренняя wiki помечена: что является черновиком, что — экземпляром для приёмки.

Что сознательно не переносить из «каталогов и шаблонов»​

Сторонние сборники стандартов и примеры документов полезны как ориентир формы, но в учебную и проектную базу знаний не стоит тащить:

  • готовые таблицы и тексты «под копипаст» — они устаревают и привязаны к чужим вымышленным системам;
  • перечни PDF без методики — их заменяет этот навигатор плюс разборы по каждому виду документа;
  • смешение ЕСКД и ЕСПД без пояснения контекста — в IT-проекте нужно явно указать, какой контур главный.

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

Куда идти дальше в энциклопедии​

См. также

Другие статьи этого же раздела в боковом меню (как на странице «О разделе»).

Ещё 9 статей в разделе

Освоение главы0%