Гост стандарты по информационные системы. ООО «Техническая документация

М. Острогорский , 2008

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

Автоматизированная система, ее функции и задачи

Определение автоматизированной системы

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

Цели деятельности

Автоматизированная система может существовать только там, где имеется персонал, занятый определенной деятельностью. Как правило, речь идет о деятельности, результаты которой полезны кому-то вне зависимости от применяемых инструментов. Например, в театральную кассу я обращаюсь за билетом, и меня вполне устроит, если кассирша выпишет мне его ручкой на бланке, лишь бы меня по нему пустили в зал. Кассирше, по большому счету, тоже все равно, как именно изготовить билет. Ее устроит любой способ, если он будет не слишком трудоемок и обеспечит ей возможность продать мне билет. Иначе говоря, у нас с ней есть общая цель. В ГОСТ 34.003-90 для ее обозначения используется термин цель деятельности . Всякий раз, когда очередной зритель отходит от окошка с билетом в руках, а театр становится чуточку богаче, эта цель деятельности достигается.

Функции автоматизированной системы

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

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

Функция автоматизированной системы — фундаментальное понятие в ГОСТ 34. Автоматизированная система рассматриваться, в первую очередь, как сумма своих функций и уж потом как куча «софта» и «железа». Самое главное, что делает система, а из чего она состоит, второстепенно.

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

Задачи автоматизированной системы

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

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

Одна и та же задача может решаться при выполнении разных функций. Например, если в автоматизированной системе имеется несколько функций для продажи билета, то выполнение каждой из них может в какой-то момент потребовать вывода билета печать.

Состав автоматизированной системы

Подсистемы

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

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

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

Компоненты

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

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

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

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

Виды обеспечения

Одно из наиболее сложных понятий для начинающего пользователя ГОСТ 34 — вид обеспечения . Что за обеспечение такое? Можно ли его увидеть или пощупать? Продать или купить?

Каждый вид обеспечения объединяет в себе компоненты или технические решения определенного характера. В ГОСТ 34 упоминается много разных видов обеспечения, последовательно описывать здесь каждый из них мы не будем, а перечислим только наиболее заметные:

• информационное обеспечение — все данные и метаданные, с которыми работает система;
• программное обеспечение — все программы, которые входят в состав системы;
• техническое обеспечение — все технические средства (иначе говоря, оборудование, аппаратура), которые входят в состав системы.

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

Стандарты по АСУ, не объединенные в серии.

ГОСТ 15971-90. Системы обработки информации. Термины и определения.

ГОСТ 19781-90. Обеспечение систем обработки информации программное. Термины и определения.

ГОСТ 28806-90. Качество программных средств. Термины и определения. Введен с 1.01.92.

ГОСТ 28195-89. Оценка качества программных средств. Общие положения.

ГОСТ 25868-91. Оборудование периферийное систем обработки информации. Термины и определения. М. Издательство стандартов. 1992, 34 с. Введен с 1.01.93.

ГОСТ 28147-89. Системы обработки информации. Защита криптографическая. Алгоритмы криптографического преобразования.

ГОСТ 28803-90 (ИСО 6523-84). Обмен данными. Структура идентификации организаций. Введен с 01.01.93.

ГОСТ Р ИСО/МЭК 9125-93. Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению.

ГОСТ Р ИСО/МЭК ТО 9294-93. Информационная технология. Руководство по управлению документированием программного обеспечения.

ГОСТ Р ИСО 9127-94. Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов.

РИСО 9126-93. Системы обработки информации. документация пользователя и информация на упаковке для потребительских программных пакетов.

ГОСТ РИСО/МЭК 12207. Процессы жизненного цикла программного обеспечения. Введен с 01.07.2000.

ГОСТ Р50739-95. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Общие технические требования.

ГОСТ Р51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов. Типовое руководство.

ГОСТ 28140-89. Системы обработки информации. Язык программирования Паскаль.

ГОСТ Р 51169-98. Качество служебной информации. Система сертификации информационных технологий в области качества служебной информации. Термины и определения.

ГОСТ Р 51168-98. Качество служебной информации. Условные обозначения элементов технологических процессов переработки данных.

ГОСТ Р 51170-98. Качество служебной информации. Термины и определения.

ГОСТ Р 51171-98. Качество служебной информации. Правила предъявления информационных технологий на сертификацию.

ГОСТы серии 34. "Информационная технология (ИТ)".

РД 50-680-88. Автоматизированные системы. Основные положения.

РД 50-682-89. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Общие положения.

ГОСТ 34.003-90. ИТ. Автоматизированные системы. Термины и определения.

ГОСТ 34.201-89. ИТ. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем.

ГОСТ 34.601-90. ИТ. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. (Взамен ГОСТ 24.601-86, 24.602-86).

ГОСТ 34.602-89. ИТ. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

ГОСТ 34.603-89. ИТ. Виды испытаний автоматизированных систем.

РД 50-34.698-90. ИТ. Автоматизированные системы. Требования к содержанию документов.

ГОСТ 34.1501.1-92 (ИСО/TR 10314-1-90). ИТ. Промышленная автоматизация. Основное производство. Часть 1. Эталонная модель стандартизации и методология идентификации требований к стандартизации.

ГОСТы серии 19. "Единая система программной документации (ЕСПД)".

ГОСТ 19.001-77. Единая система программной документации. Общие положения.

ГОСТ 19.701-90. (ИСО 5807-85). ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения. (Взамен ГОСТ 19.002-80, 19.003-80).

ГОСТ 19.005-85. ЕСПД. Р-схемы алгоритмов и программ. Обозначения условные графические и правила выполнения.

ГОСТ 19.101-77. ЕСПД. Виды программ и программных документов.

ГОСТ 19.102-77. ЕСПД. Стадии разработки.

ГОСТ 19.103-77. ЕСПД. Обозначения программ и программных документов.

ГОСТ 19.104-78. ЕСПД. Основные надписи.

ГОСТ 19.105-78. ЕСПД. Общие требования к программным документам.

ГОСТ 19.106-78. ЕСПД. Требования к программным документам, выполненным печатным способом.

ГОСТ 19.201-78. ЕСПД. Техническое задание. Требование к созданию и оформлению.

ГОСТ 19.202-78. ЕСПД. Спецификация. Требования к содержанию и оформлению.

ГОСТ 19.301-78 ЕСПД. Программа и методика испытаний. Требования к содержанию и оформлению.

ГОСТ 19.401-78. ЕСПД. Текст программы. Требования к содержанию и оформлению.

ГОСТ 19.402-78. ЕСПД. Описание программы.

ГОСТ 19.403-79. ЕСПД. Ведомость держателей подлинников.

ГОСТ 19.404-79. ЕСПД. Пояснительная записка. Требование к содержанию и оформлению.

ГОСТ 19.501-78. ЕСПД. Формуляр. Требования к описанию и оформлению.

ГОСТ 19.502-78. ЕСПД. Описание применения. Требования к описанию и оформлению.

ГОСТ 19.503-79. ЕСПД. Руководство системного программиста. Требования к описанию и оформлению.

ГОСТ 19.504-79. ЕСПД. Руководство программиста. Требования к описанию и оформлению.

ГОСТ 19.505-79. ЕСПД. Руководство оператора. Требования к описанию и оформлению.

ГОСТ 19.506-79. ЕСПД. Описание языка. Требования к описанию и оформлению.

ГОСТ 19.507-79. ЕСПД. Ведомость эксплуатационных документов.

ГОСТ 19.508-79. ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению.

ГОСТ 19.601-78. ЕСПД. Общие правила дублирования, учета и хранения.

ГОСТ 19.602-78. ЕСПД. Правила дублирования, учета и хранения документов, выполненных печатным способом.

ГОСТ 19.603-78. ЕСПД. Общие правила внесения изменений.

ГОСТ 19.604-78. ЕСПД. Правила внесения изменений в документы, выполненные печатным способом.

ГОСТы серии 24. "Единая система стандартов автоматизированных систем управления (ЕССАСУ)".

ГОСТ 24.104-85. ЕССАСУ. Автоматизированные системы управления. Общие требования.

ГОСТ 24.301-80. Система технической документации на АСУ. Общие требования к выполнению текстовых документов.

ГОСТ 24.302-80. Система технической документации на АСУ. Общие требования к выполнению схем.

ГОСТ 24.701-86. ЕССАСУ. Надежность автоматизированных систем управления. Основные положения.

ГОСТ 24.702-85. Эффективность автоматизированных систем управления. Основные положения.

ГОСТ 24.703-85. Типовые проектные решения в АСУ. Основные положения.

Вместо ГОСТ 24.601-86 и 24.602-86 см. ГОСТ 34.601-90.

Стандарты в области защиты информации.

ГОСТ Р 50922-96. Защита информации. Основные термины и определения.

ГОСТ Р 50934-96. Защита информации. Организация и содержание работ по защите информации об образцах военной техники от технических разведок. Общие положения.

ГОСТ Р 50739-95. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Общие технические требования.

ГОСТ Р 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов. Типовое руководство.

ГОСТ Р 51275-99. Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения.

ГОСТ Р 51241-98. Средства и системы управления доступом. Классификация. Общие технические требования. Методы испытаний.

ГОСТ Р 51583-2000. Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие требования.

ИСО/МЭК 15408-99. Критерии безопасности информационных технологий.

Классификация и кодирование информации.

Материалы по стандартизации.

Правила стандартизации. Основные положения и порядок проведения работ по разработке, ведению и применению общероссийских классификаторов. ПР 50.1.024-2005. Федеральное агентство по техническому регулированию и метрологии. Приказ №311-ст от 14.12.2005.

Сегодня мы поговорим об отечественных стандартах на проектную документацию. Как эти стандарты работают на практике, чем они плохи и чем хороши. При разработке документации для государственных и серьезных частных заказчиков у нас обычно нет выбора - в требования по документированию ТЗ вписано соблюдение стандартов. На практике мне приходилось сталкиваться с различными примерами недопонимания структуры стандартов, того, что должно быть в документах и зачем эти документы нужны. В итоге из-под пера техписателей, аналитиков и специалистов выходят порой такие перлы, что непонятно, в каком состоянии сознания они писались. А ведь на самом деле все достаточно просто. Поиск по Хабру не вернул ссылок на более-менее целостный материал на данную тему, потому предлагаю закрасить этот досадный пробел.

Что такое стандарты на документацию?

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

Это базовый документ, в котором приводится полный перечень документации ГОСТ 34, рекомендации по кодированию документов, к каким стадиям проекта относятся документы (стадии описываются в ГОСТ 34.601-90), а также как их можно объединить между собой.

Фактически, этот стандарт представляет собой большую таблицу с комментариями. Ее можно загнать в Excel для удобства использования.

Объемистый стандарт, с различной степенью детальности описывающий содержание проектных документов. В качестве индекса используется упомянутый выше ГОСТ 34.201-89.

К стандарту РД 50-34.698-90 существует множество вопросов и трактовок его положений, которые ввиду их неконкретности, часто понимают по-разному заказчик и исполнитель или даже члены проектной команды. Но ничего более конкретного у нас, к сожалению, нет.

Рассмотрим теперь плюсы и минусы стандартов, начав традиционно с минусов.

Минусы стандартов

• приложения двухуровневые, состоящие из клиентской программы и сервера СУБД (никаких трех- и более «уровневых» приложений, никаких Weblogic или JBoss)
• структура таблиц базы данных, будучи описана, даст представление о логической модели данных (то, что между приложением и базой может находиться какой-нибудь Hibernate, тогда казалось нехорошим излишеством)
• пользовательский интерфейс однооконный (а разве бывает другой? А что такое «браузер»?)
• Отчетов в системе немного, все они бумажные и печатаются на матричном принтере
• Разрабатываемая программа ориентирована на решение «задачи обработки информации», которая имеет четкий вход и выход и узко специализирована. В основе обработки информации лежит «алгоритм». Иногда «алгоритмов» бывает несколько. (Объектно-ориентированное программирование тогда делало лишь свои первые шаги и серьезно не рассматривалось).
• администратор базы данных понимает, какая информация лежит в таблицах и активно участвует в редактировании системных справочников (а разве бывает один сервер СУБД для 50 разных приложений?)

5.8. Чертеж формы документа (видеокадра)
В документе должно быть приведено изображение формы документа или видеокадра в соответствии с требованиями государственных стандартов унифицированной системы документации Р 50-77 и необходимые пояснения.

Смысл документа в том, что на советских предприятиях использовались так называемые «Участки печати», где стояли матричные скоростные принтеры, драйверы к которым часто писали сами инженеры. Поэтому они должны были поддерживать реестр всех документов, которые требовалось печатать для гарантии того, что в напечатанном виде документы будут выглядеть так, как положено.

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

Сейчас уже нам ничего не говорят слова «машинограмма», «видеокадр», «АЦПУ». Я тоже их не застал в употреблении, хотя заканчивал профильный институт в 90-е. Это было время появления Windows 3.1, VGA дисплеев, трехдюймовых дискет и первых отечественных интернет-сайтов. Но в стандарте эти слова есть, и заказчик иногда капризно требует предоставить ему полный комплект документации в соответствии с ГОСТ 34.201-89. Более того, подобные формулировки в ТЗ кочуют из одного министерства в другое и стали уже неким негласным шаблоном, в который вбивают содержательную часть.

Так что документ с дурацким названием «Чертеж формы документа (видеокадра)» в проекте должен быть и должен быть не пустым.

Что в стандарте хорошо

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

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

Когда вам требуется грамотно поставить задачу западным подрядчикам, которые про наши ГОСТы слыхом не слыхивали, можно также опираться на эти стандарты, а точнее на их контент, смысловую составляющую. Потому что, повторюсь, гарантия полноты информации дорогого стоит. Как бы мы себя не тешили высоким уровнем своего профессионализма, мы можем забыть включить в состав наших требований элементарные вещи, тогда как тот же ГОСТ 34.602-89 «помнит» обо всем. Если вам непонятно, как должен выглядеть результат работы западных подрядчиков, посмотрите на требования к документированию, к рекомендуемым разделам. Уверяю вас, лучше не придумать! Скорее всего, есть западные аналоги наших стандартов, в которых все может быть полнее, современнее и лучше. К сожалению, я с ними не знаком, так как не было пока ни одного случая, чтобы наших ГОСТов было бы недостаточно.

Можно смеяться над тем, что создатели стандартов ничего не знали о java или.NET, о HD мониторах и Интернете, но я бы не советовал недооценивать масштаб проделанной ими работы и ее ценность для нашего профессионального сообщества.

Как читать и понимать стандарты документации по ГОСТ серии 34

Стандарт делит все документы по двум осям - время и предметная область. Если посмотреть таблицу 2 в ГОСТ 34.201-89, то хорошо видно это деление (колонки «Стадия создания» и «Часть проекта»

Стадии создания АСУ

• Эскизный проект (ЭП)
• Технический проект (ТП)
• Разработка рабочей документации (РД)

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

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

Части (разделы) проектной документации по созданию АСУ

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

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

Математическое обеспечение (МО) , отвечающее на вопросы: какая логика зашита внутри «черного ящика»? Почему выбраны именно эти алгоритмы, именно такие формулы и именно такие коэффициенты?

Математическое обеспечение ничего не знает ни о процессорах, ни о базах данных. Это отдельная абстрактная область, обитель «сферических коней в вакууме». Но математическое обеспечение бывает очень плотно связано с предметной областью, aka Реальная жизнь. Например, управляющие алгоритмы для систем управления дорожным движением требуется согласовать в ГИБДД перед тем, как их будет согласовывать заказчик. И тут понимаешь, зачем их выделяют в отдельную книжицу. Потому что в ГИБДД никому не интересно, на какой ОС будет работать сервер приложения, а вот какой знак и ограничение скорости выскочит на табло в дождь или в снег очень даже интересно. Они отвечают за свою часть, и ничего другого подписывать не собираются. С другой стороны, когда они подписали, не будет вопросов к технической стороне вопроса - почему выбрали те, а не другие табло или светофоры. Мудрость «предков» как раз и проявляется в таких вот практических кейсах.

Информационное обеспечение (ИО) . Еще один срез системы. На этот раз делается прозрачным черный ящик нашей системы и мы смотрим на циркулирующую в нем информацию. Представьте себе модель кровеносной системы человека, когда все остальные органы невидимы. Вот что-то подобное и есть Информационное обеспечение. В нем описываются состав и маршруты прохождения информации внутри и снаружи, логическая организация информации в системе, описание справочников и систем кодирования (кто делал программы для производства, тот знает, как они важны). Основная описательная часть приходится на этап ТП, но в этап РД перетекают некоторые «рудименты», наподобие документа «Каталог баз данных». Понятно, что раньше он содержал именно то, что написано в названии. Но сегодня попробуйте для сложной комплексной системы сформировать такой документ, когда очень часто в составе системы используются покупные подсистемы со своими загадочными информационными хранилищами. Я уж не говорю о том, что этот документ не особенно сейчас и нужен.

Или вот «Ведомость машинных носителей информации». Понятно, что раньше в нем были номера магнитных барабанов или бобин с пленкой. А сейчас что туда вносить?

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

Программное обеспечение (ПО) . Любимая всеми часть проектной документации. Да хотя бы потому, что это всего один документ! И потом, всем понятно, что туда нужно записывать. Но я, все-же, повторю.

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

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

Дело в том, что стандарт предусматривает описание всего технического обеспечения, включая компьютерное «железо» и сети, инженерные системы и даже строительную часть (если потребуется). А это хозяйство регламентируется громадным количеством стандартов и нормативных актов, согласуется в разных организациях и поэтому удобнее все дробить на части и согласовывать (править) по частям. В то же время стандарт позволяет объединять некоторые документы друг с другом, что имеет смысл делать, если всю кучу согласует один человек.

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

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

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

На стадии РД появляются другие, более интересные документы, которые мне бы хотелось рассмотреть отдельно.

Руководство пользователя . Комментарии излишни, я думаю.

Методика (технология) автоматизированного проектирования . В этот документ при необходимости можно поместить описание процесса сборки ПО, управления версиями, тестирования и т.п. Но это если в ТЗ заказчик желает самолично осуществлять сборку ПО. Если он этого не требует (и не платит за это), то вся ваша внутренняя кухня не его ума дело, и этот документ делать не нужно.

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

Описание бизнес-процессов, ролевые и должностные инструкции, регламенты работы - все это ОРД, то есть организационно-распорядительная документация. Которая является продуктом консалтингового проекта, который у вас, насколько я понимаю, не покупали. А покупали у вас проект технический и документацию к нему тоже техническую.

Технологическая инструкция является прослойкой между ОРД и руководством пользователя. РП подробно описывает как нужно делать те или иные действия в системе. Технологическая инструкция говорит о том, какие действия необходимо выполнять в тех или иных случаях, связанных с эксплуатацией системы. Грубо говоря, технологическая инструкция это краткий дайджест по РП для конкретной должности или роли. Если у заказчика роли не сформированы или он хочет, чтобы вы сами сформировали роли и требования к должностям, включите в документ самые базовые роли, например: оператор, старший оператор, администратор. Замечания заказчика на тему, «а у нас не так» или «а нам не нравится» должны сопровождаться перечнем ролей и описанием должностных обязанностей. Потому что бизнес-процессы мы не ставим . Мы эти бизнес-процессы автоматизируем .

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

Описание технологического процесса обработки данных (включая телеобработку) . Жалкий рудимент пещерного века, когда были специально выделенные «Операторы ЭВМ», скармливающие машине перфокарты и упаковывающие распечатку результата в конвертик. Эта инструкция - для них. Что в нее писать в XXI веке - я вам точно сказать не могу. Выкручивайтесь сами. Самое лучшее, это просто забыть про этот документ.

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

А в-третьих, в состав ОР входит мега-документ под названием «Пояснительная записка к техническому проекту», который по задумке представляет собой некий Executive Summary, а по факту многие проектанты пихают в него вообще все полезное содержание стадии ТП. Подобный радикальный подход бывает оправдан и даже взаимно выгоден и заказчику и исполнителю работ, но в определенных случаях.

Варианты использования ГОСТ 34

1. Полное и точное следование стандарту . Добровольно никто, естественно, такую тучу документов писать не будет. Поэтому полный комплект документов готовится только по настоятельной просьбе заказчика, которую он закрепил в ТЗ и еще договором сверху придавил. В таком случае требуется понимать все буквально и отдать заказчику физические «книжки», на которых будут стоять названия документов из таблицы 2 ГОСТ 34.201-89 за исключением совсем уж ненужных, перечень которых вы обязательно должны обговорить и закрепить письменно. Содержание документов также должно без всякой фантазии соответствовать РД 50-34.698-90, вплоть до названия разделов. Для того, чтобы у заказчика взорвался мозг, иногда большую систему делят на подсистемы, и для каждой подсистемы выпускают отдельную проектную документацию. Выглядит это устрашающе и нормальному контролю при помощи земного разума не подлежит. Особенно в части интеграции подсистем. Что значительно упрощает приемку. Главное, чтобы вы сами при этом не запутались и чтобы ваша система все-таки заработала как надо.
2. Мы просто любим ГОСТы . В серьезных больших компаниях любят стандарты. Потому, что они помогают людям лучше понимать друг друга. Если ваш заказчик замечен в любви к порядку и стандартизации, постарайтесь придерживаться стандартной идеологии ГОСТ при разработке документов, даже если этого не требует ТЗ. Вас лучше поймут и одобрят согласующие специалисты, а вы сами не забудете включить в документацию важную информацию, лучше будете видеть целевую структуру документов, точнее планировать работы по их написанию и сэкономите себе и коллегам массу нервов и денег.
3. Нам плевать на документацию, лишь бы все работало . Исчезающий вид безответственного заказчика. Подобный взгляд на документацию пока еще можно встретить у небольших и бедных заказчиков, а также в оставшихся со времен перестройки авторитарных «идиотократиях», где босс окружен верными друзьями - директорами, и все вопросы решаются в личных беседах. Вы вольны в подобных условиях забивать на документирование вообще, но лучше, все таки, прицел не сбивать и хотя бы схематично наполнять содержимым документацию. Если не этому заказчику, так следующему передадите (продадите).

Заключение

Эта статья была о наших ГОСТах на документирование АСУ. ГОСТы старые, но, как оказалось, до сих пор очень даже полезные в хозяйстве. Не считая некоторые явные рудименты, структура документации обладает свойствами полноты и непротиворечивости, а следование стандарту снимает многие проектные риски, о существовании которых мы можем по началу не догадываться.

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

Тридцать четвертым ГОСТом на жаргоне ИТ-специалистов называется совокупность взаимосвязанных стандартов, которые имеют номер, начинающийся на 34: ГОСТ 34.602-89, 34.003-90, 34.603-92, 34.201-89, 34.601-90, 34.698-90, 34.320-96, 34.321-96, а также руководящий документ РД 50-34.698-90 и два стоящих особняком стандарта, относящихся к узкоспециальной теме криптозащиты - ГОСТ 34.10 -01 и ГОСТ 34.11-94.

Все эти стандарты появились в конце 80-х - начале 90-х годов (год выпуска обозначен числом после дефиса), заменив или дополнив более ранние стандарты 19-й и 24-й серий.

Чтобы понять и оценить логику, содержащуюся в семействе ГОСТ 34, проанализируем содержание составляющих его стандартов более подробно. Ориентированные на ИТ-специалистов ГОСТ 34.320-96 "Концепции и терминология для концептуальной схемы и информационной базы", ГОСТ 34.321-96. "Эталонная модель управления данными", ГОСТ 34.10 -01 "Криптографическая защита информации . Процессы формирования и проверки электронной цифровой подписи" и ГОСТ 34.11-94 "Криптографическая защита информации . Функция хэширования" я рассматривать не буду, поскольку они рассчитаны не на управленцев, а на технических специалистов. Для нас интерес представляют следующие стандарты:

• ГОСТ 34.201-89. "Виды, комплектность и обозначение документов при создании автоматизированных систем";
• ГОСТ 34.003-90 "Термины и определения";
• ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы";
• ГОСТ 34.603-92 "Виды испытаний автоматизированных систем";
• ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания";
• Руководящий документ РД 50-34.698-90 "Автоматизированные системы. Требования к содержанию документов".

ГОСТ 34.003-90, помимо того что содержит многочисленные ошибки, полностью устарел и потерял актуальность, поэтому о нем я говорить не буду. Таким образом, далее рассматривается четыре последних документа.

Стандарт ГОСТ 34.201-89

Серьезно устаревший, но отчасти пригодный для использования стандарт (ГОСТ 34, 1989а). Устанавливает соответствие документов стадиям создания АС 1АС - автоматизированная система, т. е. информационная система, разрабатываемая или внедряемая на конкретном предприятии. , описанным в ГОСТ 24.601 (впоследствии заменен на ГОСТ 34.601). По составу документов и стадиям проекта можно проследить происхождение стандарта из практики строительства. Очевидно, проектная природа строительства и деятельности по созданию информационной системы навела авторов стандарта на мысль распространить основные формы организации строительных проектов на проекты создания информационных систем. Отчасти это оказалось удобно - такие документы, упомянутые в стандарте, как " Техническое задание ", " Эскизный проект ", " Технический проект ", " Инструкция " (пользователя), " Программа и методика испытаний" прочно вошли в практику создания систем. С другой стороны, "Ведомость машинных носителей информации", "Каталог базы данных " или "Ведомость держателей подлинников" вряд ли сейчас имеют смысл. Стандарт включает также элементы практики делопроизводства в виде правил кодирования документов.

Короче говоря, при "творческом" подходе он может еще послужить, особенно в тех организациях, где проектная деятельность регулируется аналогичными проектно-ориентированными стандартами, а состав проектных документов близок к тому, что предлагает ГОСТ 34.201-89.

Стандарт ГОСТ 34.601-90

Один из наиболее применяемых до сих пор стандартов (ГОСТ 34, 1990), определяющий стадии и этапы создания автоматизированной системы. Приведенная ниже таблица является центральной в стандарте.

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

Помимо вышеприведенной таблицы ГОСТ 34.601-90 содержит справочное Приложение 1 с поэтапной расшифровкой работ , включая указание на документы, возникающие в результате этих работ , а также Приложение 2 - "Перечень организаций, участвующих в работах по созданию АС ". Это подсказывает способ адаптации стандарта к конкретным условиям: достаточно переработать Приложения, и получится вполне разумный корпоративный стандарт на создание ИС. Причем опять-таки эта работа под силу обычному управленцу.

Стандарт ГОСТ 34.602-89

Требование "подготовить Техническое задание в соответствии с ГОСТ 34.602-89", знакомо, наверное, каждому, кто хоть однажды участвовал в заказной разработке ИС или ее приемке, да и вообще всем, кто так или иначе связан с информационными системами. Некоторые разработчики до сих пор считают хорошим тоном помнить наизусть состав Технического задания (ТЗ) в соответствии с ГОСТ 34.602-89 (ГОСТ 34, 1989б).

1. Общие сведения.
2. Назначение и цели создания (развития) системы.
3. Характеристика объектов автоматизации.
4. Требования к системе.
5. Состав и содержание работ по созданию системы.
6. Порядок контроля и приемки системы.
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.
8. Требования к документированию.
9. Источники разработки.

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

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

1. по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;

   при создании системы в две или более очереди - перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях;

2. временной регламент реализации каждой функции, задачи (или комплекса задач);
3. требования к качеству реализации каждой функции (задачи или комплекса задач), к форме представления выходной информации , характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов;
4. перечень и критерии отказов для каждой функции, по которой задаются требования по надежности".

Приведенный отрывок демонстрирует иерархичность стандарта: система состоит из подсистем, комплексов задач, отдельных задач, функций. Чем точнее и подробнее сформулированы требования, тем более предсказуемым будет результат. Специально формулируются требования к функциям взаимодействия подсистем (сейчас мы бы сказали "к методам интеграции"), функции привязываются к плану-графику реализации системы (который тем самым также становится иерархическим). Специально упомянуты требования к качеству. Форма представления выходной информации , т.е. совокупность отчетов, также заслужила отдельного упоминания. Одним словом, представленный отрывок показывает, что разработка Технического задания в соответствии с ГОСТ 34.602-89 - непростая и очень трудоемкая работа, накладывающая серьезные обязательства не только на разработчика, но и на заказчика системы. Потенциал стандарта чрезвычайно велик, и неудивительно, что популярность его остается неизменно высокой на протяжении стольких лет.

С течением времени стали видны и оборотные стороны стандарта:

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

Стоит подчеркнуть, что, как и ГОСТ 34.601-90, ГОСТ 34.602-89 не требует специальной подготовки в области информационных технологий, поэтому контролировать соответствие ему Технического задания может обычный управленец, в задачу которого входит, например, взаимодействие с субподрядчиками. Это упрощает внедрение и практическое применение стандарта.

Другое интересное явление, которое продемонстрировала практика, состоит в том, что, как оказалось, далеко не каждый ИТ-специалист способен разработать Техническое задание , удовлетворяющее требованиям стандарта. Фактически появление ГОСТ 34.602-89 стимулировало возникновение новых специалистов - бизнес-аналитиков и консультантов в сфере информационных технологий, основной работой которых стали разработка и согласование Технических заданий с заказчиками автоматизированных систем.

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

На этапе 1.1. "Обследование объекта и обоснование необходимости создания АС" проводят: сбор данных об объекте автоматизации и осуществляемых видах деятельности; оценку качества функционирования объекта и осуществляемых видах деятельности, выявление проблем, решение которых возможно средствами автоматизации; оценку целесообразности создания АС.

На этапе 1.2. "Формирование требований пользователя к АС" проводят: подготовку исходных данных для формирования требований АС; формулировку и оформление требований пользователя к АС.

На этапе 1.3. "Оформление отчёта о выполненной работе и заявки на разработку АС" проводят оформление отчета о выполненных работах на данной стадии и оформление заявки на разработку АС.

На этапах 2.1. "Изучение объекта" и 2.2. "Проведение научно-исследовательских работ" разработчик проводит детальное изучение объекта автоматизации и необходимые научно-исследовательские работы (НИР), связанные с поиском путей и оценкой возможности реализации требований пользователя, оформляют и утверждают отчёты о НИР.

На этапе 2.3. "Разработка и выбор вариантов концепции АС" проводят разработку альтернативных вариантов создаваемой АС и планов их реализации; оценку необходимых ресурсов; оценку преимуществ и недостатков каждого варианта; определение порядка оценки качества и условий приёмки системы; оценку эффектов, получаемых от системы.

На этапе 2.4. "Оформление отчёта о выполненной работе" подготавливают и оформляют отчет, содержащий описание выполненных работ.

На этапе 3.1. "Разработка и утверждение ТЗ на создание АС" проводят разработку, оформление, согласование и утверждение ТЗ.

На этапе 4.1. "Разработка предварительных проектных решений по системе и её частям" определяются: функции АС; функции подсистем, их цели и эффекты; задачи; концепция инфо базы, её структура; функции системы управления базой данных; состав вычислительной системы; функции и параметры программных средств.

На этапе 5.1. "Разработка проектных решений по системе и её частям" обеспечивает разработку общих решений по системе и её частям, по функциям персонала, по структуре технических средств, по алгоритмам решения задач, по организации и ведению инфо базы, по программному обеспечению.

На этапах 4.2. и 5.2. "Разработка документации на АС и её части" проводят разработку, оформление, согласование и утверждение документации.

На этапе 5.3. "Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку" проводят: подготовку и оформление документации на поставку изделий для АС; определение технических требований и составление ТЗ на разработку изделий.

На этапе 5.4 "Разработка заданий на проектирование в смежных частях проекта объекта автоматизации" осуществляют разработку и утверждение заданий для проведения строительных, электротехнических и др. работ, связанных с созданием АС.

На этапе 6.1 "Разработка рабочей документации на систему и её части" осуществляют разработку рабочей документации, содержащей все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и её эксплуатации.

На этапе 6.2 "Разработка или адаптация программ" проводят разработку программ и программных средств системы, выбор и адаптацию приобретаемых программных средств.

На этапе 7.1 "Подготовка объекта автоматизации к вводу АС в действие" проводят работы по организационной подготовке объекта автоматизации к вводу АС в действие.

На этапе 7.2 "Подготовка персонала" проводят обучение персонала и проверку его способности обеспечить функционирование АС.

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

На этапе 7.4 "Строительно-монтажные работы" проводят: выполнение работ по строительству специализированных помещений для размещения технических средств и персонала АС; сооружение кабельных каналов; выполнение работ по монтажу технических средств и линий связи, их испытание.

На этапе 7.5 "Пусконаладочные работы" проводят: наладку технических и программных средств.

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

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

На этапе 7.8 "Проведение приёмочных испытаний" проводят: испытания на соответствие ТЗ; анализ результатов испытания АС и устранение недостатков; оформление акта о приёмке АС в постоянную эксплуатацию.

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

На этапе 8.2 "Послегарантийное обслуживание" осуществляют работы по: анализу функционирования системы; выявлению отклонений от проектных значений; установлению причин этих отклонений и их устранение; внесению изменений в документацию на АС.