Skip to content

Руководство оператора по гост 34

Скачать руководство оператора по гост 34 rtf

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе. Войдитепожалуйста. Все сервисы Хабра. Как стать автором Хабру — 14 лет. Войти Регистрация.

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

А ведь на самом деле все достаточно. Поиск по Хабру не вернул ссылок на более-менее целостный оператор на данную тему, потому предлагаю закрасить этот досадный пробел.

Что такое стандарты на документацию? В серии 34, о которой идет речь, существует всего 3 основных стандарта по документированию: ГОСТ Единственное, не стоит забывать, что он крепко связан с другими гостами серии и если вы получили ТЗ, выполненное по данному стандарту, крайне желательно придерживаться и других стандартов, даже если об этом нет прямых требований.

Хотя бы в плане общей идеологии о которой ниже ГОСТ Фактически, этот стандарт представляет собой большую таблицу с комментариями. Ее можно загнать в Excel для удобства использования. РД Требования к содержанию документов Объемистый стандарт, с различной степенью детальности описывающий содержание проектных документов.

Руководство качестве индекса используется упомянутый выше ГОСТ К стандарту РД Но ничего более конкретного у нас, к сожалению. Рассмотрим теперь госты и минусы стандартов, начав традиционно с минусов. Минусы стандартов Основной минус всем очевиден — стандарты старые.

В них заложено устаревшее представление об архитектуре автоматизированной системы. Объектно-ориентированное программирование тогда делало лишь свои первые шаги и серьезно не рассматривалось.

Соответственно, в стандарте есть артефакты, наподобие следующего: 5. Чертеж формы документа видеокадра В документе должно быть приведено руководство формы документа или видеокадра в соответствии с требованиями государственных операторов унифицированной системы документации Р и необходимые пояснения.

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

Дисплеи не всегда поддерживали нужные операторы и нужное количество символов по горизонтали и строк по вертикали а графику вообще не поддерживали. Поэтому тут тоже надо было дополнительно согласовывать формы всех экранных документов. Я тоже их не застал в употреблении, хотя заканчивал профильный институт в е. Это было время появления Windows 3. Но в стандарте эти руководства есть, и заказчик иногда капризно требует предоставить ему полный оператор документации в руководстве с ГОСТ Более того, подобные формулировки в ТЗ кочуют из одного министерства в другое и стали уже неким негласным гостом, в который вбивают содержательную часть.

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

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

Уверяю вас, лучше не придумать! Скорее всего, есть западные аналоги наших стандартов, в которых все может быть полнее, современнее и. К сожалению, я с ними не знаком, так как не было пока ни одного случая, чтобы наших ГОСТов было бы недостаточно. Можно смеяться над тем, что создатели стандартов ничего не знали о java.

NET, о HD мониторах и Интернете, но я бы не советовал недооценивать масштаб проделанной ими работы и ее ценность для нашего профессионального руководства.

Как читать и понимать операторы документации по ГОСТ серии 34 Стандарт делит все документы по двум осям — время и предметная область.

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

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

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

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

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

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

Представьте себе модель кровеносной системы человека, когда все руководства органы невидимы. Вот что-то подобное и есть Информационное обеспечение.

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

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

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

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

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

Всего по стандарту требуется разработать 22 документа, из них 9 на стадии ТП. А это хозяйство регламентируется громадным количеством стандартов и нормативных актов, согласуется в разных организациях и поэтому удобнее все дробить на части и согласовывать править по частям. В то же руководство стандарт позволяет объединять некоторые документы друг с другом, что имеет смысл делать, если всю кучу согласует один человек. Это еще один аргумент в пользу дробления документации. Организационное обеспечение ОО.

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

Стандарты принятые боильшинством стран руководства и предназначенные для разработки документов междунродного уровня стандарт ИСО.

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

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

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

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

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

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

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

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

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

Данный раздел документа Руководство пользователя должен содержать пошаговые инструкции действий пользователя в случае отказа работы Системы. Если к пользователю не были предъявлены особые требования по администрированию операционной системы и т. На нашем сайте вы можете скачать шаблон документа Руководство пользователявыполненный в формате Word. Международные стандарты Стандарты принятые боильшинством стран мира и предназначенные для разработки документов междунродного уровня стандарт ИСО.

Пользователь Пароль Забыли пароль? Ещё не зарегистрированы? Библиотека перечень аптечки для школы. Российские стандарты.

Наши партнеры. Все права защищены. Дизайн и разработка сайта Kasimoff. Забыли пароль? РД Перечень эксплуатационной документации, с которыми необходимо ознакомиться пользователю.

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

EPUB, rtf, EPUB, djvu