Документ «Руководство пользователя»
Документ «Руководство пользователя»
РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов: <…>.
УКАЗАНИЯ ГОСТ:
Настоящие методические указания распространяются на автоматизированные системы (АС), используемые в различных сферах деятельности (управление, исследование, проектирование и т. п.), включая их сочетание, и устанавливают требования к содержанию документов, разрабатываемых при создании АС.
Руководство пользователя
- Структура документа:
- 1. Введение
- 1.1 Область применения
- 1.2 Краткое описание возможностей
- 1.3 Уровень подготовки пользователя
- 1.4 Перечень эксплуатационной документации
- 2 НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ
- 2.1 Виды деятельности, функции
- 2.2 Программные и аппаратные требования к системе
- 3 ПОДГОТОВКА К РАБОТЕ
- 3.1 Состав дистрибутива
- 3.2 Запуск системы
- 3.3 Проверка работоспособности системы
- 4 ОПИСАНИЕ ОПЕРАЦИЙ
- 4.1 Наименование операции
- 4.2 Условия выполнения операции
- 4.3 Подготовительные действия
- 4.4 Основные действия
- 4.5 Заключительные действия
- 4.6 Ресурсы, расходуемые на операцию
- 5 АВАРИЙНЫЕ СИТУАЦИИ. ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ
- 6 РЕКОМЕНДАЦИИ ПО ОСВОЕНИЮ
УКАЗАНИЯ ГОСТ:
Документ содержит разделы:
1) введение;
2) назначение и условия применения;
3) подготовка к работе;
4) описание операций;
5) аварийные ситуации;
6) рекомендации по освоению.
1. Введение
1.1 Область применения
ПРИМЕР СОДЕРЖАНИЯ:
Наполнение данного раздела можно взять из документа «Техническое задание, п.п.2.1».
1.2 Краткое описание возможностей
ПРИМЕР СОДЕРЖАНИЯ:
Наполнение данного раздела можно взять из документа «Описание автоматизируемых функций, п.п.2.».
1.3 Уровень подготовки пользователя
ПРИМЕР СОДЕРЖАНИЯ:
Наполнение данного раздела можно взять из документа «Техническое задание, п.п.4.1.2 Требования к численности и квалификации персонала системы»
1.4 Перечень эксплуатационной документации
ПРИМЕР СОДЕРЖАНИЯ:
Перечень эксплуатационных документов, с которым необходимо ознакомиться:
— АС Кадры. «Руководство администратора»;
— АС Кадры. «Руководство пользователя»;
— т.д.
— пр.;
2 НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ
УКАЗАНИЯ ГОСТ:
В разделе «Назначение и условия применения» указывают:
1) виды деятельности, функции, для автоматизации которых предназначено данное средство автоматизации;
2) условия, при соблюдении (выполнении, наступлении) которых обеспечивается применение средства автоматизации в соответствии с назначением (например, вид ЭВМ и конфигурация технических средств, операционная среда и общесистемные программные средства, входная информация, носители данных, база данных, требования к подготовке специалистов и т. п.).
ПРИМЕР СОДЕРЖАНИЯ:
2.1 Виды деятельности, функции
ПРИМЕР СОДЕРЖАНИЯ:
АС Кадры предназначена для автоматизации следующих видов деятельности:
Наполнение раздела можно взять в документе «Описание автоматизируемых функций, раздел ЦЕЛИ АС И АВТОМАТИЗИРУЕМЫЕ ФУНКЦИИ».
2.2 Программные и аппаратные требования к системе
ПРИМЕР СОДЕРЖАНИЯ:
Пример требований к программному обеспечению приведен в документе «Пояснительная записка, п.п.3.10».
Пример требований к аппаратному обеспечению приведен в документе «Техническое задание, п.п.4.3.5».
3 ПОДГОТОВКА К РАБОТЕ
УКАЗАНИЯ ГОСТ:
В разделе «Подготовка к работе» указывают:
1) состав и содержание дистрибутивного носителя данных;
2) порядок загрузки данных и программ;
3) порядок проверки работоспособности.
3.1 Состав дистрибутива
ПРИМЕР СОДЕРЖАНИЯ:
В состав дистрибутива АС Кадры входит:
— СУБД Oracle 10.2g;
— Приложение установки базы данных;
— Серверная часть Windows приложения АС Кадры;
— Клиентская часть Windows приложения;
— т.д.;
— пр.
3.2 Запуск системы
ПРИМЕР СОДЕРЖАНИЯ:
Предварительно необходимо выполнить установку системы. Информацию об установке системы можно получить в документе РД И3(А) АС Кадры, который входит в состав проектной документации.
1. Для того, чтобы запустить АС Кадры, откройте папку, в которую была установлена программа, и запустите файл kadry.exe.
2. В открывшемся окне заполните следующие поля в области окна Общие параметры:
— Логин — логин (логическое имя) пользователя;
— Пароль — пароль для входа в систему;
3. т.д.
пр.
3.3 Проверка работоспособности системы
ПРИМЕР СОДЕРЖАНИЯ:
Программное обеспечение работоспособно, если в результате действий пользователя, изложенных в п.п.3.2, на экране монитора отобразилось главное окно клиентского приложения без выдачи пользователю сообщений о сбое в работе.
4 ОПИСАНИЕ ОПЕРАЦИЙ
УКАЗАНИЯ ГОСТ:
В разделе «Описание операций» указывают:
1) описание всех выполняемых функций, задач, комплексов задач, процедур;
2) описание операций технологического процесса обработки данных, необходимых для выполнения функций, комплексов задач (задач), процедур.
Для каждой операции обработки данных указывают:
1) наименование;
2) условия, при соблюдении которых возможно выполнение операции;
3) подготовительные действия;
4) основные действия в требуемой последовательности;
5) заключительные действия;
6) ресурсы, расходуемые на операцию.
В принципе, допускается в пределах разумного описывать операции без перечисления всех приведенных выше пунктов.
4.1 Наименование операции
ПРИМЕР СОДЕРЖАНИЯ:
Просмотр справочной информации.
4.2 Условия выполнения операции
ПРИМЕР СОДЕРЖАНИЯ:
Приложение запущено, успешно функционирует, не выполняет никакх операций, блокирущих доступ к пунктам меню.
4.3 Подготовительные действия
ПРИМЕР СОДЕРЖАНИЯ:
Отсутствуют.
4.4 Основные действия
ПРИМЕР СОДЕРЖАНИЯ:
Открыть пункт меню «Помощь», выбрать раздел «Справка». Появится всплывающее окно, содержащее разделы со справкой.
4.5 Заключительные действия
ПРИМЕР СОДЕРЖАНИЯ:
После завершения работы со справочной информацией, закрыть вплывающее окно со справкой.
4.6 Ресурсы, расходуемые на операцию
ПРИМЕР СОДЕРЖАНИЯ:
Отсутствуют.
5 АВАРИЙНЫЕ СИТУАЦИИ. ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ
УКАЗАНИЯ ГОСТ:
В разделе «Аварийные ситуации» указывают:
1) действия в случае несоблюдения условий выполнения технологического процесса, в том числе при длительных отказах технических средств;
2) действия по восстановлению программ и/или данных при отказе магнитных носителей или обнаружении ошибок в данных;
3) действия в случаях обнаружении несанкционированного вмешательства в данные;
4) действия в других аварийных ситуациях
ПРИМЕР СОДЕРЖАНИЯ:
При сбое в работе аппаратуры восстановление нормальной работы системы должно производиться после:
— перезагрузки операционной системы;
— запуска исполняемого файла системы;
При ошибках в работе аппаратных средств (кроме носителей данных и программ) восстановление функции системы возлагается на ОС.
При ошибках, связанных с программным обеспечением (ОС и драйверы устройств), восстановление работоспособности возлагается на ОС.
При неверных действиях пользователей, неверных форматах или недопустимых значениях входных данных, система выдает пользователю соответствующие сообщения, после чего возвращается в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных.
6 РЕКОМЕНДАЦИИ ПО ОСВОЕНИЮ
УКАЗАНИЯ ГОСТ:
В разделе «Рекомендации по освоению» указывают рекомендации по освоению и эксплуатации, включая описание контрольного примера, правила его запуска и выполнения.
ПРИМЕР СОДЕРЖАНИЯ:
Для успешного освоения приложения АС Кадры необходимо иметь навыки работы с ПК и изучить следующее:
— Нормативно-правовую базу по вопросам управления государсвенными кадрами;
— Раздел «Описание процесса деятельности» документа «Пояснительная записка (Технический проект)»;
— Раздел «Описание автоматизируемых функций» документа «Пояснительная записка (Технический проект)»;
— Настоящее «Руководство пользователя».
Контрольный пример работы с системой
Ниже рассмотрен пример работы с системой, начиная с ее запуска и заканчивая оформлением документов:
1. Запустите систему.
2. т.д.
3. пр.
Как с помощью руководства пользователя повысить качество информационной системы
Время на прочтение
7 мин
Количество просмотров 15K
В действительности все совершенно иначе, чем на самом деле.
Антуан де Сент-Экзюпери
Многое в разработке руководства пользователя регламентировано и описано ГОСТами. Но при создании больших гетерогенных систем могут возникать вопросы, не до конца освещенные этими документами.
Отношение к руководству пользователя бывает разным. Многие совсем не задаются вопросом, каковы место и роль документа в процессе разработки больших гетерогенных информационных систем, для других же все и так ясно. Не спешите. В статье мы рассмотрим подходы к организации процесса создания и поддержания в актуальном состоянии этого важного документа, оценим значимость руководства пользователя для всей информационной системы в целом и придем к некоторым неожиданным выводам.
Статья будет полезна для тестировщиков, технических писателей, аналитиков и даже для руководителей проектов.
Описание проблемы
Некоторое время назад я в качестве аналитика начала работу на проекте по разработке информационной системы федерального масштаба. Для быстрого погружения в предметную область мне было предложено заняться руководством пользователя: провести аудит и организовать процесс доработки документа под стремительно расширяющийся функционал системы.
Отдельно остановлюсь на особенностях проекта, поскольку подходы и принципы, о которых пойдет речь, разработаны и адаптированы специально для следующих условий.
1. Масштаб.
Большая гетерогенная распределенная информационная система, которая включает десятки взаимодействующих между собой подсистем.
2. Параллельная разработка.
Из-за масштаба системы над ней работают изолированные команды аналитиков, разработчиков и тестировщиков.
3. Частые изменения.
Опять же следствие масштаба — постоянный поток изменений и доработок.
4. Относительно универсальный и стандартизированный набор бизнес-процессов в рамках проекта.
БОльшая часть процессов имеет постоянную сходную с другими бизнес-процессами часть.
Даже поверхностный взгляд на актуальную на тот момент версию руководства пользователя позволил сделать вывод о невысоком качестве документа. Основных проблем было две: неактуальность и отсутствие единообразия при описании сходных функций и процессов.
Низкое качество руководства пользователя может привести к ряду негативных последствий для всего проекта. Выделю основные:
- рост расходов на эксплуатацию из-за неправильного использования системы и, как следствие, увеличение нагрузки на службу поддержки;
- недовольство пользователей и заказчика;
- увеличение затрат на разработку и сопровождение системы.
Нужно было срочно исправлять ситуацию. Причем сделать это с минимальными затратами.
Поиск решения
Для каждой проблемы был разработан собственный подход. Рассмотрим каждую проблему и каждый подход более подробно.
Неактуальность документа
Неактуальность документа содержит два класса проблем: устаревшее описание имеющегося функционала и отсутствие описания новых возможностей системы. Алгоритм устранения проблемы был выбран такой.
- Составить описание модели «AS IS» (т.е. что у нас есть сейчас, какие функции и бизнес-процессы описаны).
- Описать модель «TO BE» (в качестве консультантов привлекались ведущие аналитики по каждой подсистеме).
- Сравнить «AS IS» и «TO BE» с помощью индикатора «Светофор» и составить план действий.
Для удобства данные заносились в таблицу (см. Рисунок 1), в строках которой указывались автоматизируемые процессы и функции, а в столбцах – существующие описания из руководства пользователя. Последние дополнительно группировались в блоки для каждой подсистемы. В итоге получилась наглядная картина соответствия процессов/функций и их описаний. Кроме того, удалось выделить похожие описания для дальнейшей группировки.
После этого была проведена каталогизация всех описаний (актуальная проблема, поскольку общее количество описаний превышало 100 шт.). Если процесс был описан в руководстве пользователя, то в ячейке на пересечении соответствующих строки и столбца проставлялся номер пункта (раздела).
Далее наглядным индикатором «Светофор» были отмечены результаты сравнения:
- Зеленый цвет – процесс есть в руководстве и нужен в бизнесе.
- Красный – процесс есть, но не нужен (удалить!).
- Желтый – процесс отсутствует, но нужен (добавить!).
- Серый – процесс отсутствует и не нужен.
Использование цветовых индикаторов позволило выявить общую картину: руководство пользователя нужно править… и существенно.
Рисунок 1
Началась работа над документом. Подспорьем на данном этапе опять же стала таблица: если процесс редактируется в одном блоке, то и в другом он создается схожим процентов на 80 образом.
Общее количество описаний функций в руководстве пользователя – более сотни, типовых – 25.
Дальнейшая обработка описаний потребовала дополнительной градации: ярко-зелёный — для сценариев, в которых всё хорошо и правки не требуются; светло-зеленый – для сценариев, которые в целом описаны правильно и нуждаются только в исправлении некоторых моментов; оранжевый – для тех, которые принципиально неправильно описаны и которые необходимо править в первую очередь.
Рисунок 2
В итоге общая картина предстала в цвете: были видны обширные оранжевые пятна проблемных областей, много светло-зеленого и практически отсутствие ярко-зеленого.
Таблица соответствия в ходе работы над документом:
Рисунок 3
По завершении «покрасочных» работ обозначились приоритеты:
- убрать оранжевый цвет – все должно быть описано корректно;
- cделать светло-зеленые поля ярко-зелеными.
На этом моменте важно вспомнить про закон Парето (принцип 20/80): мы относительно быстро исправили наиболее проблемные оранжевые области и долго работали над светло-зелеными. Ведь в них, собственно, вся суть, если мы стремимся к тому, чтобы пользователь действительно мог работать с руководством.
Отсутствие единообразия
При решении этой проблемы ставилась задача обеспечить единообразие при описании сходных процессов (кейсов) и существенно сократить трудозатраты на обновление и поддержание документа. Был выбран подход, в соответствии с которым описание каждого процесса представляется в виде строительного блока (1), а сам документ – их комбинации (3). Все строительные блоки должны располагаться в репозитории (Wiki) с обязательным контролем изменений и поддержкой версионности (2).
Рисунок 4
Основное преимущество данного подхода заключается в существенном сокращении трудозатрат: при создании и редактировании общей части строительного блока правки вносятся только один раз. Сборка руководства пользователя из строительных блоков происходит также гораздо быстрее по сравнению с традиционным вариантом.
Принципиально важный момент: доступ к репозиторию должен быть обеспечен всем командам, работающим над проектом, согласно сформированному регламенту его использования.
Используя такой подход для актуализации и метод «строительных блоков» для сборки, документ удалось за короткий срок привести в надлежащее состояние. Трудозатраты сократились более чем на 30%, по сравнению с традиционным методом формирования документа. Казалось бы, на этом месте можно было бы обозначить happy end, но мне бы хотелось продолжить. Будет интересно.
Место руководства пользователя в цикле управления требованиями
Качественное руководство пользователя получило новые функции, отлично встроилось в систему управления требованиями и общий цикл разработки (независимо от того, последовательная она или итеративная) информационной системы.
В классический цикл разработки от анализа требований (1) до тестирования (4) добавляется этап подготовки документов, среди которых особое место занимает руководство пользователя. Почему же так важен этот документ? По нескольким причинам. В случае параллельной независимой разработки отдельных подсистем возможна потеря унификации (например, расположение управляющих элементов, наименования и т.д.). Именно при подготовке руководства пользователя становятся видны неувязки/несоответствия, как в функциональной плоскости, так и на уровне пользовательских интерфейсов.
Рисунок 5
Только на уровне руководства пользователя система видна целиком, а не как набор отдельных подсистем. Концепция строительных блоков позволяет решить проблему неувязок, но только в случае использования репозитория при разработке постановочной части в качестве справочных материалов. Таким образом, у руководства появляется новая категория пользователей – аналитики и тестировщики. И, конечно, документ должен быть синхронизирован и полностью соответствовать пользовательским требованиям. На этом этапе проводится дополнительная верификация на предмет соответствия пользовательских требований разработанным функциям (руководство пользователя, фактически, содержит бизнес-описание системы).
Из рисунка 5 хорошо видно, что процесс разработки финализируется созданием руководства. Этот документ также активно используется на других этапах разработки.
Рисунок 6
Выводы
Качественно и грамотно составленное руководство, которое содержит актуальное описание автоматизируемых функций, становится важным и востребованным у конечных пользователей и разработчиков документом и приобретает некоторые новые функции:
- компонент базы знаний;
- дополнительный рубеж тестирования и верификации функций, инструмент контроля;
- средство общего повышения качества информационной системы.
Использование описанных подходов при формировании руководства пользователя позволяет:
- существенно сократить затраты на создание документа и поддержание его в актуальном состоянии;
- автоматизировать процесс формирования документа;
- глубоко интегрировать и синхронизировать процесс подготовки руководства пользователя с остальными процессами разработки информационной системы;
- повысить качество информационной системы в целом.
Я надеюсь, что прочитав эту статью, некоторые из вас по-новому посмотрят на этот вроде бы нехитрый, но, как оказалось, очень важный документ и возьмут на вооружение рассмотренные подходы к его формированию.
P.S. В статью не вошли вопросы содержательности элементов и разделов руководства пользователя. Подробно это рассмотрено и регламентировано подразделом 3.4 документа РД 50-34.698-9 и стандартом IEEE 1063-2001.
Структура и содержание документов Руководство оператора, Руководство программиста, Руководство системного программиста регламентированы ГОСТ 19.505-79, ГОСТ 19.504-79 и ГОСТ 19.503-79 соответственно.
Обобщенная структура руководства пользователя, построенная на основе анализа перечисленных стандартов, приведена здесь. Общую методологию можно посмотреть в этой статье.
Журавлев Денис
Когда и у кого возникает необходимость создания руководства пользователя по ГОСТ
Многие 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 бесплатно
Смотрите также
- Шаблоны файлов помощи, руководства пользователя программного обеспечения или сайта, шаблон базы знаний — бесплатные шаблоны и примеры пользовательской документации
Руководство
пользователя как программная
(эксплуатационная) документация
пользователя
Документ
«Руководство пользователя» относится
к пакету эксплуатационной документации.
Основная цель руководства пользователя
заключается в обеспечении пользователя
необходимой информацией для самостоятельной
работы с программой или автоматизированной
системой.
Таким
образом, документ Руководство пользователя
должен отвечать на следующие вопросы:
что это за программа, что она может, что
необходимо для обеспечения ее корректного
функционирования и что делать в случае
отказа системы.
Документация:
программная/эксплуатационная/документация
пользователя
Предмет:
программа,
программный компонент комплекса
или системы
Аудитория:
пользователи программы, т. е. лица,
применяющие ее для решения собственных
прикладных задач
Задачи:
обеспечить пользователям возможность
в полном объеме самостоятельно освоить
и применять программу
Руководящими
стандартами для создания документа
Руководство пользователя могут
являться как РД
50-34.698-90 в п.п. 3.4. «Руководство пользователя»,
так и ГОСТ
19.505-79 «Руководство оператора. Требования
к содержанию и оформлению».
Можно
выделить следующие основные разделы
руководства пользователя:
-
Назначение
системы; -
Условия
применения системы; -
Подготовка
системы к работе; -
Описание
операций; -
Аварийные
ситуации.
Назначение
системы
Данный
раздел документа Руководство пользователя
должен содержать информацию о назначении
системы, ее целях и задачах.
Пример:
«Корпоративный
интранет портал предназначен для
повышения корпоративной культурыр
организации эффективного взаимодействия
сотрудников.
Основной
целью Порта является создание единого
информационного пространства предприятия
и оптимизация работы сотрудников путем
облегчения коммуникаций между ними и
оптимизации ряда бизнес-процессов.»
Условия
применения системы
Данный
раздел документа Руководство пользователя
должен включать все те факторы, которые
необходимы для корректной работы
системы. Здесь можно выделить несколько
подразделов:
-
Требования
к аппаратному обеспечению – сюда можно
включить требования к конфигурации
компьютера пользователя, программное
обеспечение необходимое для работы
Системы, а также наличие дополнительного
оборудования (принтер, сканер и т.п.),
если таковое необходимо; -
Квалификация
пользователя – данный подраздел должен
содержать требования к навыкам и знаниям
пользователя (пример:
«Пользователи должны обладать умениями
работать с операционной системой
Windows»);
Подготовка
системы к работе
Данный
раздел документа Руководство пользователя
должен содержать пошаговую инструкцию
для запуска приложения. К этапу подготовки
системы к работе можно отнести установку
дополнительных приложений (при
необходимости), идентификацию,
аутентификацию и т.п.
Описание
операций
Это
основной раздел документа Руководство
пользователя, который содержит пошаговую
инструкцию для выполнения того или
иного действия пользователем.
Если
работа автоматизированной системы
затрагивает целый бизнес-процесс, то в
руководстве пользователя перед описанием
операций целесообразно предоставить
информацию о данном процессе его
назначении и участниках. Подобное
решение позволяет человеку четко
представить свою роль в данном процессе
и те функции, которые реализованы для
него в системе.
Далее
в документе Руководство пользователя
следует представить описание функций
разбитых на отдельные операции. Необходимо
выделить подразделы, описывающие функции
данного процесса, и действия, которые
необходимо совершить для их выполнения.
Пример:
«4.1
Согласование проекта
Данный
процесс предназначен для организации
работы сотрудников, участвующих в
разработке и согласовании проекта.
Автор
проекта создает запись в Системе и
прикрепляет пакет необходимой
документации, далее проект передается
на согласование руководящими лицами.
Руководители после ознакомления с
проектом могут подтвердить его или
отправить на доработку Автору.
4.1.1
Создание проекта
Для
того чтобы создать Проект необходимо
на панели «…» нажать на кнопку «…» и в
появившейся форме заполнить следующие
поля:
-
Наименование
проекта; -
Описание
проекта;
Следующие
поля заполняются автоматически:
-
Дата
создания проекта – текущая дата; -
Автор
– ФИО и должность автора проекта.»
Чем
подробнее будут описаны действия с
системой, тем меньше вопросов возникнет
у пользователя. Для более легкого
понимания всех принципов работы с
программой стандартами в документе
Руководство пользователя допускается
использовать схемы, таблицы, иллюстрации
с изображением экранных форм.
Для
крупных автоматизированных систем
рекомендуется создавать отдельное
руководство для каждой категории
пользователя (пользователь, модератор
и т.п.). Если в работе с системой выделяются
дополнительные роли пользователей, то
в документе Руководство пользователя
целесообразно поместить таблицу
распределения функций между ролями.
Аварийные
ситуации
Данный
раздел документа Руководство пользователя
должен содержать пошаговые инструкции
действий пользователя в случае отказа
работы Системы. Если к пользователю не
были предъявлены особые требования по
администрированию операционной системы
и т.п., то можно ограничиться фразой «При
отказе или сбое в работе Системы
необходимо обратиться к Системному
администратору».
Методика
и стиль изложения руководства пользователей
Руководство
пользователя может представлять собой
как краткий справочник по основному
функционалу программы, так и полное
учебное пособие. Методика изложения
материала в данном случае будет зависеть
от объема самой программы и требований
заказчика.
В
зависимости от особенностей программы
и целевой аудитории руководство
пользователя по способу изложения
материала может приближаться к учебнику
или, наоборот, к справочнику. Порядок
изложения материала в руководстве
пользователя определяется пользовательской
перспективой программы.
Если
программа представляет собой инструмент,
позволяющий решать практические задачи
из некоторого конечного набора, в
руководстве приводят типовые процедуры
решения каждой из них. Например,
пользователю почтового клиента необходимо
знать, как написать и отправить сообщение,
как загрузить новые сообщения с сервера,
как ответить на сообщение и т. п. Каждое
из этих действий можно разложить на
последовательные элементарные шаги,
во всяком случае, для типичных ситуаций.
В крупной программе подобных пользовательских
задач может
быть много, но не бесконечно много.
Руководство пользователя, построенное
по принципу пользовательских задач,
напоминает учебник, хотя, как правило,
лишено присущего учебникам методического
аппарата: проверочных заданий, вопросов,
упражнений.
Если
программа представляет собой среду, в
пределах которой пользователь может
решать задачи, поставленные им
самостоятельно, руководство пользователя
должно быть ближе к справочнику. В нем
последовательно и систематично должны
быть описаны все функции программы и
порядок их применения. Что с ними делать,
на что направить, пользователь будет
думать сам (или запишется на учебные
курсы). Так, в руководстве пользователя
по графическому редактору мы найдем
описание всех графических примитивов,
инструментов, фильтров, однако, там не
будет напрямую сказано, как изобразить
здание, автомобиль или, скажем, собаку.
Пользователь это либо умеет рисовать,
либо нет.
Возможны
и другие пользовательские перспективы.
Бывают программы, посредством которых
пользователь контролирует состояние
того или иного объекта, скажем, промышленной
установки. Тогда руководство пользователя
строится по принципу таблицы: сообщение
программы — реакция или возможные
реакции пользователя.
Если
пользователь применяет программу для
решения задач в нетривиальных предметных
областях, в руководство пользователя
настоятельно рекомендуется включить
концептуальный раздел. В нем должен
быть описан реализованный в программе
способ представления объектов реального
мира, чтобы пользователь хорошо понимал,
с какими из них и на каком уровне
абстракции он может работать.
Соседние файлы в папке Лекции_МПО_ч2
- #
- #
- #
- #
- #
- #