Стандарт на разработку руководства пользователя

Журавлев Денис

Когда и у кого возникает необходимость создания руководства пользователя по ГОСТ

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

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

Какие ГОСТ используются при написании руководства пользователя приложения

Существует две серии (набора) стандартов, которые регламентируют набор создаваемых документов и правила их оформления при разработке автоматизированных систем, комплексов и программного обеспечения:

  • ГОСТ 34 — Автоматизированные системы
  • ГОСТ 19 — Единая система программной документации (ЕСПД)

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

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

ГОСТ 19 в большей степени определяет правила оформления документов.

Поэтому, на практике часто используются сразу оба этих ГОСТа.

Руководство пользователя — основной документ для конечного пользователя

Если говорить именно о документации для конечного пользователя системы, то из перечня описываемых в ГОСТ 34 документов нас интересует «Руководство пользователя». В ГОСТ 19 аналогичный по смыслу документ называется «Руководство оператора», но для программного обеспечения чаще используется именно первый вариант.

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

Сложности написания руководства пользователя по ГОСТ

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

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

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

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

Dr.Explain упрощает создание руководства пользователя по ГОСТ

Начиная с версии 5.5.1100 программа для создания пользовательской документации Dr.Explain предлагает функцию автоматизированной поддержки ГОСТ в проектах. Эта функция призвана значительно облегчить жизнь пользователям, перед которыми стоит задача создания руководства пользователя в соответствии с требованиями государственных стандартов.

В частности программа Dr.Explain контролирует и автоматизирует поддержку следующих требований стандартов:

  • Наличие обязательных разделов документа “Руководство пользователя” [ГОСТ 34 РД 50-34.698-90]. Все разделы снабжаются пояснениями по их содержанию.
  • Оформление титульных листов, аннотации и содержания [ГОСТ 19.105-78, 19.104-78].
  • Параметры печатных страниц документа и расположение основных элементов на них [ГОСТ 19.106-78].
  • Структуру и оформление колонтитулов [ГОСТ 19.106-78].
  • Оформление текстовой части документа: стили шрифтов, абзацные отступы, межстрочные интервалы [ГОСТ 19.106-78].
  • Формирование и оформление заголовков, разделов, перечислений (списков) [ГОСТ 19.106-78].

Управление функцией поддержки ГОСТ для проекта доступно в Настройках проекта в разделе Общие.

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

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

Важно: Перед включением режима поддержки ГОСТ для уже существующих в формате Dr.Explain проектов необходимо сделать резервную копию gui-файла проекта.

Важно: Функция поддержки ГОСТ доступна в Dr.Explain только в русскоязычной версии интерфейса. Язык интерфейса программы выбирается в меню Настройки\Выбор языка программы (Options\Application language).

Создание нового руководства пользователя по ГОСТ

Для создания нового руководства пользователя по требованиям ГОСТ 34 в программе Dr.Explain можно использовать команды меню Файл \ Создать локальный проект — Руководство пользователя по ГОСТ 34 или Файл \ Создать общий проект на tiwri.com — Руководство пользователя по ГОСТ 34

или аналогичные кнопки на стартовом экране приложения.

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

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

Настройки оформления для печатных форматов RTF/DOC и PDF будут выставлены в соответствии с требованиям ГОСТ 19.

Приведение существующей пользовательской документации в соответствие с требованиями ГОСТ

Также программа Dr.Explain позволяет привести существующую пользовательскую документацию в соответствии с требованиями ГОСТ.

Важно: Перед включением режима поддержки ГОСТ для уже существующих в формате Dr.Explain проектов необходимо сделать резервную копию gui-файла проекта.

Если исходная документация еще не ведется в Dr.Explain, а хранится в других форматах, первым шагом необходимо выполнить импорт существующих документов в программу. Dr.Explain поддерживает импорт документов из ряда популярных форматов. Команды импорта доступны как на стартовом окне программы, так и в меню Файл.

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

Пользователь должен будет перенести содержимое этих разделов или разделы целиком методом drag-n-drop в основное дерево проекта и отредактировать их по необходимости.

Как и в первом случае настройки оформления для печатных форматов RTF/DOC и PDF будут выставлены в соответствии с требованиям ГОСТ 19.

 Создайте документацию, соответсвующую ГОСТ 19 и ГОСТ 34 в Dr.Explain бесплатно

Смотрите также

  • Шаблоны файлов помощи, руководства пользователя программного обеспечения или сайта, шаблон базы знаний — бесплатные шаблоны и примеры пользовательской документации

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

Предисловие

Цели, основные принципы и общие правила проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены»

Сведения о стандарте

1 РАЗРАБОТАН Акционерным обществом «Всероссийский научно-исследовательский институт сертификации» (АО «ВНИИС») и Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ)

2 ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии

3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 22 декабря 2020 г. N 58)

За принятие проголосовали:

Краткое наименование страны по МК (ИСО 3166) 004-97 Код страны по МК (ИСО 3166) 004-97 Сокращенное наименование национального органа по стандартизации
Армения АМ ЗАО «Национальный орган по стандартизации и метрологии» Республики Армения
Беларусь ВY Госстандарт Республики Беларусь
Киргизия KG Кыргызстандарт
Россия RU Росстандарт
Узбекистан UZ Узстандарт
Украина UA Минэкономразвития Украины

4 Приказом Федерального агентства по техническому регулированию и метрологии от 19 ноября 2021 г. N 1521-ст межгосударственный стандарт ГОСТ 34.201-2020 введен в действие в качестве национального стандарта Российской Федерации с 1 января 2022 г.

5 ВЗАМЕН ГОСТ 34.201-89

6 ИЗДАНИЕ (март 2022 г.) с Поправкой (ИУС N 3 2022 г.)

1 Область применения

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

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

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие межгосударственные стандарты:

ГОСТ 2.102 Единая система конструкторской документации. Виды и комплектность конструкторских документов

ГОСТ 2.113-75 Единая система конструкторской документации. Групповые и базовые конструкторские документы

ГОСТ 2.601 Единая система конструкторской документации. Эксплуатационные документы

_______________

1) В Российской Федерации действует ГОСТ Р 2.601-2019.

ГОСТ 19.101 Единая система программной документации. Виды программ и программных документов

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

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

3 Виды и наименование документов

Состав видов документов, разрабатываемых на стадии «Исследование и обоснование создания АС», определяют исходя из требуемых результатов выполнения данной стадии (научно-технический отчет, тактико-техническое задание, технико-экономическое обоснование).

На стадии «Техническое задание» разрабатывают Техническое задание (ТЗ) на создание автоматизированной системы в соответствии с требованиями ГОСТ 34.602.

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

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

Виды документов, разрабатываемых на стадиях «Эскизный проект», «Технический проект», «Рабочая документация», приведены в таблице 1.

Таблица 1 — Виды документов, разрабатываемых на стадиях «Эскизный проект», «Технический проект», «Рабочая документация»

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

Виды документов на программные средства, используемые при создании АС (ее частей), — по ГОСТ 19.101.

Виды документов на технические средства, используемые при создании АС (ее частей), — по ГОСТ 2.102 и по ГОСТ 2.601 в части эксплуатационных документов.

Наименования конкретных документов, разрабатываемых при проектировании АС в целом или ее части, приведены в таблице 2.

Таблица 2 — Наименования конкретных документов, разрабатываемых при проектировании АС в целом или ее части

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

* Документы, код которых установлен в соответствии с требованиями стандартов Единой системы конструкторской документации (ЕСКД).

Примечания

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

2 Знак «Х» означает принадлежность к проектно-сметной или эксплуатационной документации.

3 Номенклатуру документов одного наименования устанавливают в зависимости от принятых при создании системы проектных решений.

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

В зависимости от применяемых методов проектирования и специфики создаваемых АС допускается:

  • разрабатывать групповые и базовые документы в соответствии с разделами 1, 3, 4, 6 ГОСТ 2.113— 75;
  • выпускать документы отдельными самостоятельными частями, соответствующими разделам основного документа;
  • расширять номенклатуру документов, установленную настоящим стандартом.

При изготовлении несерийных компонентов комплексов средств автоматизации и на стадии «Ввод в действие» разрабатывают следующие организационно-распорядительные документы:

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

4 Комплектность документации

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

Примечание — Комплектность проектно-сметных документов определяют в соответствии с правилами, установленными системой проектной документации для строительства.

4.2 На каждый комплект должна быть составлена ведомость документов.

4.3 Комплектность документации, обеспечивающей разработку, изготовление, приемку и монтаж технических средств, — по ГОСТ 2.102. Комплектность эксплуатационной документации на эти средства — по ГОСТ 2.601.

4.4 Комплектность документации на программные средства вычислительной техники — по ГОСТ 19.101.

4.5 При самостоятельной разработке составной части системы документы на нее комплектуют в соответствии с требованиями настоящего стандарта.

5 Обозначения документов

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

Заимствованным документам сохраняют ранее присвоенные обозначения.

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

5.3 Обозначение документа имеет следующую структуру, показанную на рисунке 1.

5.3.1 Правила обозначения системы (части системы) приведены в приложении А.

5.3.2 Код документа состоит из двух буквенно-цифровых знаков. Код для документов, определенных настоящим стандартом, проставляют в соответствии с графой 3 таблицы 2. Код дополнительных документов формируют следующим образом: первый знак — буква, означающая вид документа согласно таблице 1, второй знак — цифра или буква, указывающая порядковый номер документа данного вида.

Код документа отделяют от предыдущего обозначения точкой.

Рисунок 1. Структура обозначения документа.

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

5.3.4 Номер редакции документа присваивают, начиная со второй в порядке возрастания от 2 до 9, и отделяют от предыдущего значения точкой. Очередной номер редакции присваивают в случаях сохранения (не аннулирования) предыдущей редакции.

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

5.3.6 Признак документа, выполненного на машинных носителях, вводят при необходимости. Букву «М» отделяют от предыдущего обозначения точкой.

Приложение А (рекомендуемое). Правила обозначения систем и их чертежей

А.1 Структура обозначения автоматизированной системы или ее части имеет вид, показанный на рисунке А.1.

Рисунок А.1. Структура обозначения АС

А.2 Код организации-разработчика представляет собой основной государственный регистрационный номер (ОГРН) из Единого государственного реестра юридических лиц (ЕГРЮЛ).

А.З Код классификационной характеристики системы или ее части (подсистемы, комплекса, компонента) присваивают в соответствии с правилами, установленными в отрасли.

А.4 Порядковый регистрационный номер системы (части системы) присваивает служба организации разработчика, ответственная за ведение картотеки и учет обозначений. Регистрационные номера присваивают с 001 до 999 по каждому коду регистрационной характеристики.

Скачать документ в формате .doc вы можете здесь.

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

Комплекс технических документов, который регламентирует деятельность разработчиков, называется нормативно-методическим обеспечением (НМО). В данный комплекс входят:

ü стандарты;

ü руководящие документы;

ü методики и положения;

ü инструкции и т. д.

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

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

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

ü дает описание возможностей системы;

ü обеспечивает фиксацию принятых и реализованных проектных решений;

ü определяет условия функционирования ИС;

ü предоставляет информацию об эксплуатации и обслуживании ИС;

ü регламентирует процедуру защиты информации, регулирует права различных групп пользователей;

ü определяет возможности модернизации системы.

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

ü что и зачем должно быть документировано?

ü для кого предназначен тот или иной документ?

ü какие ошибки может допустить пользователь и что нужно сделать для их устранения?

ü как и в каких условиях будет использоваться документ?

ü каковы сроки разработки документа?

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

ü кто будет оценивать документ и как он соотносится с отраслевыми или ведомственными требованиями на сертификацию разработки?

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

Как правило, к технической документации предъявляются следующие основные требования:

ü документы должны быть точными, полными и, по возможности, краткими, иметь четкое и однозначное толкование;

ü документация должна создаваться параллельно с разработкой самой информационной системы;

ü обязанности по документированию системы лежат на ее разработчике;

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

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

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

По объекту стандартизации:

ü стандарты на продукты и услуги;

ü стандарты на процессы и технологии.

По предмету стандартизации:

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

ü стандарты на организацию жизненного цикла (ЖЦ) автоматизированных систем и программного обеспечения.

Альтернативная классификация группирует стандарты по статусу:

ü официальные стандарты;

ü стандарты «де-факто».

В свою очередь официальные стандарты подразделяются на:

þ международные стандарты (ISO, ANSI, IDEF0/1);

þ стандарты Российской Федерации (ГОСТ);

þ отраслевые стандарты;

þ ведомственные стандарты.

Стандартами «де-факто» являются официально никем не утвержденные, но фактически действующие стандарты.

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

Отдельно выделяют корпоративные стандарты.

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

ü стандарты проектирования;

ü стандарты оформления проектной документации;

ü стандарты пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

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

þ правила именования объектов, оформления диаграмм, включая требования к форме и размерам объектов и т. д.

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

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

Стандарт оформления проектной документации должен устанавливать:

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

þ требования к ее оформлению, включая требования к содержанию разделов, подразделов, пунктов, таблиц и т. д.

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

þ требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;

þ требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать:

þ правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

þ правила использования клавиатуры и мыши;

þ правила оформления текстов помощи;

þ перечень стандартных сообщений;

þ правила обработки реакции пользователя.

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

Отечественными стандартами являются стандарты ЕСПД (Единой Системы Программной Документации) серии ГОСТ 19.ХХХ и комплекс стандартов на автоматизированные системы серии ГОСТ 34.ХХХ, созданные в 80-90-е годы двадцатого века. Кроме того, существуют более современные стандарты на программное обеспечение.

Перечень стандартов ГОСТ 19.ХХХ

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

ü ГОСТ 19.001-77 Общие положения

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

ü ГОСТ 19.102-77 Стадии разработки

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

ü ГОСТ 19.104-78 Основные надписи

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

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

ü ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению

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

ü ГОСТ 19.301-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.601-78 Общие правила дублирования, учета и хранения

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

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

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

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

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

Перечень стандартов ГОСТ 34.ХХХ

Стандарты информационной технологии

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

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

ü ГОСТ 34.320-96 Информационные технологии (ИТ). Система стандартов по базам данных. Концепции и терминология для концептуальной схемы и информационной базы

ü ГОСТ 34.321-96 Информационные технологии (ИТ). Система стандартов по базам данных. Эталонная модель управления данными

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

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

ü ГОСТ 34.603-92 Информационная технология (ИТ). Виды испытаний автоматизированных систем

ü РД 50-34.698-90 Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов

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

Если говорить о более поздних отечественных стандартах, следует выделить ГОСТ Р 51904-2002 Программное обеспечение встроенных систем. Общие требования к разработке и документированию, который был разработан Государственным научно-исследовательским институтом авиационных систем с участием Научно-исследовательского института стандартизации и унификации. Данный стандарт распространяется на процессы разработки и документирования программного обеспечения встроенных систем реального времени и все действия, имеющие отношение к разработке программного обеспечения. Стандарт подготовлен в развитие ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств, о котором пойдет речь в п. 2.3.

Отдельно стандарт ГОСТ Р 51904-2002 в части подготовки документов будет рассмотрен в главе 9 «Программное обеспечение».

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

В основе практически всех современных промышленных технологий создания программных средств лежит международный стандарт ISO/IEC 12207 Information technology. System and software engineering. Software life cycle processes (ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств). Первая редакция стандарта ISO/IEC 12207 была опубликована в августе 1995 г. и явилась первым международным стандартом, содержавшим представительный набор процессов жизненного цикла в отношении программного обеспечения, которое рассматривалось как часть большой системы, а также применительно к программным продуктам и услугам. Стандарт определяет процессы, виды деятельности и задачи, которые используются при приобретении программного продукта или услуги, а также при поставке, разработке, применении по назначению, сопровождении и прекращении применения программных продуктов.

Основными характеристиками данного стандарта являются:

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

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

Кроме того, существуют международные стандарты (на английском языке), которые направлены на написание документации:

1. IEEE Std 1063-2001 «IEEE Standard for Software User Documentation» – стандарт для написания руководства пользователя. В документе обозначены требования к структуре, содержимому и формату инструкций пользователя.

2. IEEE Std 1016-1998 «IEEE Recommended Practice for Software Design Descriptions» – стандарт для написания технического описания программы. Представлены рекомендации к документам, описывающим архитектуру программного обеспечения.

3. ISO/IEC FDIS 18019:2004 «Guidelines for the design and preparation of user documentation for application software» – стандарт для написания руководства пользователя. В данном документе есть большое количество примеров. Также в приложениях есть чек-листы «что не забыть сделать в процессе разработки документации» и «что должно быть».

Документ особенно полезен начинающим специалистам.

4. ISO/IEC 26514:2008 «Requirements for designers and developers of user documentation» – стандарт для дизайнеров и разработчиков пользователей документации.

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

Понравилась статья? Поделить с друзьями:
  • Руководство rotax 552
  • Как определить стиль руководства учителя
  • Метронидазол инструкция по применению при демодексе
  • Инструкция по сыворотке против рожи свиней
  • Часы мужские наручные skmei инструкция на русском языке