Руководство пользователя в тех задании

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

Требования настоящего документа применяются при:

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

1.2. Краткое описание возможностей

Информационно-аналитическая система Корпоративное Хранилище Данных (ИАС КХД) предназначена для оптимизации технологии принятия тактических и стратегических управленческих решений конечными бизнес-пользователями на основе информации о всех аспектах финансово-хозяйственной деятельности Компании.

ИАС КХД предоставляет возможность работы с регламентированной и нерегламентированной отчетностью.

При работе с отчетностью используется инструмент пользователя Oracle Discoverer Plus, который предоставляет следующие возможности:

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

1.3. Уровень подготовки пользователя

Пользователь ИАС КХД должен иметь опыт работы с ОС MS Windows (95/98/NT/2000/XP), навык работы с ПО Internet Explorer, Oracle Discoverer, а также обладать следующими знаниями:

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

Квалификация пользователя должна позволять:

• формировать отчеты в Oracle Discoverer Plus;
• осуществлять анализ данных.

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

• Информационно-аналитическая система «Корпоративное хранилище данных». ПАСПОРТ;
• Информационно-аналитическая система «Корпоративное хранилище данных». ОБЩЕЕ ОПИСАНИЕ СИСТЕМЫ.

Oracle Discoverer Plus в составе ИАС КХД предназначен для автоматизации подготовки, настройки отчетных форм по показателям деятельности, а также для углубленного исследования данных на основе корпоративной информации хранилища данных.

Работа с Oracle Discoverer Plus в составе ИАС КХД возможна всегда, когда есть необходимость в получении информации для анализа, контроля, мониторинга и принятия решений на ее основе.

Работа с Oracle Discoverer Plus в составе ИАС КХД доступна всем пользователям с установленными правами доступа.

3.1. Состав и содержание дистрибутивного носителя данных

Для работы с ИАС КХД необходимо следующее программное обеспечение:

1. Internet Explorer (входит в состав операционной системы Windows);
2. Oracle JInitiator устанавливается автоматически при первом обращении пользователя к ИАС КХД.

3.2. Порядок загрузки данных и программ

Перед началом работы с ИАС КХД на рабочем месте пользователя необходимо выполнить следующие действия:

1. Необходимо зайти на сайт ИАС КХД ias-dwh.ru.
2. Во время загрузки в появившемся окне «Предупреждение о безопасности», которое будет содержать следующее: ‘Хотите установить и выполнить «Oracle JInitiator» …’ Нажимаем на кнопку «Да».
3. После чего запуститься установка Oracle JInitiator на Ваш компьютер. Выбираем кнопку Next и затем OK.

3.3. Порядок проверки работоспособности

Для проверки доступности ИАС КХД с рабочего места пользователя необходимо выполнить следующие действия:

1. Открыть Internet Explorer, для этого необходимо кликнуть по ярлыку «Internet Explorer» на рабочем столе или вызвать из меню «Пуск».
2. Ввести в адресную строку Internet Explorer адрес: ias-dwh.ru и нажать «Переход».
3. В форме аутентификации ввести пользовательский логин и пароль. Нажать кнопку «Далее».
4. Убедиться, что в окне открылось приложение Oracle Discoverer Plus.

В случае если приложение Oracle Discoverer Plus не запускается, то следует обратиться в службу поддержки.

4.1. Выполняемые функции и задачи

Oracle Discoverer Plus в составе ИАС КХД выполняет функции и задачи, приведенные в таблице ниже:

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

Ниже приведено описание пользовательских операций для выполнения каждой из задач.

Задача: «Визуализация отчетности»

Операция 1: Регистрация на портале ИАС КХД

Условия, при соблюдении которых возможно выполнение операции:

1. Компьютер пользователя подключен к корпоративной сети.
2. Портал ИАС КХД доступен.
3. ИАС КХД функционирует в штатном режиме.

Подготовительные действия:

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

Основные действия в требуемой последовательности:

1. На иконке «ИАС КХД» рабочего стола произвести двойной щелчок левой кнопкой мышки.
2. В открывшемся окне в поле «Логин» ввести имя пользователя, в поле «Пароль» ввести пароль пользователя. Нажать кнопку «Далее».

Заключительные действия:

Не требуются.

Ресурсы, расходуемые на операцию:

15-30 секунд.

Операция 2: Выбор отчета

Условия, при соблюдении которых возможно выполнение операции:

Успешная регистрация на Портале ИАС КХД.

Подготовительные действия:

Не требуются.

Основные действия в требуемой последовательности:

1. В появившемся окне «Мастер создания рабочих книг» поставить точку напротив пункта «Открыть существующую рабочую книгу».

2. Выбрать нужную рабочую книгу и нажать кнопку «Откр.»:

Заключительные действия:

После завершения работы с отчетом необходимо выбрать пункт меню «Файл», далее выбрать пункт «Закрыть».

Ресурсы, расходуемые на операцию:

15 секунд.

Задача: «Формирование табличных и графических форм отчетности»

Заполняется по аналогии.

В случае возникновения ошибок при работе ИАС КХД, не описанных ниже в данном разделе, необходимо обращаться к сотруднику подразделения технической поддержки ДИТ (HelpDesk) либо к ответственному Администратору ИАС КХД.

Рекомендуемая литература:

• Oracle® Business Intelligence Discoverer Viewer User’s Guide
• Oracle® Business Intelligence Discoverer Plus User’s Guide

Рекомендуемые курсы обучения:

• Discoverer 10g: Создание запросов и отчетов

В качестве контрольного примера рекомендуется выполнить операции задачи «Визуализация отчетности», описанные в п. 4.2. настоящего документа.

Ниже представлен пример (образец) документа «Руководство пользователя«, разработанного на основании методических указаний РД 50-34.698-90.

Данный документ формируется IT-специалистом, или функциональным специалистом, или техническим писателем в ходе разработки рабочей документации на систему и её части на стадии «Рабочая документация».

Для формирования руководства пользователя в качестве примера был взят инструмент Oracle Discoverer информационно-аналитической системы «Корпоративное хранилище данных».

Ниже приведен состав руководства пользователя в соответствии с ГОСТ. Внутри каждого из разделов кратко приведены требования к содержанию и текст примера заполнения (выделен вертикальной чертой).

Разделы руководства пользователя:

1. Введение.
2. Назначение и условия применения.
3. Подготовка к работе.
4. Описание операций.
5. Аварийные ситуации.
6. Рекомендации по освоению.

1. Введение

В разделе «Введение» указывают:

1. область применения;
2. краткое описание возможностей;
3. уровень подготовки пользователя;
4. перечень эксплуатационной документации, с которой необходимо ознакомиться пользователю.

2. Назначение и условия применения Oracle Discoverer Plus

В разделе «Назначение и условия применения» указывают:

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

3. Подготовка к работе

В разделе «Подготовка к работе» указывают:

1. состав и содержание дистрибутивного носителя данных;
2. порядок загрузки данных и программ;
3. порядок проверки работоспособности.

4. Описание операций

В разделе «Описание операций» указывают:

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

Для каждой операции обработки данных указывают:

1. наименование;
2. условия, при соблюдении которых возможно выполнение операции;
3. подготовительные действия;
4. основные действия в требуемой последовательности;
5. заключительные действия;
6. ресурсы, расходуемые на операцию.

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

5. Аварийные ситуации

В разделе «Аварийные ситуации» указывают: 1. действия в случае несоблюдения условий выполнения технологического процесса, в том числе при длительных отказах технических средств; 2. действия по восстановлению программ и/или данных при отказе магнитных носителей или обнаружении ошибок в данных; 3. действия в случаях обнаружении несанкционированного вмешательства в данные; 4. действия в других аварийных ситуациях.

6. Рекомендации по освоению

В разделе «Рекомендации по освоению» указывают рекомендации по освоению и эксплуатации, включая описание контрольного примера, правила его запуска и выполнения.

Сравнительный анализ структур руководств пользователя программы по ЕСПД и IEEE Std 1063-2001 с учетом рекомендаций «манифеста Кагарлицкого». Показано, что обобщенная структура руководства пользователя, собранная согласно требованиям «устаревших» ГОСТов 19-й системы, существенно превосходит структуру руководства, рекомендуемую суперсовременным IEEE Std 1063-2001. Редакция от 23.01.2022.

Создан 11.02.2005 11:14:22

Когда умирает надежда, приходит отчаяние.

Мудрая латинская поговорка

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

Где взять структуру разделов руководства пользователя? С руководствами на изделия (руководство по эксплуатации по ГОСТ 2.601-95) и на автоматизированные системы (руководство пользователя по РД 50-34.698-90) все более или менее ясно. А вот сам документ «Руководство пользователя» программы в ГОСТах 19-й системы отсутствует как класс.

Каким содержимым наполнять разделы руководства пользователя? Как быть? Главное — не отчаиваться.

Цели и задачи статьи

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

Задачи:

• проанализировать существующие стандарты и рекомендации по разработке эксплуатационной программной документации, выявить достоинства и недостатки каждого документа по отдельности;
• вывести некую обобщенную структуру руководства пользователя по ГОСТам 19-й системы из имеющегося набора эксплуатационных программных документов;
• сравнить ее со структурой, рекомендованной IEEE Std 1063-2001;
• а все прочие задачи перекочевали во 2-ю часть статьи…

Примечание от 10.07.2014 г. — В феврале 2005 года был проведен, пожалуй, даже не сравнительный анализ, а скорее сравнительные испытания, показавшие неоспоримое превосходство ГОСТов 19-й системы стандартов над буржуйскими и практически полную несостоятельность последних.

Вопросы, на которые должно дать ответы руководство пользователя

Подарите ребенку незнакомую ему электронную игрушку. Перечень вопросов будет примерно таким (если сразу же не разломает):

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

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

Руководство пользователя: четыре источника и четыре составных части

Располагаем документами:

• «метагайдом» Кагарлицкого;
• суперсовременным IEEE Std 1063-2001, «IEEE Standard for Software User Documentation»;
• классическими отечественными ГОСТами 19-й системы, включающим в себя перечисленные ниже документы «описательного» характера:
  • ГОСТ 19.402-78 ЕСПД. Описание программы;
  • ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению;
  • ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению;
  • ГОСТ 19.504-79 ЕСПД. Руководство программиста. Требования к содержанию и оформлению;
  • ГОСТ 19.505-79 ЕСПД. Руководство оператора. Требования к содержанию и оформлению.

Крайняя четверка из перечня — эксплуатационные программные документы.

Возможно, существуют и иные документы, но автору, основательно порывшемуся в рунетовской свалке, ничего более подходящего заполучить пока не удалось. Яндекс обнаружил в своих недрах еще одну страничку с названием «Как сделать хорошее руководство пользователя», автор которой именует себя на американЬский манер (типа John P. Morgan). Двухстраничное «наставление» с радостными возгласами было немедленно отправлено в корзину.

Манифест Кагарлицкого

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

(цитаты из манифеста Кагарлицкого)

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

Начало обнадеживающее.

В состав технической документации входят две стержневые части, которые мы будем называть соответственно руководством пользователя и справочником пользователя, или коротко: руководством и справочником (по аналогии с английскими словосочетаниями User’s Guide и User’s Reference). Они могут быть оформлены в виде отдельных документов (для крупных программных продуктов), а могут, напротив, существовать в интегрированном виде. Между ними даже может не быть четкой границы: единый текст способен совмещать в себе черты руководства и черты справочника.

Что-то не так. Автору статьи всегда «казалось», что термин техническая документация трактуется более широко, значительно шире, чем эксплуатационная (программная) документация.

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

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

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

На небосклоне засияла звезда по имени Надежда — сейчас уважаемый г-н Кагарлицкий выдаст нам, лишенцам, всеобъемлющую иерархическую структуру руководства пользователя всех времен и народов. Ну же?!

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

Жаль… А так все хорошо начиналось. Со «стандартов ГОСТ» — «стандартов ГОсударственных СТандартов» — простим г-на Кагарлицкого за тавтологию. Только вот решения первой задачи, поставленной автором настоящей статьи, в семидесятидвухстраничном манифесте (Arial’ом 12pt) нет. Уважаемый автор манифеста лишь поставил нам задачу. Что ж, нет пророка в своем отечестве. Может, есть пророк в отечестве буржуйском?

Руководство пользователя по IEEE Std 1063-2001 «IEEE Standard for Software User Documentation»

Забугорный «пророческий» документ IEEE Std 1063-2001 (IEEE в простонародье — «ай-яй-яй») в подразделе 1.2 (Puprose) содержит такую строчку:

This revision provides requirements for the structure, information content, and format of both printed and electronic documentation.

В авторском понимании назначение (намерение, цель, замысел, стремление) документа IEEE Std 1063-2001 состоит в «обеспечении требований к структуре, информационному наполнению, форматированию (оформлению) как электронной, так и печатной пользовательской документации по программным средствам». Что ж, подходяще. Какую же структуру руководства пользователя предлагает IEEE Std 1063-2001?

Структура руководства пользователя по IEEE Std 1063-2001

Опциональная типовая структура руководства пользователя содержится в таблице из раздела Structure of software user documentation документа IEEE Std 1063-2001:

For purposes of this standard, the following non-mandatory nomenclature is used for the structural parts of software user documentation. A printed document is structured into logical units called chapters, subdivided into topics, which may be subdivided into subtopics, and printed on physical units called pages.

Здорово. IEEE Std 1063-2001 предлагает «все взять и поделить» — разбить разделы руководства на главы, топики, субтопики и т.д. И наступит всем счастье.

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

Introduction

Какие сведения должны быть изложены в разделе Introduction согласно IEEE Std 1063-2001? А вот какие

The introduction shall describe the intended audience, scope, and purpose for the document and include a brief overview of the software purpose, functions, and operating environment.

Что ж, замечательно. Структура подразделов Introduction начинает как-то вырисовываться.

Information for use of the documentation

The documentation shall include information on how it is to be used (for example, help on help), and an explanation of the notation (a description of formats and conventions-see 5.8). At least one document in a document set shall identify all documents in the set by title and intended use, including recommendations on which members of the audience should consult which sections of the documentation. In document sets comprising many volumes or products, this information may be provided in a separate «road map» or guide to the document set. Documentation may include identification and discussion of notable changes from the previous version of the document set and the software.

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

Concept of operations

Documentation shall explain the conceptual background for use of the software, using such methods as a visual or verbal overview of the process or workflow; or the theory, rationale, algorithms, or general concept of operation. Explanations of the concept of operation should be adapted to the expected familiarity of the users with any specialized terminology for user tasks and software functions. Documentation shall relate each documented function to the overall process or tasks. Conceptual information may be presented in one section or immediately preceding each applicable procedure.

Концептуальная информация безусловно важна.

Procedures

Task-oriented instructional mode documentation shall include instructions for routine activities that are applied to several functions:

— Software installation and de-installation, if performed by the user

— Orientation to use of the features of the graphical user interface (see 5.6)

— Access, or log-on and sign-off the software

— Navigation through the software to access and to exit from functions

— Data operations (enter, save, read, print, update, and delete)

— Methods of canceling, interrupting, and restarting operations

These common procedures should be presented once to avoid redundancy when they are used in more complex functions.

И пошла конктерика. Молодцы, буржуи!

Information on software commands

Documentation shall explain the formats and procedures for user-entered software commands, including required parameters, optional parameters, default options, order of commands, and syntax. Documentation may be provided on the development and maintenance of macros and scripts. Reference mode documentation shall contain a reference listing of all reserved words or commands. Examples should illustrate the use of commands. Documentation shall explain how to interrupt and undo operation during execution of a command and how to restart it, if possible. Documentation shall describe how to recognize that the command has successfully executed or abnormally terminated.

Error messages and problem resolution

Documentation should address all known problems in using the software in sufficient detail such that the users can either recover from the problems themselves or clearly report the problem to technical support personnel. Reference mode documentation shall include each error message with an identification of the problem, probable cause, and corrective actions that the user should take. A quick reference card may address error messages by referring the user to more detailed reference documentation. The documentation on resolving problems shall also include contact information for reporting problems with software or its documentation and suggesting improvements.

Выводы по IEEE Std 1063-2001

Но счастье оказалось неполным… Структура разделов первого уровня руководства показана в таблице явно. А дальше — «милый мой, хороший, догадайся сам» («догадайся, мол, сама»). IEEE Std 1063-2001, конечно, «provides requirements for the structure», но не предлагает явной структуры руководства пользователя до рекомендованного ГОСТ 2.105 четвертого уровня вложенности.

Рекомендации типа «Documentation shall explain…», «Examples should illustrate…», «Documentation shall describe…» и им подобные, безусловно, проверены временем. В руководстве пользователя надо и объяснять, и иллюстрировать, и описывать — без всякого сомнения. Но все это и козе понятно, и в ГОСТах 19-й системы прописано.

Итак, вряд ли целесообразно разрабатывать руководства пользователя, основываясь исключительно на рекомендациях IEEE Std 1063-2001. Причины, как минимум, две:

• отсутствие в IEEE Std 1063-2001 четко регламентированной структуры руководства пользователя;
• «поверхностность» IEEE Std 1063-2001, отсутствие «широты охвата» и «глубины проработки».

Отсутствие четко регламентированной структуры руководства пользователя даст возможность заказчику ТРЕТИРОВАТЬ разработчика, см. хотя бы Страшная правда о техническом задании. Бедняга-разработчик будет вынужден, по указке заказчика, изо дня в день менять местами разделы руководства пользователя (гарантированный минимум, полученный опытным путем).

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

По мнению автора, рекомендации IEEE Std 1063-2001, разработанного при участии сотни забугорных спецов, весьма и весьма поверхностны. Не сможет разработчик, работая по IEEE Std 1063-2001, охватить максимум «характеристик», свойственных программе. В IEEE Std 1063-2001 многие из них попросту не прописаны. Отсутствуют «широта охвата» и «глубина проработки», свойственные отечественным документам.

В крайнем разделе настоящей статьи приведена таблица соответствия ГОСТ 19 и IEEE Std 1063-2001, которую автор статьи начал было составлять, затем бросил и проверять не стал. А выводы пусть каждый сделает сам для себя. И, возможно, в чем-то поправит автора.

Пользовательские документы по ГОСТ 19 (ЕСПД)

В отличие от суперсовременного буржуйского IEEE Std 1063-2001, древние, многими ругаемые отечественные стандарты 19-й системы (Единая система программной документации — ЕСПД) содержат не пространные рассуждения о том, что и как должно разъяснять, иллюстрировать и описывать руководство пользователя, а конкретные требования к структуре и содержанию пользовательских (эксплуатационных) документов.

Перечень ГОСТов 19 «описательного» характера, на основе которых можно, не мудрствуя лукаво, сформировать четкую структуру разделов каждого из «описательных» документов, приведен в разделе Источники. Основной прием — детализация — подробно описан в статье «Как писать техническое задание?!». Далее — сформированные «детализацией» структуры разделов документов согласно ГОСТам из перечня.

Структура разделов описания программы по ГОСТ 19.402-78

Структура разделов описания применения по ГОСТ 19.502-78

Структура разделов руководства системного программиста по ГОСТ 19.503-79

Структура разделов руководства программиста по ГОСТ 19.504-79

Структура разделов руководства оператора по ГОСТ 19.505-79

Выводы по ГОСТам 19.ххх

Ни ГОСТ 19.505-79, ни ГОСТ 19.504-79, ни ГОСТ 19.503-79, взятые по одельности, не могут похвастаться достаточной полнотой структуры.

Зато структуры «описательных» документов ГОСТ 19 обладают как полностью идентичными (по тексту названий), так и схожими по тексту названий разделами и подразделами. К идентичным разделам относятся, к примеру, разделы «Аннотация», имеющие место во всех документах согласно ГОСТ 19.105-78. К схожим (фактически — идентичным) можно отнести подразделы «Назначение программы» и «Сведения о назначении программы».

А почему не попытаться объединить все «описательные» документы? Объединить идентичные и схожие разделы документов, выделить специфические разделы? Быть может, удастся избавиться от неполноты ГОСТ 19.505-79, ГОСТ 19.504-79 и ГОСТ 19.503-79 и получить обобщенную структуру «описательного» документа и обозвать сам документ руководством пользователя программы?

ГОСТы 19.ххх допускают «вводить дополнительные разделы или объединять отдельные разделы», а также «вводить новые». Согласно ГОСТ 19.101-77 «Допускается объединять отдельные виды эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра). Необходимость объединения этих документов указывается в техническом задании. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов. В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ [из 2.6 ГОСТ 19.101-77]»

Сказано — сделано. Только мы нарушим ГОСТы и создадим объединенный документ под названием «Руководство пользователя».

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

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

Выводы по обобщенной структуре руководства пользователя по ГОСТ 19.ххх

Обобщенная структура руководства пользователя по ГОСТ 19.ххх явно не страдает, как IEEE Std 1063-2001, отсутствием широты охвата. Избыток, как известно, рождает качество. Перечислено все, чем может характеризоваться программа. Отдельные подразделы могут показаться даже излишними, к примеру, подраздел «Языки программирования, на которых написана программа».

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

В то же время, при всей широте охвата, в явном виде отсутствуют:

• Software installation and de-installation, if performed by the user;
• Orientation to use of the features of the graphical user interface;
• Access, or log-on and sign-off the software;
• Navigation through the software to access and to exit from functions и многое другое.

Автору удалось разбросать кое-что в разделе Таблица соответствия ГОСТ 19.ххх и IEEE Std 1063-2001, но времени «наморщить ум» всегда не хватает, руководство пользователя, как всегда, должно было быть готово еще на прошлой неделе.

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

Выводы по источникам

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

Автор манифеста более склонен к рекомендациям по подбору слов* и построению предложений, IEEE Std 1063-2001, в лучшем случае, приводит требования к структуре руководства пользователя, но не дает особой конкретики, в ГОСТ 19.ххх не прописаны процедуры заполнения содержимым разделов руководства. Может, организовать эдакую смесь французского с нижегородским? Использовать все четыре источника в качестве четырех составных частей?

* Нынче в моде буржуйское понятие — т.н. контролируемый язык. Среди представителей «просвещенной русской интеллигенции» наибольшей популярностью пользуется отечественный аналог в глагольной форме повелительного наклонения — фильтруй базар!

Смесь французского с нижегородским

Почему бы нет? Взять лучшее из ГОСТов 19-й системы, — обобщенную структуру руководства пользователя, добавить к ней немногочисленные толковые рекомендации из IEEE Std 1063-2001 и разбавить неисчерпаемой стилистической культурой и ресурсами языка из манифеста Кагарлицкого? Придать смеси стройный строгий вид, сформировать очередной учебно-тренировочный документ с подробными комментариями? А что делать, если ни один из перечисленных выше источников и составных частей в отдельности не способны дать ответы на все поставленные вопросы?

Таблица соответствия ГОСТ 19 и IEEE Std 1063-2001

Практическая работа №13

Тема: Руководство пользователя.                                                                    

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

Теоретические
сведения.

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

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

Содержание

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

·       
Аннотацию, в
которой приводится краткое изложение содержимого документа и его назначение

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

·       
Страницу
содержания

·       
Главы,
описывающие, как использовать, по крайней мере, наиболее важные функции
системы

·       
Главу, описывающую
возможные проблемы и пути их решения

·       
Часто
задаваемые вопросы и ответы
на них

·       
Где
ещё найти информацию по предмету, контактная информация

·       
Глоссарий и, в
больших документах, предметный указатель

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

Стандарты

Структура и
содержание документа Руководство пользователя автоматизированной
системы регламентированы подразделом 3.4 документа РД 50-34.698-90. Структура и
содержание документов Руководство оператора, Руководство
программиста, Руководство системного программиста регламентированы
ГОСТ 19.505-79, ГОСТ 19.504-79 и ГОСТ 19.503-79 соответственно.

·       
Комплекс
стандартов и руководящих документов на автоматизированные системы (ГОСТ 34)

·     РД
50-34.698-90 АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ

·       
Единая система конструкторской документации (ЕСКД)
определяет документ «Руководство по эксплуатации» и другие документы:

·     ГОСТ
2.601-2013 Эксплуатационные документы

·     ГОСТ
2.610-2006 Правила выполнения эксплуатационных документов

·       
Единая
система программной документации (ЕСПД)
определяет документы «Руководство оператора», «Руководство по техническому обслуживанию»
и их структуру:

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

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

·     ГОСТ
19.505-79 Руководство оператора. Требования к содержанию и оформлению

·     ГОСТ
19.508-79 Руководство по техническому обслуживанию. Требования к содержанию и
оформлению.

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

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

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

Руководящими
стандартами для создания документа Руководство пользователя  могут
являться как РД
50-34.698-90 в п.п. 3.4. «Руководство пользователя», так
и ГОСТ
19.505-79 «Руководство оператора. Требования к содержанию и оформлению». Ниже для
сравнения приведены структуры документа согласно двум перечисленным стандартам.

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

ü Назначение
системы;

ü Условия применения
системы;

ü Подготовка системы
к работе;

ü Описание операций;

ü Аварийные
ситуации.

Назначение системы

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

Пример:

«Корпоративный
интранет портал предназначен для повышения корпоративной культурыр организации
эффективного взаимодействия сотрудников.  

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

Условия
применения системы

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

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

Квалификация
пользователя – данный подраздел должен содержать требования к навыкам и знаниям
пользователя (пример: «Пользователи должны обладать навыками работы с
операционной системой Windows XP»);

Подготовка
системы к работе

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

Описание
операций

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

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

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

Пример:

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

4.1.1
 Создание проекта. Для того чтобы создать Проект необходимо на панели «…»
нажать на кнопку «…» и в появившейся форме заполнить следующие поля:

Наименование
проекта;

Описание
проекта;

Следующие
поля заполняются автоматически:

Дата
создания проекта – текущая дата;

Автор –
ИФО и должность автора проекта.»

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

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

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

Аварийные
ситуации

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

Ниже представлен пример (образец)
документа «Руководство пользователя«, разработанного на
основании методических указаний РД
50-34.698-90.

Данный документ формируется
IT-специалистом, или функциональным специалистом, или техническим писателем в
ходе разработки рабочей документации на систему и её части на стадии «Рабочая
документация».

Для формирования руководства пользователя
в качестве примера был взят инструмент Oracle Discoverer информационно-аналитической
системы «Корпоративное хранилище данных».

Ниже приведен состав руководства
пользователя в соответствии с ГОСТ. Внутри каждого из разделов кратко приведены требования к
содержанию и текст примера заполнения (выделен вертикальной
чертой).

Разделы руководства пользователя:

1.     
Введение.

2.     
Назначение и
условия применения.

3.     
Подготовка к
работе.

4.     
Описание операций.

5.     
Аварийные
ситуации.

6.     
Рекомендации по
освоению.

1. Введение

В разделе «Введение»
указывают:

1.     
область применения;

2.     
краткое
описание возможностей;

3.     
уровень
подготовки пользователя;

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

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

Требования настоящего документа
применяются при:

·  предварительных комплексных
испытаниях;

·  опытной эксплуатации;

·  приемочных испытаниях;

·  промышленной эксплуатации.

1.2. Краткое описание возможностей

Информационно-аналитическая
система Корпоративное Хранилище Данных (ИАС КХД) предназначена для оптимизации
технологии принятия тактических и стратегических управленческих решений
конечными бизнес-пользователями на основе информации о всех аспектах
финансово-хозяйственной деятельности Компании.

ИАС КХД предоставляет возможность
работы с регламентированной и нерегламентированной отчетностью.

При работе с отчетностью
используется инструмент пользователя Oracle Discoverer Plus, который
предоставляет следующие возможности:

·  формирование табличных и
кросс-табличных отчетов;

·  построение различных диаграмм;

·  экспорт и импорт результатов
анализа;

·  печать результатов анализа;

·  распространение результатов
анализа.

1.3. Уровень подготовки
пользователя

Пользователь ИАС КХД должен иметь
опыт работы с ОС MS Windows (95/98/NT/2000/XP), навык работы с ПО Internet
Explorer, Oracle Discoverer, а также обладать следующими знаниями:

·  знать соответствующую предметную
область;

·  знать основы многомерного анализа;

·  понимать многомерную модель
соответствующей предметной области;

·  знать и иметь навыки работы с
аналитическими приложениями.

Квалификация пользователя должна
позволять:

·  формировать отчеты в Oracle
Discoverer Plus;

·  осуществлять анализ данных.

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

·  Информационно-аналитическая
система «Корпоративное хранилище данных». ПАСПОРТ;

·  Информационно-аналитическая
система «Корпоративное хранилище данных». ОБЩЕЕ ОПИСАНИЕ СИСТЕМЫ.

2. Назначение и условия применения
Oracle Discoverer Plus

В разделе «Назначение и
условия применения» указывают:

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

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

Oracle Discoverer Plus в составе
ИАС КХД предназначен для автоматизации подготовки, настройки отчетных форм по
показателям деятельности, а также для углубленного исследования данных на
основе корпоративной информации хранилища данных.

Работа с Oracle Discoverer Plus в
составе ИАС КХД возможна всегда, когда есть необходимость в получении
информации для анализа, контроля, мониторинга и принятия решений на ее основе.

Работа с Oracle Discoverer Plus в
составе ИАС КХД доступна всем пользователям с установленными правами доступа.

3. Подготовка к работе

В разделе «Подготовка к работе»
указывают:

1.     
состав и
содержание дистрибутивного носителя данных;

2.     
порядок
загрузки данных и программ;

3.     
порядок
проверки работоспособности.

3.1. Состав и содержание
дистрибутивного носителя данных

Для работы с ИАС КХД необходимо
следующее программное обеспечение:

1.     
Internet
Explorer (входит в состав операционной системы Windows);

2.     
Oracle
JInitiator устанавливается автоматически при первом обращении пользователя к
ИАС КХД.

3.2. Порядок загрузки данных и
программ

Перед началом работы с ИАС КХД на
рабочем месте пользователя необходимо выполнить следующие действия:

1.     
Необходимо
зайти на сайт ИАС КХД ias-dwh.ru.

2.     
Во время
загрузки в появившемся окне «Предупреждение о безопасности», которое
будет содержать следующее: ‘Хотите установить и выполнить «Oracle JInitiator»
…’ Нажимаем на кнопку «Да».

3.     
После чего
запуститься установка Oracle JInitiator на Ваш компьютер. Выбираем кнопку Next
и затем OK.

3.3. Порядок проверки
работоспособности

Для проверки доступности ИАС КХД с
рабочего места пользователя необходимо выполнить следующие действия:

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

2.     
Ввести в
адресную строку Internet Explorer адрес: ias-dwh.ru и нажать «Переход».

3.     
В форме аутентификации
ввести пользовательский логин и пароль. Нажать кнопку «Далее».

4.     
Убедиться, что
в окне открылось приложение Oracle Discoverer Plus.

В случае если приложение Oracle
Discoverer Plus не запускается, то следует обратиться в службу поддержки.

4. Описание операций

В разделе «Описание
операций» указывают:

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

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

Для каждой операции обработки
данных указывают:

1.     
наименование;

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

3.     
подготовительные
действия;

4.     
основные
действия в требуемой последовательности;

5.     
заключительные
действия;

6.     
ресурсы, расходуемые
на операцию.

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

4.1. Выполняемые функции и задачи

Oracle Discoverer Plus в составе
ИАС КХД выполняет функции и задачи, приведенные в таблице ниже:

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

Ниже приведено описание
пользовательских операций для выполнения каждой из задач.

Задача:
«Визуализация отчетности»

Операция 1: Регистрация на портале
ИАС КХД

Условия,
при соблюдении которых возможно выполнение операции:

1.     
Компьютер
пользователя подключен к корпоративной сети.

2.     
Портал ИАС КХД
доступен.

3.     
ИАС КХД
функционирует в штатном режиме.

Подготовительные
действия:

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

Основные
действия в требуемой последовательности:

1.     
На иконке «ИАС
КХД» рабочего стола произвести двойной щелчок левой кнопкой мышки.

2.     
В открывшемся
окне в поле «Логин» ввести имя пользователя, в поле «Пароль» ввести пароль пользователя.
Нажать кнопку «Далее».

Заключительные
действия:

Не требуются.

Ресурсы,
расходуемые на операцию:

15-30 секунд.

Операция 2: Выбор отчета

Условия,
при соблюдении которых возможно выполнение операции:

Успешная регистрация на Портале
ИАС КХД.

Подготовительные
действия:

Не требуются.

Основные
действия в требуемой последовательности:

1. В появившемся окне «Мастер
создания рабочих книг» поставить точку напротив пункта «Открыть существующую
рабочую книгу».

2. Выбрать нужную рабочую книгу и
нажать кнопку «Откр.»:

Заключительные действия:

После завершения работы с отчетом
необходимо выбрать пункт меню «Файл», далее выбрать пункт «Закрыть».

Ресурсы,
расходуемые на операцию:

15 секунд.

Задача:
«Формирование табличных и графических форм отчетности»

Заполняется по аналогии.

5. Аварийные ситуации

В разделе «Аварийные
ситуации» указывают: 1. действия в случае несоблюдения условий выполнения
технологического процесса, в том числе при длительных отказах технических
средств; 2. действия по восстановлению программ и/или данных при отказе
магнитных носителей или обнаружении ошибок в данных; 3. действия в случаях
обнаружении несанкционированного вмешательства в данные; 4. действия в других
аварийных ситуациях.

В случае возникновения ошибок при
работе ИАС КХД, не описанных ниже в данном разделе, необходимо обращаться к
сотруднику подразделения технической поддержки ДИТ (HelpDesk) либо к
ответственному Администратору ИАС КХД.

6. Рекомендации по освоению

В разделе «Рекомендации по
освоению» указывают рекомендации по освоению и эксплуатации, включая
описание контрольного примера, правила его запуска и выполнения.

Рекомендуемая литература:

·  Oracle® Business Intelligence Discoverer
Viewer User’s Guide

·  Oracle® Business Intelligence Discoverer
Plus User’s Guide

Рекомендуемые курсы обучения:

·  Discoverer 10g: Создание запросов
и отчетов

В качестве контрольного примера
рекомендуется выполнить операции задачи «Визуализация отчетности», описанные в
п. 4.2. настоящего документа.

Ход
работы:

Задание 1.
Изучите
свой вариант руководства пользователя. Опишите его по следующему плану:

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

2)
основные технические характеристики продукта;

3)
основные разделы руководства пользователя (название раздела и краткое его
описание)

Задание 2.
Откройте 
документ «Образец руководства пользователя», заполните в нем первые разделы для
своего вымышленного программного продукта.

Сделайте
вывод
о проделанной работе.

Контрольные
вопросы:

1) Дайте
определения понятиям «руководство пользователя», «инструкция по эксплуатации»

2) Какие
основные разделы должно содержать руководство пользователя?

3) Какие
стандарты описывают Руководство пользователя Руководство оператора, Руководство
программиста, Руководство системного программиста?

4) Что
описывает раздел «назначение системы»?

5) Что
указывается в разделе «условия применения системы»?

6) Какая
информация содержится в разделе «Описание операций»?

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

Приятного чтения.

Если перед вами стоит вопрос – нужно ли вашему продукту пользовательское руководство, то отвечу сразу – да, нужно. Почему? На это есть две причины:

1. Качественная документация повышает лояльность клиента и ценность продукта в целом.

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

2. Руководство пользователя экономит время и силы техподдержки.

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

А теперь к советам!

Общие советы по созданию руководства пользователя

Прежде чем начинать писать руководство пользователя нужно ответить на несколько вопросов. — Для кого вы пишите? Кто будет пользоваться файлом справки? (ваша целевая аудитория)

— Где скорее всего пользователи будут прибегать к документации? (дома, на работе, в машине)

— Насколько объективно сложен для понимания продукт и как часто пользователь будет обращаться к документации?

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

(Для изложения лучше всего выбрать нейтрально-формальный стиль)

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

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

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

В первом разделе расскажите общую информацию о продукте. Для чего создан проект и какие задачи он решает.

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

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

В любом руководстве желательны разделы «Частые вопросы» и «Устранение типовых проблем». Расскажите о проблемах, с которыми часто сталкиваются клиенты и о путях их решения.

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

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

Профессиональный совет: если вы хотите максимально облегчить ношу клиента при чтении документации создайте контекстно-зависимую справку. Что это такое?

Представьте, что вы работаете в программе для создания пользовательской документации. Открываете меню основных настроек и видите раздел «аннотирование экрана» Заходите в него, там показаны разные стили аннотации, тени, фон и так далее. Но что такое аннотация? Допустим вы не знаете — нажимаете кнопку F1 и перед вами открывается руководство именно на той странице, где рассказано об «аннотировании экрана»

Как ее сделать? Смотрите ниже.

Контент

И так, мы создали «каркас» нашей документации, но чтобы руководство стало полезным нужно наполнить её компетентной информацией.

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

1. Понятность.

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

2. Наглядность.

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

3. Видео.

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

Но как добавить в документацию видео? Смотрите ниже.

Больше советов!

Когда документация будет готова, чтобы она стала «полноценной» её нужно опубликовать. Иначе какой от неё толк, если клиент не может её прочитать. У «юзера» всегда должен быть доступ к документации, и не важно где он. Такую потребность легко закрывают три формата: HTML, PDF и CHM.

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

Выложите руководство на сайт в формате HTML, чтобы клиент мог обратиться к документации, даже не работая с программой. Кроме того, документация, выложенная на сайт, повышает SEO факторы сайта.

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

Но помните, что после публикации документации, придется иногда её обновлять.

Инструменты

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

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

Dr.Explain – программа для создания руководств пользователя для ПО, web-сервисов и баз знаний.

Благодаря «доктору» вы сможете опубликовать и обновлять документацию в востребованных форматах (CHM; HTML; PDF; DOC), не выходя из программы.

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

Импортируйте в программу заранее написанные фрагменты документации.

Вы сможете создать контекстно-зависимую документацию, настроить визуальный стиль руководства, добавить в него видео и многое другое!

Какой можно сделать вывод

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

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

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

Спасибо за внимание!

Со всеми возможностями Dr.Explain можно ознакомиться здесь:

Руководство пользователя – это основной документ в составе эксплуатационной документации на автоматизированную систему (ГОСТ 34). Очевидно ли это?

Назначение руководства пользователя

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

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

Конкретный подход к написанию определяется многими факторами:

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

– сложностью программы;

– количеством разнообразных вариантов использования.

Принимая во внимание все различия и особенности, сложно привести структуру любого Руководства пользователя к одному виду. Тем не менее, РД 50-34.698 предлагает нам такой список разделов:

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

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

– Подготовка к работе, где описывают комплектность дистрибутива, порядок установки и загрузки программы, а также способ проверки ее работоспособности;

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

– Аварийные ситуации, где описывают действия в нештатных ситуациях – сбоях в программе, ошибок в данных и т.д.;

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

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

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

Наличие Руководства пользователя регламентируется ГОСТ 34.201, а структура и содержание – РД 50-34.698. Однако, в зависимости от сложности, назначения и области применения ПО, различные Руководства пользователя могут отличаться друг от друга по способу, методике и стилю изложения.

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

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

Возможно, вас также заинтересует:

– разработка руководства администратора;
– создание руководства программиста;
– разработка руководства оператора.

Стандарты и шаблоны для ТЗ на разработку ПО

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы рекомендует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

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

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

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

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:

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

Согласно стандарту техническое задание должно включать следующие разделы:

1. Введение

• 1. Назначение
• 2. Область действия
• 3. Определения, акронимы и сокращения
• 4. Ссылки
• 5. Краткий обзор

2. Общее описание

• 1. Взаимодействие продукта (с другими продуктами и компонентами)
• 2. Функции продукта (краткое описание)
• 3. Характеристики пользователя
• 4. Ограничения
• 5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

• 1. Требования к внешним интерфейсам
  • 1. Интерфейсы пользователя
  • 2. Интерфейсы аппаратного обеспечения
  • 3. Интерфейсы программного обеспечения
  • 4. Интерфейсы взаимодействия
• 2. Функциональные требования
• 3. Требования к производительности
• 4. Проектные ограничения (и ссылки на стандарты)
• 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
• 6. Другие требования

4. Приложения
5. Алфавитный указатель

На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который легко найти в Интернете. Как и примеры, правда, на англ. языке.

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

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

Данный стандарт содержит два шаблона спецификации требований:

• System requirements specification (SyRS)
• Software requirements specification (SRS)

System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 34.

SyRS может содержать следующие разделы:

1. Введение

• 1. Назначение системы
• 2. Содержание системы (границы системы)
• 3. Обзор системы
  • 1. Содержание системы
  • 2. Функции системы
  • 3. Характеристики пользователей
• 4. Термины и определения

2. Ссылки

3. Системные требования

• 1. Функциональные требования
• 2. Требования к юзабилити
• 3. Требования к производительности
• 4. Интерфейс (взаимодействие) системы
• 5. Операции системы
• 6. Состояния системы
• 7. Физические характеристики
• 8. Условия окружения
• 9. Требования к безопасности
• 10. Управление информацией
• 11. Политики и правила
• 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
• 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

5. Приложения

• 1. Предположения и зависимости
• 2. Аббревиатуры и сокращений

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

SRS может содержать следующие разделы:

1. Введение

• 1. Назначение
• 2. Содержание (границы)
  • 3. Обзор продукта
  • 1. Взаимодействие продукта (с другими продуктами и компонентами)
  • 2. Функции продукта (краткое описание)
  • 3. Характеристики пользователей
  • 4. Ограничения
• 4. Термины и определения

2. Ссылки

3. Детальные требования

• 1. Требования к внешним интерфейсам
• 2. Функции продукта
• 3. Требования к юзабилити
• 4. Требования к производительности
• 5. Требования к логической структуре БД
• 6. Ограничения проектирования
• 7. Системные свойства ПО
• 8. Дополнительные требования

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

5. Приложения

• 1. Предположения и зависимости
• 2. Аббревиатуры и сокращений

Данный стандарт достаточно сложно найти в открытом виде в Интернете, но постараться можно, и опять же только на англ.

RUP

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.
• Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):

1. Введение.

• 1. Цель.
• 2. Краткая сводка возможностей.
• 3. Определения, акронимы и сокращения.
• 4. Ссылки.
• 5. Краткое содержание.

2. Обзор системы

• 1. Обзор вариантов использований.
• 2. Предположения и зависимости.

3. Детальные требований

• 1. Описание вариантов использования.
• 2. Дополнительные требования.
• 3. Другие функциональные требования.
• 4. Нефункциональные требования.

4. Вспомогательная информация.

Естественно, что в Интернете можно найти шаблон и примеры SRS от RUP.

SWEBOK, BABOK и пр.

SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.

А как же Agile?

Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.

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

Заключение

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

Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.

Ну а кто дочитал до конца — тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).

Также рекомендую ознакомиться со следующими материалами:

• Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях.
• Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований.
• Правила составления Software requirements specification (читать вместе с комментариями)
• Примеры ТЗ и другой документации по разработке АС для МЭР
• ГОСТ-овский стиль управления. Статья Gaperton по правильной работе с ТЗ по ГОСТ
• Шаблоны документов для бизнес-аналитиков из группы ВК «Business Analysis Magazine»

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

К основным
компонентам документа ТЭО
относятся:характеристика исходных
данных о предметной области; обоснование
цели создания ЭИС; обоснование комплекса
автоматизации задач, выбора комплекса
технических средств, программного и
информационного обеспечений; разработка
организационных мероприятий по
проектированию системы; предварительный
расчет и обоснование экономической
эффективности проекта; выводы о
возможности дальнейших разработок.
Документ техническое
задание (ТЗ),
является обязательным документом.ТЗ
разрабатывается
согласно ГОСТу 34.602. В состав ТЗ входят
следующие разделы:1. В разделе «Общие
сведения о проекте»
указывают: полное наименование системы,
код системы, код договора, наименования
предприятия-разработчика и
предприятия-заказчика, перечень
документов, на основе которых создается
система, плановые сроки начала и окончания
работ по созданию системы, сведения об
источниках финансирования, порядок
оформления и предъявления заказчику
результатов работ по созданию системы
(ее частей).

2.Раздел описания
«Назначение,
цели создания системы»
состоит из двух подразделов: — в подразделе
«Назначение
системы»
даются вид автоматизируемой деятельности
и перечень объектов автоматизации, на
которых предполагается ее использовать;
— в подразделе «Цели
создания системы» указываются
наименования и требуемые значения
технических, технологических,
производственно-экономических и других
показателей объекта автоматизации,
которые будут достигнуты в результате
внедрения ЭИС.

3. В разделе
«Характеристика
объекта автоматизации»
приводятся: краткие сведения об объекте
автоматизации; сведения об условиях
эксплуатации объекта и характеристиках
окружающей среды. 4.Раздел «Требования
к системе» состоит
из следующих подразделов: — В подразделе
«Требования
к системе в целом»
указывают: требования к структуре и
функционированию системы; к численности
квалифицированных работников; к
надежности и безопасности работы
системы; к эргономике и технической
эстетике, эксплуатации, техническому
обслуживанию, ремонту системы; к защите
информации от несанкционированного
доступа; требования по сохранности
информации при авариях; к защите от
внешней среды; к патентной чистоте
проектных решений; требования по
унификации и стандартизации. — В подразделе
«Требования
к функциям (задачам), выполняемым
системой»,
комплексам задач и отдельным задачам
приводят по каждой подсистеме перечень
функций, задач или
их комплексов,
подлежащих автоматизации; распределение
их по очередям создания; временной
регламент реализации каждой функции,
задачи или комплекса; требования к
качеству реализации каждой функции,
задачи, комплекса, к форме представления
выходной информации; характеристики
необходимой точности и времени выполнения,
достоверности выдачи результата. — В
подразделе «Требования
к видам обеспечения»
содержатся требования к математическому,
программному, техническому, информационному
и методическому обеспечению ЭИС. 5.Раздел
«Состав и
содержание работ по созданию системы»
должен
содержать: перечень стадий и этапов
работ по созданию системы в соответствии
с ГОСТ 34.601-90; сроки выполнения; перечень
организаций-исполнителей; перечень
документов по ГОСТ 34.201-89 «Виды,
комплектность и обозначение документов
при создании автоматизированных систем»,
предъявляемых по окончании работ; вид
и порядок проведения экспертизы
технической документации и др. 6.В разделе
«Порядок
контроля приемки системы»
указывают: виды, состав, методы испытания
системы и ее частей; общие требования
к приемке работ по стадиям; порядок
утверждения приемных документов; статус
приемочной комиссии. 7.В разделе
«Требования
к составу и содержанию работ по подготовке
объекта автоматизации к вводу системы
в действие» необходимо
привести перечень необходимых мероприятий
и их исполнителей, которые следует
выполнять при подготовке объекта к
вводу ЭИС в действие: приведение
информации, поступающей в систему, к
виду, пригодному для ввода в ЭВМ; создание
условий функционирования объекта, при
которых гарантируется соответствие
создаваемой системы требованиям,
содержащимся в ТЗ; создание необходимых
для функционирования системы подразделений
и служб; сроки и порядок комплектования
штатов и обучения персонала. 8.В разделе
«Требования
к документированию»
приводят: перечень подлежащих разработке
комплектов и видов документов,
соответствующих требованиям ГОСТ
34.201-89 и научно-технической документации
отрасли заказчика. 9.В разделе «Источники
разработки»
должны быть перечислены документы и
информационные материалы (ТЭО, отчеты
о законченных научно-исследовательских
разработках, информационные материалы
на отечественные, зарубежные системы-аналоги
и др.).

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

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

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

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

математической
модели; — экономико-математического
метода, применяемого для ее реализации;
— перечень последовательных шагов
выполнения расчетов.

Документ
«Руководство пользователя» содержит
разделы: введение;
назначение и условия применения;
подготовка к работе; описание операций;
аварийные ситуации; рекомендации по
освоению. 1. В разделе «Введение»
указывают:

область применения;
краткое описание возможностей; уровень
подготовки пользователя; перечень
эксплуатационной документации, с
которыми необходимо ознакомиться
пользователю. 2. В разделе «Назначение
и условия применения» указывают:
— виды деятельности, функции, для
автоматизации которых предназначено
данное средство автоматизации; — условия,
при соблюдении (выполнении, наступлении)
которых обеспечивается применение
средства автоматизации в соответствии
с назначением (например, вид ЭВМ и
конфигурация технических средств,
операционная среда и общесистемные
программные средства, входная информация,
носители данных, база данных, требования
к подготовке специалистов и т. п.). 3. В
разделе «Подготовка
к работе»
указывают: — состав и содержание
дистрибутивного носителя данных; —
порядок загрузки данных и программ; —
порядок проверки работоспособности.
4. В разделе «Описание
операций»
указывают: — описание всех выполняемых
функций, задач, комплексов задач,
процедур; — описание операций
технологического процесса обработки
данных, необходимых для выполнения
функций, комплексов задач (задач),
процедур. 5. Для каждой операции обработки
данных указывают: — наименование; —
условия, при соблюдении которых возможно
выполнение операции; — подготовительные
действия; — основные действия в требуемой
последовательности; — заключительные
действия; — ресурсы, расходуемые на
операцию.

В описании действий
допускаются ссылки на файлы подсказок,
размещенные на магнитных носителях. 6.
В разделе «Аварийные
ситуации» указывают:
— действия в случае несоблюдения условий
выполнения технологического процесса,
в том числе при длительных отказах
технических средств; — действия по
восстановлению программ и/или данных
при отказе магнитных носителей или
обнаружении ошибок в данных; — действия
в случаях обнаружении несанкционированного
вмешательства в данные; — действия в
других аварийных ситуациях.

7. В разделе
«Рекомендации
по освоению»
указывают рекомендации по освоению и
эксплуатации, включая описание
контрольного примера, правила его
запуска и выполнения.

Соседние файлы в папке ШПОРЫ — ГОТОВО

• #

  13.05.2015174.59 Кб38БД.doc

• #
• #
• #
• #
• #
• #