Главная » Аллергия » Программно информационный комплекс определение по гост. Требования к информационному обеспечения АСУ. Требования к асу

Программно информационный комплекс определение по гост. Требования к информационному обеспечения АСУ. Требования к асу

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

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

В серии 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

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

Заключение

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

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

ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.

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

Дата введения
с 01.01.1992г.

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

Стандарт устанавливает стадии и этапы создания АС. В приложении 1 приведено содержание работ на каждом этапе.

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

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

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

1.3. Работы по развитию АС осуществляют по стадиям и этапам, применяемым для создания АС.

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

Перечень организаций, участвующих в работах по созданию АС, приведён в приложении 2.

2. СТАДИИ И ЭТАПЫ СОЗДАНИЯ АС

2.1. Стадии и этапы создания АС в общем случае приведены в таблице.

	Этапы работ
1. Формирование требований к АС	1.1. Обследование объекта и обоснование необходимости создания АС. 1.2. Формирование требований пользователя к АС. 1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС.	2.1. Изучение объекта. 2.2. Проведение необходимых научно-исследовательских работ. 2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя. 2.4. Оформление отчёта о выполненной работе.
3. Техническое задание.	Разработка и утверждение технического задания на создание АС.
4. Эскизный проект.	4.1. Разработка предварительных проектных решений по системе и её частям. 4.2. Разработка документации на АС и её части.
5. Технический проект.	5.1. Разработка проектных решений по системе и её частям. 5.2. Разработка документации на АС и её части. 5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку. 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.
6. Рабочая документация.	6.1. Разработка рабочей документации на систему и её части. 6.2. Разработка или адаптация программ.
7. Ввод в действие.	7.1. Подготовка объекта автоматизации к вводу АС в действие. 7.2. Подготовка персонала. 7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями). 7.4. Строительно-монтажные работы. 7.5. Пусконаладочные работы. 7.6. Проведение предварительных испытаний. 7.7. Проведение опытной эксплуатации. 7.8. Проведение приёмочных испытаний.
8. Сопровождение АС	8.1. Выполнение работ в соответствии с гарантийными обязательствами. 8.2. Послегарантийное обслуживание.

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

Допускается исключить стадию "Эскизный проект" и отдельные этапы работ на всех стадиях, объединять стадии "Технический проект" и "Рабочая документация" в одну стадию "Технорабочий проект". В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.

ПРИЛОЖЕНИЕ 1
(справочное)

1. На этапе 1.1. "Обследование объекта и обоснование необходимости создания в АС" общем случае проводят:

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

2. На этапе 1.2. "Формирование требований пользователя к АС" проводят:

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

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

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

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

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

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

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

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

10. На этапах 4.2. и 5.2. "Разработка документации на АС и её части" проводят разработку, оформление, согласование и утверждение документации в объёме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию АС. Виды документов - по ГОСТ 34.201-89 .

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

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

13. На этапе 6.1 "Разработка рабочей документации на систему и её части" осуществляют разработку рабочей документации, содержащей все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и её эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями, её оформление, согласование и утверждение. Виды документов по ГОСТ 34.201-89 .

14. На этапе 6.2 "Разработка или адаптация программ" проводят разработку программ и программных средств системы, выбор, адаптацию и (или) привязку приобретаемых программных средств, разработку программной документации в соответствии с ГОСТ 19.101 .

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

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

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

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

18. На этапе 7.4 "Строительно-монтажные работы" проводят:

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

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

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

20. На этапе 7.6 "Проведение предварительных испытаний" осуществляют:

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

21. На этапе 7.7 "Проведение опытной эксплуатации" проводят:

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

22. На этапе 7.8 "Проведение приёмочных испытаний" проводят:

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

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

24. На этапе 8.2 "Послегарантийное обслуживание" осуществляют работы по:

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

ПРИЛОЖЕНИЕ 2
(справочное)

ПЕРЕЧЕНЬ ОРГАНИЗАЦИЙ, УЧАСТВУЮЩИХ В РАБОТАХ ПО СОЗДАНИЮ АС.

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

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

3. Организация-поставщик, которая изготавливает и поставляет программные и технические средства по заказу разработчика или заказчика.

4. Организация-генпроектировщик объекта автоматизации.

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

6. Организации строительные, монтажные, наладочные и другие.

Примечания:

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

Дата введения 01.01.92

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

Стандарт устанавливает стадии и этапы создания АС. В приложении 1 приведено содержание работ на каждом этапе.

1. Общие положения

2. Стадии и этапы создания АС

Приложение 1 (справочное)

Приложение 2 (справочное)

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

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

1.3. Работы по развитию АС осуществляют по стадиям и этапам, применяемым для создания АС.

Перечень организаций, участвующих в работах по созданию АС, приведен в приложении 2.

2. СТАДИИ И ЭТАПЫ СОЗДАНИЯ АС

2.1. Стадии и этапы создания АС в общем случае приведены в таблице.

Стадии	Этапы работ
1. Формирование требований к АС	1.1. Обследование объекта и обоснование необходимости создания АС
	1.2. Формирование требований пользователя к АС
	1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС	2.1. Изучение объекта
	2.2. Проведение необходимых научно-исследовательских работ
	2.3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетво-ряющего требованиям пользователя
	2.4. Оформление отчета о выполненной работе
3. Техническое задание	3.1. Разработка и утверждение технического задания на создание АС
4. Эскизный проект	4.1. Разработка предварительных проектных решений по системе и ее частям
4. Эскизный проект	4.2. Разработка документации на АС и ее части
5. Технический проект	5.1. Разработка проектных решений по системе и ее частям
	5.2. Разработка документации на АС и ее части
	5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку
	5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации
6. Рабочая документация	6.1. Разработка рабочей документации на систему и ее части
6. Рабочая документация	6.2. Разработка или адаптация программ
7. Ввод а действие	7.1. Подготовка объекта автоматизации к вводу АС в действие
	7.2. Подготовка персонала
	7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
	7.4. Строительно-монтажные работы
	7.5. Пусконаладочные работы
	7.6. Проведение предварительных испытаний
	7.7. Проведение опытной эксплуатации
	7.8. Проведение приемочных испытаний
8. Сопровождение АС	8.1. Выполнение работ в соответствии с гарантийными обязательствами
8. Сопровождение АС	8.2. Послегарантийное обслуживание

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

Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в одну стадию «Технорабочий проект». В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.

ПРИЛОЖЕНИЕ 1.Справочное

1. На этапе 1.1 «Обследование объекта и обоснование необходимости создания АС» в общем случае проводят:

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

2. На этапе 1.2 «формирование требований пользователя к АС» проводят:

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

3. На этапе 1.3 «Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)» проводят оформление отчета о выполненных работах на данной стадии и оформление заявки на разработку АС (тактико-технического задания) или другого заменяющего ее документа с аналогичным содержанием.

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

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

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

7. На этапе 3.1 «Разработка и утверждение технического задания на создание АС» проводят разработку, оформление, согласование и утверждение технического задания на АС и, при необходимости, технических заданий на части АС.

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

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

10. На этапах 4.2 и 5.2 «Разработка- документации на АС и ее части» проводят разработку, оформление, согласование и утверждение документации в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию АС. Виды документов - по ГОСТ 34.201.

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

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

13. На этапе 6.1 «Разработка рабочей документации на систему и ее части» осуществляют разработку рабочей документации, содержащей все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и ее эксплуатации, а также для поддерживания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями, ее оформление, согласование и утверждение. Виды документов - по ГОСТ 34.201.

14. На этапе 6.2 «Разработка или адаптация программ» проводят разработку программ и программных средств системы, выбор, адаптацию и (или) привязку приобретаемых программных средств, разработку программной документации в соответствии с ГОСТ 19.101.

15. На этапе 7.1 «Подготовка объекта автоматизации к вводу АС в действие» проводят работы по организационной подготовке объекта автоматизации к вводу АС в действие, в т. ч.: реализацию проектных решений по организационной структуре АС; обеспечение подразделений объекта управления инструктивно-методическими материалами; внедрение классификаторов информации.

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

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

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

19. На этапе 7.5 «Пусконаладочные работы» проводят автономную наладку технических и программных средств, загрузку информации в базу данных и проверку системы ее ведения; комплексную наладку всех средств системы.

20. На этапе 7.6 «Проведение предварительных испытаний» осуществляют:

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

21. На этапе 7.7 «Проведение опытной эксплуатации» проводят, опытную эксплуатацию АС; анализ результатов опытной эксплуатации АС; доработку (при необходимости) программного обеспечения АС; дополнительную наладку (при необходимости) технических средств АС; оформление акта о завершении опытной эксплуатации.

22. На этапе 7.8 «Проведение приемочных испытаний» проводят:

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

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

24. На этапе 8.2 «Послегарантийное обслуживание» осуществляют работы по:

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

ПРИЛОЖЕНИЕ 2. Справочное

ПЕРЕЧЕНЬ ОРГАНИЗАЦИЙ, УЧАСТВУЮЩИХ В РАБОТАХ ПО СОЗДАНИЮ АС

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

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

4. Организация-генпроектировщик объекта автоматизации.

6. Организации строительные, монтажные, наладочные и другие.

Примечания:

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

2. Стадии и этапы выполняемых ими работ по созданию АС определяются на основании настоящего стандарта.

ИНФОРМАЦИОННЫЕ ДАННЫЕ

1. РАЗРАБОТАН И ВНЕСЕН Государственным комитетом СССР по управлению качеством продукции и стандартам

РАЗРАБОТЧИКИ

Ю.Х. Вермишев, д-р техн. наук; Я.Г. Виленчик; В.И. Воропаев, д-р техн. наук; Л.М. Зайденберг, канд. техн. наук; Ю.Б. Ирз, канд. техн. наук; В.Д. Костюков, канд. техн. наук; М.А. Лабутин, конд. техн. наук; Н.П. Лесковская; И.С. Митяев; В.Ф. Попов (руководитель темы); С.В. Гаршина; А.И. Глуховеря; Ю.Г. Жуков, канд техн. наук; З.П. Задубовская; В.Г. Иванов; Ю.И. Караванов, канд техн. наук; А.А. Клочков; В.Ю. Королев; В.И. Махнач, канд. техн. наук; С.Б. Михалев, д-р техн. наук; В.Н. Петрикевич; В.А. Рахманов, канд. экон. наук; А.А. Ратъкович; Р.С. Седегов, д-р экон. наук; Н.В. Степанчикова; М.С. Суровец; А.В. Флегентов; Л.О. Хвилевский, канд. техн. наук; В.К. Чистов, канд. экон. наук

2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по управлению качеством продукции и стандартам от 29.12.90 № 3469

Введение

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

Какие бывают ГОСТы?

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

Международные стандарты (ISO, IEEE Std);
Российские или Советские ГОСТы.

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

IEEE Std 1063-2001 «IEEE Standard for Software User Documentation» - стандарт для написания руководства пользователя;
IEEE Std 1016-1998 «IEEE Recommended Practice for Software Design Descriptions» - стандарт для написания технического описания программы;
ISO/IEC FDIS 18019:2004 «Guidelines for the design and preparation of user documentation for application software» - ещё один стандарт для написания руководства пользователя. В данном документе есть большое количество примеров. Так сказать, это больше похоже на руководство по написанию руководства пользователя. Начинающим специалистам будет особенно полезен;
ISO/IEC 26514:2008 «Requirements for designers and developers of user documentation» - ещё один стандарт для дизайнеров и разработчиков пользователей документации.

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

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

Чем отличаются ГОСТы серий 19 и 34?

Первый вопрос, который возникает, а чем, вообще, эти ГОСТы 19 и 34 отличаются друг от друга.
В ГОСТе 19.781-90 «Единая система программной документации. Программное обеспечение систем обраб0отки информации. Термины и определения» указаны определения:

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

В ГОСТе 34.003-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения» указано определение:

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

В зависимости от вида управляемого объекта (процесса) АСУ делят, например, на: АСУ технологическими процессами (АСУТП), АСУ предприятиями (АСУП) и т.д.
Также ГОСТ 34 делает разделение на виды обеспечения АС:

Организационное;
Методическое;
Техническое;
Математическое;
Программное обеспечение;
Информационное;
Лингвистическое;
Правовое;
Эргономическое.

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

ГОСТ 34

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

ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем - данный стандарт устанавливает виды, наименование, комплектность и номера документов. Является одним из основных документов серии ГОСТов 34. По сути, это базовый документ, так что новичкам необходимо ознакомиться с ним в первую очередь.
ГОСТ 34.320-96 Концепции и терминология для концептуальной схемы и информационной базы - настоящий стандарт устанавливает основные понятия и термины концептуальных схем и информационных баз, охватывающие разработку, описание и применение концептуальных схем и информационных баз, манипулирования информацией, а также описание и реализацию информационного процесса. Стандарт определяет роль концептуальной схемы. Положения, изложенные в нём, носят рекомендательный характер и могут использоваться для оценки систем управления базами данных (СУБД). Этот документ не описывает конкретные методы применения средств поддержки концептуальных схем. Описанные в стандарте языки концептуальных схем не следует рассматривать как стандартные.
ГОСТ 34.321-96 Информационные технологии. Система стандартов по базам данных. Эталонная модель управления - данный документ устанавливает эталонную модель управления данными.
Эталонная модель определяет общую терминологию и понятия, относящиеся к данным информационных систем. Такие понятия используются для определения услуг, предоставляемых системами управления базами данных или системами словарей данных.
Эталонная модель не рассматривает протоколы для управления данными.
Область применения эталонной модели включает процессы, которые касаются управления постоянными данными и их взаимодействия с процессами, отличающимися от требований конкретной информационной системы, а также общие услуги управления данными, для определения, хранения, поиска, обновления, ввода, копирования, восстановления и передачи данных.
ГОСТ 34.601-90 Автоматизированные системы. Стадии создания - стандарт устанавливает стадии и этапы создания АС.
ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы (Взамен ГОСТ 24.201-85) - устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы».
Данный документ является одним из часто используемых документов серии ГОСТ 34. При разработке ТЗ по этому ГОСТу следует помнить и о других стандартах, даже если в этом документе нет ссылок на эти стандарты.
ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем - стандарт устанавливает виды испытаний АС автономные, комплексные, приёмочные испытаний и опытная эксплуатация) и общие требования к их проведению.
РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов - один из важнейших документов 34 ГОСТа, так как именно в нём описано содержание практически всех документов, а также описание каждого пункта документа.
ГОСТ Р ИСО/МЭК 8824-3-2002 Информационная технология. Абстрактная синтаксическая нотация версии один - настоящий стандарт является частью абстрактной синтаксической нотации версии 1 (АСН.1) и устанавливает нотацию для спецификации ограничений, определённых пользователем, и табличных ограничений.
ГОСТ Р ИСО/МЭК 10746-3-2001 Управление данными и открытая распределённая обработка.
В настоящем стандарте:
- определено, как специфицируются системы открытой распределённой обработки (ОРО) с использованием понятий, введённых в ГОСТ Р ИСО/МЭК 10746-2;
- идентифицированы характеристики, по которым системы относятся к системам ОРО.
В стандарте установлен каркас для координации разработки стандартов по системам ОРО.
ГОСТ Р ИСО/МЭК 15271-02 Процессы жизненного цикла программных средств - данный ГОСТ необходимо больше, на мой взгляд, для аналитиков при проектировании и моделировании АС.
Этот документ полезен, с моей точки зрения, в чисто образовательных целях.
ГОСТ Р ИСО/МЭК 15910-2002 Процесс создания документации пользователя программного средства - определяет минимально необходимый процесс создания документации пользователя всех видов для программного средства, имеющего интерфейс пользователя. Данные виды охватывают печатную документацию (например, руководства пользователя и краткие справочные карты), диалоговую (оперативную) документацию, справочный текст («хелпы») и системы диалоговой документации.

Итак, исходя из всего выше написанного, видно, что основных документов в 34 ГОСТе 3: ГОСТ 34.201-89, РД 50-34.698-90 и ГОСТ 34.602-89.
При разработке пакета документации, для начала, необходимо открыть ГОСТ 34.201-89 и выбрать стадию создания Эскизный проект, Технический проект и Рабочая документация. Далее, следует выбрать документы для разработки, которые соответствуют стадии создания.

Перечень документов 34 ГОСТа

Стадия создания	Наименование документа	Код	Часть проекта	Принад лежнос ть к проект но-смет ной доку мента ции	Принад лежнос ть к эксплуа тацион ной до кумен тации	Дополнительные указания
ЭП	Ведомость эскизного проекта	ЭП*	ОР	—	—	—
ЭП	Пояснительная записка К эскизному проекту	П1	ОР	—	—	—
ЭП, ТП	Схема организационной структуры	СО	ОР	—	—	Допускается включать в документ П3 или ПВ
	Схема структурная комплекса технических средств	С1*	ТО	Х	—
	Схема функциональной структуры	С2*	ОР	—	—	При разработке документов СО, С1, С2, С3 на стадии ЭП допускается их включать в документ П1
	специализированных (новых) технических средств	В9	ТО	Х	—	При разработке на стадии ТП допускается включать в документ П2
	Схема автоматизации	С3*	ТО	Х	—	—
	Технические задания на разработку специализированных (новых) технических средств	—	ТО	—	—	В состав проекта не входят
ТП	Задания на разработку санитарно-технических и других разделов проекта, связанных с созданием системы	—	ТО	Х	—	В состав проекта не входят
	Ведомость технического проекта	ТП*	ОР	—	—	—
	Ведомость покупных изделий	ВП*	ОР	—	—	—
	Перечень входных сигналов и данных	В1	ИО	—	—	—
	Перечень выходных сигналов (документов)	В2	ИО	—	—	—
	Перечень заданий на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, связанных с созданием системы	В3	ТО	Х	—	Допускается включать в документ П2
	Пояснительная записка к техническому проекту	П2	ОР	—	—	Включает план мероприятий по подготовке объекта к вводу системы в эксплуатацию
	Описание автоматизируемых функций	П3	ОР	—	—	—
	Описание постановки задач (комплекса задач)	П4	ОР	—	—	Допускается включать в документы П2 или П3
	Описание информационного обеспечения системы	П5	ИО	—	—	—
	Описание организации информационной базы	П6	ИО	—	—	—
ТП	Описание систем классификации и кодирования	П7	ИО	—	—	—
	Описание массива информации	П8	ИО	—	—	—
	Описание комплекса технических средств	П9	ТО	—	—	Для задачи допускается включать в документ 46 по ГОСТ 19.101
	Описание программного обеспечения	ПА	ПО	—	—	—
	Описание алгоритма (проектной процедуры)	ПБ	МО	—	—	Допускается включать в документы П2, П3 или П4
	Описание организационной структуры	ПВ	ОО	—	—	—
	План расположения	С8	ТО	Х	—	Допускается включать в документ П9
	Ведомость оборудования и материалов	—	ТО	Х	—	—
	Локальный сметный расчёт	Б2	ОР	Х	—	—
ТП, РД	Проектная оценка надёжности системы	Б1	ОР	—	—	—
ТП, РД	Чертёж формы документа (видеокадра)	С9	ИО	—	Х	На стадии ТП допускается включать в документы П4 или П5
РД	Ведомость держателей подлинников	ДП*	ОР	—	—	—
	Ведомость эксплуатационных документов	ЭД*	ОР	—	Х	—
	Спецификация оборудования	В4	ТО	Х	—	—
	Ведомость потребности в материалах	В5	ТО	Х	—	—
	Ведомость машинных носителей информации	ВМ*	ИО	—	Х	—
	Массив входных данных	В6	ИО	—	Х	—
РД	Каталог базы данных	В7	ИО	—	Х	—
	Состав выходных данных (сообщений)	В8	ИО	—	Х	—
	Локальная смета	Б3	ОР	Х	—	—
	Методика (технология) автоматизированного проектирования	И1	ОО	—	Х	—
	Технологическая инструкция	И2	ОО	—	Х	—
	Руководство пользователя	И3	ОО	—	Х	—
	Инструкция по формированию и ведению базы данных (набора данных)	И4	ИО	—	Х	—
	Инструкция по эксплуатации КТС	ИЭ	ТО	—	Х	—
	Схема соединений внешних проводок	С4*	ТО	Х	—	Допускается выполнять в виде таблиц
	Схема подключения внешних проводок	С5*	ТО	Х	—	То же
	Таблица соединений и подключений	С6	ТО	Х	—	—
	Схема деления системы (структурная)	Е1*	ТО	—	—	—
	Чертёж общего вида	ВО*	ТО	Х	—	—
	Чертёж установки технических средств	СА	ТО	Х	—	—
	Схема принципиальная	СБ	ТО	Х	—	—
	Схема структурная комплекса технических средств	С1*	ТО	Х	—	—
	План расположения оборудования и проводок	С7	ТО	Х	—	—
	Описание технологического процесса обработки данных (включая телеобработку)	ПГ	ОО	—	Х	—
	Общее описание системы	ПД	ОР	—	Х	—
	Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистемы, систем)	ПМ*	ОР	—	—	—
	Формуляр	ФО*	ОР	—	Х	—
	Паспорт	ПС*	ОР	—	Х	—
*Документы, код которых установлен в соответствии с требованиями стандартов ЕСКД

Примечание к таблице:

В таблице приняты следующие обозначения:
- ЭП — эскизный проект;
- ТП — технический проект;
- РД — рабочая документация;
- ОР — общесистемные решения;
- ОО — решения по организационному обеспечению;
- ТО — решения по техническому обеспечению;
- ИО — решения по информационному обеспечению;
- ПО — решения по программному обеспечению;
- МО — решения по математическому обеспечению.
Знак Х — обозначает принадлежность к проектно-сметной или эксплуатационной документации.
Номенклатуру документов одного наименования устанавливают в зависимости от принятых при создании системы проектных решений.

Когда перечень документов определён, то в РД 50-34.698-90 следует найти выбранные документы и разработать их строго по указанным пунктам. Все пункты содержания, которые указаны, обязательно должны быть в документе.
Если разрабатывается Техническое задание, то сразу нужно открыть ГОСТ 34.602-89 и разработать ТЗ строго согласно пунктам.

ГОСТ 19

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

1. ГОСТ 19.001-77 Общие положения - слишком общий документ, практической пользы он не несёт. Поэтому его можно пропустить.
2. ГОСТ 19781-90 Термины и определения - хороший список определений в области программного обеспечения систем обработки информации. Кроме как определений больше не содержит ничего.
3. ГОСТ 19.101-77 Виды программ и программных документов - один из главных документов 19 ГОСТа. Именно с него следует начинать работу с 19 ГОСТом, так как в нём содержится полный перечень и обозначения документов ГОСТа.

Перечень документов 19 ГОСТа

Код	Вид документа	Стадии разработки
		Эскизный проект	Технический проект	Рабочий проект
		Эскизный проект	Технический проект	компонент	комплекс
—	Спецификация	—	—
05	Ведомость держателей подлинников	—	—	—
12	Текст программы	—	—
13	Описание программы	—	—
20	Ведомость эксплуатационных документов	—	—
30	Формуляр	—	—
31	Описание применения	—	—
32	Руководство системного программиста	—	—
33	Руководство программиста	—	—
34	Руководство оператора	—	—
35	Описание языка	—	—
46	Руководство по техническому обслуживанию	—	—
51	Программа и методика испытаний	—	—
81	Пояснительная записка			—	—
90-99	Прочие документы

Условные обозначения:
— документ обязательный;
— документ обязательный для компонентов, имеющих самостоятельное применение;
— необходимость составления документа определяется на этапе разработки и утверждения технического задания;
- — документ не составляют.

ГОСТ 19.102-77 Стадии разработки - содержит описание стадий разработки. Полезен в образовательных целях. На мой взгляд, особой практической пользы не несёт.
ГОСТ 19.103-77 Обозначения программ и программных документов - содержит описание присвоения номера (кода) документу. Даже после прочтения этого ГОСТа остаётся куча вопросов о том, как же присвоить этот самый номер документу.
ГОСТ 19.104-78 Основные надписи - устанавливает формы, размеры, расположение и порядок заполнения основных надписей листа утверждения и титульного листа в программных документах, предусмотренных стандартами ЕСПД, независимо от способов их выполнения. Так как документы 19 ГОСТа оформляются в рамочках, то данный документ очень важен.
ГОСТ 19.105-78 Общие требования к программным документам - устанавливает общие требования к оформлению программных документов. Требования слишком общие. Как правило для разработки документа этот ГОСТ почти не применяется, так как хватает специального ГОСТа на документ, но для общих знаний в данный ГОСТ все же лучше заглянуть разок.
ГОСТ 19.106-78 Требования к программным документам, выполненным печатным способом - содержит требования к оформлению всех документов 19 ГОСТа.
ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению - устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия.
Пункты ТЗ 34 ГОСТа и 19 ГОСТа отличаются.
ГОСТ 19.601-78 Общие правила дублирования, учёта и хранения - общие правила дублирования, обращения, учёта и хранения программных документов. В ГОСТе в нескольких пунктах описано как сделать так, чтобы документы не потерялись.
ГОСТ 19.602-78 Правила дублирования, учёта и хранения программных документов, выполн-х печ. Способом - дополнение к ГОСТу 19.601-78.
ГОСТ 19.603-78 Общие правила внесения изменений - устанавливает общие правила внесения изменений в программные документы. По сути, описывает длинный бюрократический алгоритм внесения изменений в документы.
ГОСТ 19.604-78 Правила внесения изменений в программные документы, выполненных печатным способом - описывает порядок работы и заполнения с Листа регистрации изменений.

Список специализированных ГОСТов, то есть в каждом из них описано содержание и требования к определённому документу:

ГОСТ 19.202-78 Спецификация. Требования к содержанию и оформлению;
ГОСТ 19.301-79 Программа и методика испытаний. Требования к содержанию и оформлению;
ГОСТ 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 ГОСТом:

В ГОСТе 19.101-77 выбрать документ и его код согласно стадии разработки.
Согласно ГОСТу 19.103-77 присвоить номер документу.
Затем по ГОСТам 19.104-78 и 19.106-78 оформить документ.
Из специализированного списка ГОСТов следует выбрать тот, который соответствует разрабатываемому документу.

Заключение

ГОСТ - это не страшно и несложно! Главное понять, что нужно написать и какой для этого ГОСТ используется. Наши основные ГОСТы 19 и 34 для написания документации очень старые, но и по сей день актуальны. Написание документации по стандарту снимает множество вопросов между исполнителем и заказчиком. Следовательно, несёт в себе экономию времени и денег.