27.10.2016 09:57:23

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

1. Разработка документации технического проекта на СИБ

Жизненный цикл системы информационной безопасности (далее - СИБ) в общем виде состоит из следующих этапов:

• анализ требований к СИБ;
• проектирование;
• реализация;
• внедрение;
• эксплуатация.

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

1.1. Зачем вообще разрабатывать документацию на СИБ

Ответ на этот вопрос следует рассматривать в двух плоскостях: в плоскости владельца информационных ресурсов (для защиты которых и создается СИБ) и в плоскости непосредственного разработчика СИБ.

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

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

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

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

Исполнитель в процессе разработки документации технического проекта получит следующие результаты:

• базу для перехода к следующим этапам построения СИБ, а именно стадиям рабочей документации и внедрения;
• понимание архитектуры, используемых технологий и средств, порядка построения системы;
• каким образом реализуются требования Заказчика (бизнес-требования) и нормативных документов в сфере информационной безопасности к системе.

1.2. Обзор подходов к разработке документации технического проекта

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

• многократно апробированный подход к созданию информационных систем;
• продуманные структура и наполнение документов;
• состав документов, достаточный для разработки и описания практически любой системы.

Для разработки документации стадии технического проекта (ТП) на СИБ используются государственные стандарты и руководящие документы серии 34:

• ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем». В данном стандарте указаны:
  • виды и наименование документов стадии ТП;
  • комплектность документации;
  • принятые обозначения документов;
  • правила обозначения СИБ и их частей.
• ГОСТ 34.003-90 «Термины и определения»;
• ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания». В стандарте указаны:
  • перечень этапов работ, проводимых на стадии ТП;
  • подробное описание работ, проводимых на стадии ТП;
  • перечень организаций, участвующих в создании СИБ;
• РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов». В данном руководящем документе указаны требования к содержанию документов стадии ТП.

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

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

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

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

• приказ ФСТЭК России от 18 февраля 2013 г. № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»;
• приказ ФСТЭК России от 11 февраля 2013 г. № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»
• приказ ФСТЭК России от 14 марта 2014 г. № 31 «Об утверждении требований к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды;
• методический документ «Меры защиты информации в государственных информационных системах», утвержден ФСТЭК России 11 февраля 2014 г.

Требования к защите информации ограниченного доступа и перечни защитных мер разнятся для ИС разных уровней/классов защищенности. В случае, если информация в организации не относится к защищаемой в соответствии с федеральными законами РФ (например, служебная тайна), то владелец данной информации может воспользоваться подходами, предлагаемыми в данных НПА для построения корпоративной СИБ.

Российские и зарубежные стандарты, описывающие различные подходы к способам реализации стадий жизненного цикла построения СИБ, в том числе стадии технического проекта:

• серия государственных стандартов ГОСТ Р ИСО/МЭК 2700X, идентичные международным стандартам ISO/IEC 2700X. Данные стандарты описывают процессный подход PDCA (Plan, Do, Check, Act) к реализации жизненного цикла системы менеджмента информационной безопасности, которая является неотъемлемой частью СИБ;
• NIST SP 800-64 – стандарт Национального Института Стандартов и Технологий США, описывающий жизненный цикл разработки информационных систем;
• NIST SP 800-37 – стандарт Национального Института Стандартов и Технологий США, являющийся руководством по интеграции управления рисками в жизненный цикл разработки информационных систем.

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

• общее описание (datasheet);
• руководство администратора (может входить руководство по локальному и централизованному управлению);
• руководство пользователя;
• руководство по быстрой установке и развертыванию (для аппаратного СЗИ);
• руководство оператора;
• руководство по развертыванию в виртуальной инфраструктуре (для программного СЗИ);

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

• руководства по архитектурам систем информационной безопасности, например: Defense-in-Depth, Cisco SAFE, Check Point SDP и прочие;
• лучшие практики в области информационной безопасности, например, доступные по данным ссылкам (https://www.sans.org/reading-room/whitepapers/bestprac/ , http://csrc.nist.gov/publications/nistpubs/800-14/800-14.pdf). Данные документы чаще всего представлены на английском языке, однако свои лучшие практики внедрения средств защиты есть у любого российского производителя СЗИ и по запросу их могут предоставить;
• руководства по безопасности для СЗИ и сред функционирования. В качестве примера можно привести раздел «Безопасность» на официальном портале компании Microsoft (https://technet.microsoft.com/ru-ru/library/dd637672.aspx).

1.3. Разработка технического проекта на СИБ в соответствии с ГОСТ 34

Разработка документов стадии технического проекта на СИБ осуществляется чаще всего интеграторами данных услуг и реализуется преимущественно в соответствии со следующим планом:

Определение перечня разрабатываемых документов – данные сведения указываются в техническом задании на СИБ. В некоторых случаях разработчик документов по согласованию с Заказчиком может расширить или сократить данный перечень, если возможность этого предусмотрена в ТЗ;

Разработка шаблонов документов стадии ТП – используется структура в соответствии с РД 50-34.698-90 и ГОСТ 2.106 (для некоторых документов), оформление в соответствии с ГОСТ 2.105-95;

Разработка сутевой части документов. Требования к системе устанавливаются в техническом задании на СИБ. В соответствии с данными требованиями определяется перечень защитных технических и организационных мер, необходимых к реализации в системе. Меры защиты могут быть определены в соответствующих НПА (в зависимости от типа защищаемой информации), корпоративных стандартах и политиках информационной безопасности, а также исходя из наличия актуальных угроз безопасности, выявленных на этапе разработки модели угроз организации. Основываясь на перечне мер защиты, разработчик СИБ осуществляет выбор соответствующих средств защиты информации и разрабатывает функциональную структуру системы информационной безопасности (подсистемы, компоненты). Далее в документах технического проекта описывается практическая реализация мер защиты на основе выбранных СЗИ или организационных мер в инфраструктуре организации.

Согласование разработанной документации и представленных в ней решений с Заказчиком системы.

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

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

По требованию Заказчика или в том случае, если СИБ является сложной многокомпонентной системой, дополнительно могут разрабатываться также следующие документы:

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

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

Ведомость технического проекта

Обозначение: ТП.

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

Пояснительная записка к техническому проекту

Обозначение: П2.

Данный документ является основным для стадии ТП и включает в себя описание архитектуры СИБ, технических и организационных мер, функций СИБ, комплексов программных и технических средств и прочего. Согласно стандарту состоит из четырех основных разделов:

• общие положения;
• описание процесса деятельности;
• основные технические решения;
• мероприятия по подготовке объекта автоматизации к вводу системы в действие.

Схема функциональной структуры

Обозначение: С2.

Данный документ описывает логическую структуру СИБ, а именно:

• логические подсистемы и компоненты, входящие в состав СИБ;
• функции, реализуемые средствами подсистем и компонентов;
• информационные связи между логическими элементами СИБ и типы сообщений при обмене.

Схема структурная комплекса технических средств

Обозначение: С1.

Данный документ включает в себя описание следующих элементов СИБ:

• технических средств в составе логических подсистем и компонентов СИБ;
• каналов связи и обмена между техническими средствами с указанием транспортных протоколов.

Схема организационной структуры

Обозначение: С0.

Данный документ описывает организационную структуру организации в части управления СИБ, а именно:

• подразделения и ответственных лиц организации, участвующих в функционировании СИБ;
• выполняемые функции и связи между подразделениями и ответственными лицами.

Ведомость покупных изделий

Обозначение: ВП.

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

Примечание. Здесь также стоит отметить, что руководящий документ РД 50-34.698-90 допускает дополнение любого документа стадии ТП (включение разделов и сведений, отличных от предложенных), объединение разделов, а также исключение некоторых отдельных разделов. Решения об этом принимаются разработчиком документов стадии ТП и основываются на особенностях создаваемой СИБ.

1.4. Правила разработки документации

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

Пояснительная записка к техническому проекту:

• разработка документа осуществляется в среде Microsoft Word, после окончания разработки рекомендуется для удобства конвертировать документ в формат PDF;
• термины и сокращения должны быть едиными в пределах всех разделов документа;
• рекомендуется избегать явных повторений и ненужного увеличения объема документа;
• технические решения необходимо описывать как можно более подробно с указанием:
  • архитектуры и используемых технологий;
  • мест размещения программных и технических средств в инфраструктуре организации;
  • используемых средств защиты информации с описанием их характеристик, реализуемых функций, сведений о сертификации;
  • основных настроек средств защиты информации в части механизмов защиты, адресации, маршрутизации, взаимодействия со смежными системами и средствами и прочего;
  • средств управления, методов доступа к ним и местах их установки;
  • схемы (структурная, функциональная, организационная):
    • разрабатывать схемы в среде Microsoft Visio;
    • после разработки вставлять схемы в документ при помощи диалога «Специальная вставка» в формате EMF (метафайл Windows);
    • разрабатывать отдельные схемы на систему, подсистемы и компоненты подсистем;
    • оформление схем делать однотипным, с использованием одинаковых элементов, сокращений, иконок, стилей текста и прочего.

1.5. Ресурсы, помогающие при разработке документации

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

Таблица. Ресурсы по техническому проектированию СИБ

Тип ресурса	Информация	Примеры ресурсов
Интернет-порталы федеральных органов исполнительной власти	Нормативные документы, методические рекомендации, реестры (в том числе сертифицированных СЗИ), базы данных (в том числе БД уязвимостей и угроз)	fstec.ru clsz.fsb.ru minsvyaz.ru/ru/
Интернет-порталы производителей СЗИ, дистрибьюторов решений в области ИБ	Описание решений по ИБ, эксплуатационная документация по СЗИ, аналитические материалы и статьи	securitycode.ru kaspersky.ru/ drweb.ru/ ptsecurity.ru/ infowatch.ru/ infotecs.ru/ cisco.com/c/ru_ru/index.html checkpoint.com altx-soft.ru
Специализированные ресурсы по ИБ	Сравнение решений по ИБ, обзорные статьи по решениям ИБ, тесты решений по ИБ, глубокие технические сведения о технологиях ИБ	anti-malware.ru bis-expert.ru safe.cnews.ru securitylab.ru/ vulners.com/ csrc.nist.gov itsecurity.com owasp.org sans.org

1.6. Примеры документов стадии технического проекта

Для понимания требований к содержанию документации стадии ТП далее представлены примеры наполнения основных документов (разделов документов).

1.6.1. Пояснительная записка к техническому проекту

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

Подсистема анализа защищенности СИБ

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

Подсистема анализа защищенности (ПАЗ) предназначена для проведения систематического контроля состояния защищенности автоматизированных рабочих мест (АРМ) персонала и серверов организации. Основой ПАЗ являются программное средство «Test» производства компании ООО «Информационная безопасность». СЗИ Test имеет сертификат ФСТЭК России на соответствие техническим условиям (ТУ) по безопасности информации и по 4-му уровню контроля отсутствия недекларированных возможностей.

В состав ПАЗ входят следующие компоненты:

• сервер управления Test Server;
• консоль управления Test Console.

Описание компонентов подсистемы представлено в таблице ниже.

Таблица. Компоненты ПАЗ

Компонент	Описание
Сервер управления Test Server	Обеспечивает управление задачами сканирования, выполняет функции контроля состояния защищенности АРМ и серверов организации. Параметры сканирования задаются администратором ИБ на сервере управления Test Server. Вся собранная информация о результатах сканирования сохраняется в хранилище сервера Test Server на базе системы управления базами данных Microsoft SQL Server 2008
Консоль управления Test Console	Позволяет администратору ИБ подключаться к серверу Test Server, просматривать и изменять его конфигурацию, создавать и модифицировать задачи на проведение сканирований, просматривать информацию о ходе выполнения задач и результаты их выполнения. Консоль управления устанавливается на АРМ администратора ИБ

Обеспечение функций

ПАЗ обеспечивает выполнение следующих функций:

• реализация проактивной защиты АРМ и серверов организации с помощью мониторинга состояния ИБ;
• автоматизация процессов контроля соответствия внутренним политикам и определенным стандартам безопасности;
• снижение затрат на аудит и контроль защищенности, подготовку отчетов по состоянию;
• автоматизация процессов инвентаризации ресурсов, управления уязвимостями, контроля соответствия политикам безопасности и контроля изменений.

Решение по комплексу технических и программных средств

Перечень используемого программно-технического обеспечения ПАЗ приведен в таблице ниже.

Таблица. Программно-технические средства ПАЗ

Сервер управления ПАЗ

Технические средства

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

Таблица. Требования к ОС и ПО сервера управления ПАЗ

Программное обеспечение	Технические требования
	CPU	RAM, МБ
Microsoft Windows Server 2008 R2	3000 МГц, 4 ядра	8192
Microsoft SQL Server 2008 R2
ПО Test Server

Программные средства

ОС сервера управления

Установка ОС Windows 2008 R2 на сервер управления производится штатным образом с загрузочного дистрибутива.

Управление ОС сервера управления осуществляется как локально с консоли, так и по протоколу RDP.

СУБД сервера управления

Установка БД Microsoft SQL Server 2008 R2 осуществляется под учетной записью с правами локального администратора посредством стандартного мастера установки из дистрибутива, поставляемого разработчиком продукта.

ПО Test Server

Установка ПО Test Server на сервер управления осуществляется с помощью стандартного мастера установки.

Первоначальная настройка и последующее управление ПО Test Server в штатном режиме осуществляются с помощью консоли управления Test Console, установленной на АРМ администратора ИБ.

АРМ администратора ИБ

Технические средства

В качестве платформы используется существующий АРМ сотрудника подразделения организации, ответственного за обеспечение ИБ, под управлением ОС семейства Microsoft Windows.

Технические средства АРМ администратора ИБ должны обладать следующими характеристиками аппаратной конфигурации (рекомендуется не менее):

• CPU 2 ГГц;
• RAM 4 ГБ;
• HDD 80 ГБ.

Программные средства

ПО Test Console

АРМ администратора ИБ, на которое выполняется установка ПО Test Console, должно функционировать под управлением одной из следующих ОС:

• Microsoft Windows 7, 32- и 64-битные;
• Microsoft Windows 8/8.1, 32- и 64-битные.

Кроме того, для корректной работы ПО консоли управления Test Console на АРМ администратора ИБ должно быть установлено ПО Microsoft .NET Framework версии 3.5 SP1 или выше, а настройки безопасности используемой ОС должны разрешать доступ к серверу Test Server.

Установка ПО Test Console на АРМ администратора ПАЗ осуществляется с помощью стандартного мастера установки ПО Test Server с выбранной опцией установки консоли управления Test Console и прочими настройками по умолчанию.

Взаимодействие со смежными системами

Для ПАЗ смежными являются:

• средства подсистемы межсетевого экранирования;
• службы каталога Active Directory;
• АРМ и серверы организации.

Для обеспечения сетевого взаимодействия со смежными системами и непосредственно между самими компонентами ПАЗ должно быть организовано прохождение необходимого сетевого трафика.

Для обеспечения возможности получения обновлений базы знаний и модулей ПО Test для сканера Test Server необходимо обеспечить доступ к веб-серверу обновлений компании ООО «Информационная безопасность» update.com по порту 443/tcp.

При сканировании в режиме PenTest взаимодействие сканера Test Server и АРМ и серверов организации осуществляется по протоколу IP. При сканировании в режиме Audit и Compliance используются протоколы удаленного управления WMI, RPC и т. п. Для сканирования узлов на устройствах с функциями межсетевого экрана необходимо разрешить соединения от сервера Test Server к сканируемым узлам по протоколу IP. Соответственно, для сервера Test Server необходимо обеспечить доступ к сетевым портам сканируемых узлов по соответствующим протоколам удаленного управления.

Поскольку ПАЗ при сканировании в режимах Audit и Compliance использует для анализа протоколы удаленного управления, то средства сканирования ПО Test должны проходить аутентификацию и авторизацию на сканируемом узле. В ПАЗ для сканирования узлов в режимах Audit и Compliance в каждом из типов узлов (АРМ, сервер, прикладные системы, СУБД и т. п.) используются учетные записи c административными привилегиями.

Все регистрируемые события информационной безопасности хранятся в СУБД Microsoft SQL. Данные события посредством специальных коннекторов могут отправляться в подсистему мониторинга событий ИБ.

Эксплуатация и обслуживание ПАЗ

Пользователи подсистемы

Эксплуатация и обслуживание средств ПАЗ осуществляется сотрудниками организации с функциональной ролью «администратор ИБ».

Под администратором ИБ понимается специалист, в задачи которого входит:

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

Режимы эксплуатации системы

Штатный режим эксплуатации

В штатном режиме эксплуатации ПАЗ функционирует 24 часа в сутки 7 дней в неделю.

В штатном режиме работы администратор ИБ выполняет:

• плановое и внеплановое сканирования узлов;
• генерацию отчетов;
• обновление баз знаний и модулей ПО Test.

Аварийный режим эксплуатации

При нарушении работоспособности средств ПАЗ функционирование подсистемы нарушается. Нарушение работоспособности средств ПАЗ не влияет на функционирование АРМ и серверов организации.

1.6.2. Схема функциональной структуры

Функциональные схемы могут разрабатываться для всей СИБ или для ее части, например, подсистемы или компонента.

Пример общей функциональной схемы СИБ представлен на рисунке ниже.

1.6.3. Схема структурная комплекса технических средств

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

Пример структурной схемы комплекса технических средств СИБ представлен на рисунке ниже.

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

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

В серии 34, о которой идет речь, существует всего 3 основных стандарта по документированию:

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

Это базовый документ, в котором приводится полный перечень документации ГОСТ 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, то хорошо видно это деление (колонки «Стадия создания» и «Часть проекта»

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

Стадии создания определены в ГОСТ 34.601-90. Имеют отношение к документированию из них три:

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

Эскизный проект следует после стадии Техническое задание и служит для разработки предварительных проектных решений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Название документа:
Номер документа:	1.16-78
Вид документа:	ГОСТ
Принявший орган:	Госстандарт СССР
Статус:	Недействующий
Опубликован:
Дата принятия:	30 ноября 1978
Дата начала действия:	01 июля 1979
Дата окончания действия:	01 января 1987
Дата редакции:	01 января 1983

ГОСТ 1.16-78

Группа Т50

ГОСУДАРСТВЕННЫЙ СТАНДАРТ СОЮЗА ССР

ГОСУДАРСТВЕННАЯ СИСТЕМА СТАНДАРТИЗАЦИИ

Пояснительная записка к проекту стандарта. Построение, содержание, изложение и оформление

State system of standardization. Explanatory note to draft standard. Lay-out, contents, wording and formal presentation

Дата введения 1979-07-01

Постановлением Государственного комитета СССР по стандартам от 30 ноября 1978 г. N 3205 срок введения установлен с 01.07.79

ПЕРЕИЗДАНИЕ с Изменением N 1, утвержденным в ноябре 1981 г. (ИУС 3-82)


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

1. ОБЩИЕ ПОЛОЖЕНИЯ

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Пояснительную записку к проекту стандарта составляют к каждой редакции проекта, рассылаемой на отзыв, направляемой на согласование и представляемой на утверждение.

1.2. Пояснительную записку к проекту стандарта должна составлять организация (предприятие)-разработчик стандарта.

При наличии нескольких разработчиков пояснительную записку к проекту стандарта составляет ведущая организация (предприятие)-разработчик.

1.3. На каждый разрабатываемый стандарт составляют самостоятельную пояснительную записку.

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

2. ТРЕБОВАНИЯ К ПОСТРОЕНИЮ, СОДЕРЖАНИЮ И ИЗЛОЖЕНИЮ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ

2.1. В наименовании пояснительной записки указывают категорию и полное наименование стандарта, порядковый номер редакции проекта стандарта и (или) сведения о стадии разработки стандарта.

Например:

Пояснительная записка

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

Пояснительная записка

к проекту государственного стандарта "Приборы картографические. Термины и определения" (окончательная редакция, представляемая на утверждение)

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

При необходимости пояснительную записку можно разбить на подразделы, пункты и подпункты по требованиям, установленным в ГОСТ 1.5-68 * для стандартов.
________________
* На территории Российской Федерации документ не действует. Заменен на ГОСТ 1.5-85 (отменен без замены), здесь и далее по тексту

2.3. Пояснительная записка должна состоять из разделов, располагаемых в следующей последовательности:

основание для разработки стандарта;

цели и задачи разработки стандарта;

данные о стандартизации объекта к началу разработки проекта стандарта;

характеристика объекта стандартизации;

научно-технический уровень объекта стандартизации;

технико-экономическая эффективность от внедрения стандарта;

предполагаемый срок введения стандарта в действие и предполагаемый срок его действия;

взаимосвязь с другими стандартами;

сведения о рассылке на отзыв (ко всем редакциям проекта стандарта, кроме первой);

сведения о согласовании (только к окончательной редакции проекта стандарта, представляемой на утверждение);

источники информации;

дополнительные сведения.

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

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

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

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

Следует указать также, в соответствии с какой программой комплексной стандартизации, при ее наличии, разрабатывают стандарт.

2.6. В разделе "Цели и задачи разработки стандарта" следует указать конечные результаты, достижение которых будет обеспечено применением стандарта, и задачи, которые будут решены при разработке стандарта.

2.7. В разделе "Данные о стандартизации объекта к началу разработки проекта стандарта" указывают сведения о том, что стандарт разрабатывается впервые, или сведения о действующих стандартах, технических условиях, инструкциях, других документах, действующих к началу разработки проекта стандарта по данному объекту стандартизации.

2.8. В разделе "Характеристика объекта стандартизации" в зависимости от стандартизуемого объекта (продукция, показатели, нормы, характеристики, требования организационно-методического и общетехнического характера), категории и вида стандарта указывают основные показатели, нормы, характеристики, требования проекта стандарта, определяющие научно-технический уровень объекта стандартизации, и их технико-экономическое обоснование.

Основными показателями, нормами, характеристиками, требованиями проекта стандарта могут быть требования основных направлений развития народного хозяйства СССР, показатели планов стандартизации и технических заданий на разработку стандартов и показатели использования материальных ресурсов.

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

2.9. В разделе "Научно-технический уровень объекта стандартизации" приводят сравнительный анализ показателей, норм, характеристик, требований, предусмотренных проектом стандарта;

с показателями, нормами, характеристиками, требованиями стандартов (рекомендаций) СЭВ, ИСО, МЭК, других международных организаций;

с показателями, нормами, характеристиками, требованиями отечественных и иностранных стандартов;

с лучшими образцами техники и товарами отечественного производства и зарубежных фирм;

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

В этом разделе следует отразить соответствие показателей, норм, характеристик, требований проекта стандарта:

задачам, определенным в основных направлениях развития народного хозяйства СССР;

комплексным научно-техническим программам, включающим объект стандартизации;

комплексным программам стандартизации.

В этом разделе на основе вышеуказанных данных дают общий вывод о научно-техническом уровне показателей, норм, характеристик, требований объекта стандартизации.

Если с окончательной редакцией проекта стандарта, представляемой на утверждение, отдельно направляют таблицы сравнения показателей или карту технического уровня и качества продукции по ГОСТ 2.116-71*, то в пояснительной записке к этой редакции указывают только результаты сравнительного анализа и дают общий вывод о научно-техническом уровне показателей, норм, характеристик, требований объекта стандартизации.
________________
ГОСТ 2.116-84 . - Примечание изготовителя базы данных.

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

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

2.11. В разделе "Предполагаемый срок введения стандарта в действие и предполагаемый срок его действия" следует привести:

обоснование предполагаемого срока введения стандарта в действие с учетом времени, необходимого на выполнение мероприятий по внедрению стандарта;

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

обоснование утверждения проекта стандарта без ограничения срока действия или обоснование предполагаемого срока действия стандарта.

2.12. В разделе "Взаимосвязь с другими стандартами" следует указать:

принадлежность проекта стандарта к комплексу стандартов, входящих в систему;

данные о взаимосвязи проекта стандарта с другими стандартами, а также стандартами и рекомендациями СЭВ и других международных организаций;

обоснованные предложения о необходимости пересмотра, разработки изменений или отмены действующих взаимосвязанных стандартов.

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

2.13. В разделе "Сведения о рассылке на отзыв" следует указать:

количество организаций (предприятий), которым рассылали редакцию проекта стандарта;

количество организаций (предприятий), приславших отзывы;

краткую обобщенную характеристику отзывов;

результаты рассмотрения отзывов.

2.14. В разделе "Сведения о согласовании" следует привести сведения о проведении согласования проекта стандарта с заинтересованными организациями (предприятиями); о проведении согласительных совещаний; дать краткую характеристику рассмотренных на них вопросов; указать разногласия, оставшиеся при разработке проекта стандарта.

Если проект стандарта согласовывать не требуется, то в пояснительной записке следует указать, что стандарт согласованию не подлежит.

2.15. В разделе "Источники информации" следует указать источники информации, использованные при разработке проекта стандарта, в том числе:

нормативные акты действующего законодательства;

нормативные акты министерств, ведомств, объединений и предприятий;

отечественные стандарты и технические условия (их обозначения);

иностранные и международные стандарты и другие документы международных организаций (их обозначения и наименования);

отчеты о патентных исследованиях;

отчеты о законченных научно-исследовательских и опытно-конструкторских работах и другие.

2.16. В разделе "Дополнительные сведения", при необходимости, можно включить:

варианты решения некоторых вопросов и (или) отдельные вопросы по проекту стандарта с просьбой к организациям (предприятиям), которым рассылают на отзыв проект стандарта, высказать свое мнение;

и другие вопросы.

2.17. Пояснительную записку следует излагать в соответствии с требованиями, установленными в ГОСТ 1.5-68 , разд.1, для стандартов.

3. ТРЕБОВАНИЯ К ОФОРМЛЕНИЮ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ

3.1. Пояснительную записку к проекту стандарта следует печатать в соответствии с требованиями ГОСТ 6.38-72*.
________________
* На территории Российской Федерации документ не действует. Действует ГОСТ Р 6.30-2003 . - Примечание изготовителя базы данных.

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

Пояснительная записка к проекту стандарта предприятия должна быть подписана руководителем отдела (подразделения)-разработчика, руководителем разработки (темы) и исполнителями.

Подписи располагают на последней странице пояснительной записки к проекту стандарта.

3.3. Пояснительная записка к проекту стандарта должна иметь самостоятельную нумерацию страниц и не содержать обложки.

Электронный текст документа
подготовлен АО "Кодекс" и сверен по:
официальное издание
Государственная система
стандартизации: Сборник ГОСТов. -
М.: Издательство стандартов, 1983

ГОСТ 1.16-78 ГСС. Пояснительная записка к проекту стандарта. Построение, содержание, изложение и оформление (с Изменением N 1)

Название документа:	ГОСТ 1.16-78 ГСС. Пояснительная записка к проекту стандарта. Построение, содержание, изложение и оформление (с Изменением N 1)
Номер документа:	1.16-78
Вид документа:	ГОСТ
Принявший орган:	Госстандарт СССР
Статус:	Недействующий
Опубликован:	Официальное издание. Государственная система стандартизации: Сборник ГОСТов. - М.: Издательство стандартов, 1983 год
Дата принятия:	30 ноября 1978
Дата начала действия:	01 июля 1979
Дата окончания действия:	01 января 1987
Дата редакции:	01 января 1983

Как правило, Пояснительная записка бывает самым сложным документом на ПО, подчас вызывая множество споров и дискуссий вокруг своего содержания. Почему так случается?

Назначение пояснительной записки

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

Состав типовой пояснительной записки

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

– Введение . В этом разделе приводится полное наименование системы и тема разработки, а также список документов, послуживших основанием для работ по проекту.

– Назначение и область применения . Здесь описываются цели и задачи, которые будут решены с помощью системы, а также сфера ее использования.

– Технические характеристики . Этот раздел обычно разбивают на подразделы, в которых описывают: постановку задачи на создание программы; используемый математический аппарат; алгоритм работы ПО; структуру входных и выходных данных; состав технических и программных средств. Также необходимо приводить расчеты и результаты анализа для обоснования выбора именно тех решений, о которых говорится в документе.

– Ожидаемые технико-экономические показатели . Раздел предполагает экономическое обоснование разработки с учетом ее технических показателей.

– Источники, использованные при разработке . Раздел представляет собой список документов, статей и публикаций, на которые были приведены ссылки в тексте.

Стандарты для пояснительной записки

Состав разделов определяется ГОСТом 19.404, однако, стандарт позволяет эти разделы при необходимости объединять, а также добавлять новые. В случае использования ГОСТ серии 34 следует разрабатывать документ в соответствии с РД 50-34.698. Тем не менее, документ должен оставаться в рамках требований общих стандартов, таких, например, как ГОСТ 19.105.

Стоимость разработки пояснительной записки

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

– с одной стороны, внятно и доходчиво представляет все нужные (а порой и нудные) сведения, включая сложные технические подробности;

ГОСТ 19.404-79

Группа Т55

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Единая система программной документации

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

Требования к содержанию и оформлению

Unified system for program documentation. Explanatory note. Requirements for contents and form of presentation

Дата введения 1981-01-01

Постановлением Государственного комитета CCCР по стандартам от 11 декабря 1979 г. N 4753 дата введения установлена 01.01.81

ПЕРЕИЗДАНИЕ. Январь 2010 г.


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

1. ОБЩИЕ ПОЛОЖЕНИЯ

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Структура и оформление документа устанавливаются в соответствии с ГОСТ 19.105-78 .

Составление информационной части (аннотации и содержания) является необязательным.

1.2. Пояснительная записка должна содержать следующие разделы:

введение;

назначение и область применения;

технические характеристики;

ожидаемые технико-экономические показатели;

источники, использованные при разработке.

В зависимости от особенностей документа отдельные разделы (подразделы) допускается объединять, а также вводить новые разделы (подразделы).

2.1. В разделе "Введение" указывают наименование программы и (или) условное обозначение темы разработки, а также документы, на основании которых ведется разработка, с указанием организации и даты утверждения.

2.2. В разделе "Назначение и область применения" указывают назначение программы, краткую характеристику области применения программы.

2.3. Раздел "Технические характеристики" должен содержать следующие подразделы:

постановка задачи на разработку программы, описание применяемых математических методов и, при необходимости, описание допущений и ограничений, связанных с выбранным математическим аппаратом;

описание алгоритма и (или) функционирования программы с обоснованием выбора схемы алгоритма решения задачи, возможные взаимодействия программы с другими программами;

описание и обоснование выбора метода организации входных и выходных данных;

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

2.4. В разделе "Ожидаемые технико-экономические показатели" указывают технико-экономические показатели, обосновывающие преимущество выбранного варианта технического решения, а также, при необходимости, ожидаемые оперативные показатели.

2.5. В разделе "Источники, использованные при разработке" указывают перечень научно-технических публикаций, нормативно-технических документов и других научно-технических материалов, на которые есть ссылки в основном тексте.

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



Электронный текст документа
подготовлен ЗАО "Кодекс" и сверен по:
официальное издание
Единая система программной документации:
Сб. ГОСТов. -
М.: Стандартинформ, 2010