Как написать руководство пользователя программы или сайта — инструкции, советы, помощь, программное обеспечение
Журавлев Денис
Что такое руководство пользователя и для чего его создавать
Ежедневно создаются новые продукты, программы, сервисы и часто пользователям приходится несладко при освоении какой-нибудь сложной программы, поэтому каждому новому продукту желательно собственное руководство. Для чего?
Большинство людей не хочет разбираться с чем-то незнакомым без персонального, всегда доступного и понятного помощника. А именно им и является хорошее руководство пользователя.
Общие советы по созданию пользовательской документации
Перед тем как приступить к созданию руководства, нужно определиться с некоторыми важными моментами. Например, определить, для кого вы его пишете? Кто его будет читать — рядовые пользователи, для которых важны базовые функции продукта, или люди, которым нужны особые, нечасто используемые функции программы/сервиса.
После этого важно подумать о том:
- Где пользователь будет к нему обращаться: дома, на работе, в машине?
- Как часто он будет его просматривать?
- Насколько объективно сложен для понимания продукт?
Из этого можно сделать вывод, насколько интенсивно пользователь будет работать с документацией, а значит уже можно выбрать между сжатым «справочником» или объемным «путеводителем» Также важно, чтобы руководство писал профессионал, знающий продукт. Так что по возможности делегируйте написание техническому специалисту или аналитику, у которого есть полное представление о всех тонкостях продукта.
Определившись со всеми представленными пунктами, станет понятнее, какой нужно использовать стиль изложения, какого объема написать текст. Но помните, что излишне стилистически окрашенные слова мешают пользователю добраться до сути. Так что лучшим вариантом в большинстве случаев будет нейтрально-формальный стиль. Пишите так, чтобы пользователь вас понял. Постарайтесь по возможности избегать технических терминов, но проанализируйте — не сделает ли полное отсутствие терминов ваше руководство бесполезным?
Структура руководства пользователя
После того как вы ответили на предыдущие вопросы, создайте структуру руководства. У любого хорошего «путеводителя» хорошая и логичная структура. Начните с оглавления. Информативное содержание поможет читателю легко ориентироваться в документе.
В первом разделе желательно рассказать общую информацию о программе:
- Для чего создан продукт.
- Какие задачи он решает.
- Какие основные выгоды от использования для клиента.
В следующем разделе можно указать основные элементы пользовательского интерфейса. Пользователю будет трудно разобраться в софте, если он не поймёт для чего служат различные элементы интерфейса, или он не разберётся в основных режимах работы ПО. Опишите понятным языком предназначение экранов и окон.
Создайте раздел, где расскажете о наиболее эффективных способах применения продукта для решения типовых задач. Какие цели стоят перед клиентом, и как ваша программа/сервис помогает достичь их. Укажите информацию о том, как быстро и продуктивно пользоваться программой.
Ни одно руководство не обойдется без таких разделов как: «Частые вопросы» и «Устранение типовых проблем» В них разбираются вопросы и проблемы, с которыми часто сталкиваются пользователи. Для заполнения данного раздела вам скорее всего понадобятся уже готовые отзывы клиентов. Если у вас абсолютно новый продукт, вы можете предугадать проблемы ваших клиентов либо на первое время не включать данный пункт в ваше руководство.
Иногда технические писатели забывают о важном моменте в руководстве пользователя — контактная информация. Этот раздел поможет пользователям связаться с вами, даже если у них нет никаких вопросов и руководство полностью закрывает все их потребности. Клиент может дать совет, поделиться опытом или предложить выгодное вам сотрудничество.
Инструменты для быстрого создания руководства пользователя
Но как создать руководство пользователя, если пишешь его впервые? Или что делать, если руководство пользователя нужно постоянно обновлять и дорабатывать? Или нужны особые функции, которых нет в традиционных текстовых редакторах, например, в MS Word.
Одним из популярных инструментов для создания качественного руководства является программа Dr. Explain (https://www.drexplain.ru), в которой уже есть готовые шаблоны руководств пользователя с готовой структурой разделов и в которой удобно обновлять документацию, как бы часто эти обновления не происходили.
Видео-обзор основных возможностей программы Dr.Explain
Удобной особенностью инструмента является возможность экспортировать один и тот же документ в форматы: HTML, CHM, PDF. Простой и понятный интерфейс сам подскажет, как быстро просмотреть документ в различных форматах и настроить его под вывод в эти форматы.
Любой проект в Dr.Explain вы можете создать с нуля или импортировать уже существующую документацию, например из формата MS Word, HTML или CHM-файла, и буквально за несколько минут создать из нее онлайн-помощь, файл справки в формате CHM, или документ в формате PDF.
При создании руководства важно опираться на заранее составленный план. Дерево проекта в Dr.Explain поможет структурировать документ по вашему усмотрению. Вы можете добавлять, удалять перемещать разделы и переименовывать их. Для каждого раздела вы можете определить, в какой формат он будет экспортироваться. Также в работе удобно использовать статусы готовности разделов.
У программы свой собственный редактор, оптимизированный под работу со сложной документацией. Основные функции редактора вынесены в компактный тулбар. Это — управление стилем текста, форматирование абзацев, вставка ссылок, изображений, видео, таблиц и списков, а также вставка специальных объектов. Dr. Explain экономит время и силы своих пользователей. Разработчики документации часто сталкиваются с проблемой многократного использования одного и того же фрагмента текста и прибегают к очевидным решениям — «Ctrl+c», Ctrl+v». Dr.Explain предлагает решение по повторному использованию контента — текстовые переменные. Это решение экономит время, когда нужно много раз использовать один и тот же текст, особенно, который может периодически изменяться — например, версия документируемой системы.
Многие российские компании сталкиваются с тем, что руководство пользователя нужно писать согласно ГОСТ 19 и ГОСТ 34. Dr.Explain активирует поддержку требований ГОСТ фактически одним кликом. Программа автоматически сформирует структуру обязательных разделов и установит требуемые параметры страницы, стили абзацев, списков и заголовков.
Часто техническим писателям при документировании пользовательского интерфейса приходится снабжать изображения пояснительными выносками. Для таких случаев программа поддерживает специальные графические объекты — аннотированные экраны. Чаще всего аннотируются скриншоты программ и страниц веб-сайтов. Уникальной особенностью Dr.Explain является автоматическая аннотация изображений, получаемых при захвате экранов с окнами программ или сайтов. Программа анализирует структуру окон и добавляет пояснительные выноски ко всем значимым элементам.
Кроме того, Dr.Explain позволяет нескольким авторам одновременно работать над проектом с использованием сервиса www.tiwri.com, учетную запись на котором можно создать бесплатно за пару минут. При внесении правок одним автором сервис блокирует редактируемые разделы проекта для изменения другими авторами. По окончании редактирования изменения отправляются на сервер, и блокировка снимается. Так несколько человек могут одновременно работать над различными разделами проекта без риска помешать друг другу.
Попробовать режим многопользовательской работы в Dr.Explain можно даже с бесплатной лицензией. Вы можете создать общий проект и полноценно работать с ним в многопользовательском режиме до семи дней.
Почему компании выбирают Dr.Explain для создания руководств пользователя
Павел Свиридов, профессиональный военный, полковник, создатель астрологической системы «Вега Матрица»
«Только программа Dr.Explain обладала всеми необходимыми возможностями. А главное — она давала простор для творчества. Можно было выбрать цветовую гамму, вид и форму служебных элементов, настраиваемые шаблоны. Это позволило мне сохранить стилевое единство документации и самой программы. Ну, и конечно, полуавтоматическая обработка материала существенно облегчает и ускоряет работу по созданию хелпа.
Обучение работе в Dr.Explain было наглядным и сделано возможностями самой программы, что безусловно повлияло на мой выбор в ее пользу».
Прочитать полный кейс компании «Вега Матрица вы можете перейдя по ссылке
Наталья Обухова, бизнес-аналитик компании CRM Expert
«По классике жанра был пилотный проект на двух фаворитах (Dr.Explain и HelpNDoc) и муки выбора.
Через неделю справка была полностью готова. Конечно, если мы набивали ее «с нуля», за это время мы бы не успели. Мы просто конвертировали все бумажные инструкции во внутренний формат программ, изменили каталогизацию и организовали систему гиперссылок.
Сначала фаворитом выбора была другая система, но решающим фактором в пользу Dr.Explain стал возглас человека, выполняющего основную часть работы по переносу текста: «Вжух! И вся структура документа перенеслась в файл справки». Функция импорта в Dr.Explain отработала на ура и сэкономила кучу времени.
Также очень подкупил дизайн веб-справки, который формируется Dr.Explain, и красивый способ организации подписей к окнам нашей системы. В Dr.Explain это называется «Аннотирование экрана».
Возможность установки статуса раздела тоже оказалась очень удобной, особенно, после импорта старой версии справки легко отслеживать, какие разделы требуют обновления, в каких еще ведутся изменения, а какие уже обновлены и актуальны».
Прочитать полный кейс компании CRM Expert
Николай Вальковец, разработчик компании 2V
«Мы значительно сократили время работы техподдержки с новыми клиентами на этапе подключения. Раньше требовалось проводить онлайн презентации и видео конференции для новых клиентов, объясняя особенности программы. Сейчас же, один раз постаравшись максимально подробно всё описать, мы избавили себя и нашу техподдержку от этой работы. Нам импонирует простота программы и скорость работы. Можно быстро редактировать, добавить новые пункты в документацию, сохранить в формате HTML и выложить на сайт».
Прочитать кейс компании V2
Подытожим
Создание и написание хорошей пользовательской документации — это труд, который требует много времени и усилий. Но если успешно справиться с задачей, можно навсегда получить лояльных и довольных клиентов. Не забывайте о том, что недовольство от некачественного руководства может быть спроецировано пользователем на сам продукт и повлиять на дальнейшие решения о его выборе. Пользовательская документация должна стать персональным и незаменимым помощником. Используя Dr. Explain, вы сможете быстро создать качественное руководство пользователя, которое будет помогать пользователям разбираться в продукте, а вам позволит сосредоточить свои силы на более важных задачах — разработке и продвижении программного продукта.
Скачать Dr.Explain с неограниченной по срокам возможностью бесплатной работы можно по адресу: https://www.drexplain.ru/download/
Успешных вам разработок!
Смотрите также
- Dr.Explain — инструмент для создания мобильной версии пользовательской документации к программным продуктам
- Шаблоны файлов помощи, руководства пользователя программного обеспечения или сайта, шаблон базы знаний — бесплатные шаблоны и примеры пользовательской документации
Писать руководство пользователя по шаблону. Удобно? Удобно
Время на прочтение
4 мин
Количество просмотров 5.2K
Команда, разрабатывающая софт для создания пользовательской документации, делится лайфхаками на тему написания идеальной пользовательской документации для тех, кто далёк от написания руководств к программе.
Для чего мы сами конструируем некоммерческие образцы документации и инструкций для пользователей
Наш проект существует и развивается уже долгое время, практически шестнадцать лет, если быть точнее. За этот срок была сформирована определенная база, где собраны самые актуальные и насущные вопросы, которые возникают перед людьми, создающими справочные элементы к своему проекту.
Ведя диалог с нашими клиентами, мы смогли выделить их потребности и понять основную «боль». Если обобщить, основная проблема заключалась в том, что ни одна программа для создания файл-справок и инструкций не могла выполнить самую нудную, энергозатратную часть проекта — само разрабатывание и оформление этой пользовательской документации
Даже имея осознание того, что файл-справка — неотъемлемый и действительно полезный элемент для пользователя, очень редко возникает мотивация оформить его грамотно и качественно. Еще реже желание возникает, когда в написании пользовательской документации нет опыта или специалистов, которые бы этот опыт имели. Обычно, эта обязанность с легкой руки падает на плечи самих создателей программы, людей, занимающихся тестированием, аналитикой, специалистам поддержки или даже руководителей компании, которые тоже не совсем понимают, как грамотно создать что-то подобное.
Отсюда вытекает еще одна загвоздка. Люди, у которых нет опыта и в принципе понимания, как начать и что туда вносить, просто не знают, как создать качественное руководство для пользователей. В таких случаях большинство следует привычному пути: загуглить определение и найти готовый шаблон.
И с какой-то стороны, это разумно. Мы достаточно часто сталкиваемся с такими запросами, пользователи просят у нас пошаговое руководство или хотя бы костяк готовой инструкции.
Так вышло, что потребности наших клиентов практически на сто процентов входят в нашу экспертную сферу. И мы приняли решение по возможности помочь всем, кто хочет (или вынужден) заниматься созданием файл-справок и инструкций к своему продукту и предоставить возможность получить образцы, которые могут послужить базой и легко быть адаптированными под конкретный запрос.
В связи с этим, мы сами создали готовые образцы и костяки шаблонных проектов в программе. Что входит в нашу базу:
-
Руководство пользователя программного обеспечения.
-
Руководство пользователя web-сервиса.
-
Корпоративная база знаний компании.
В чем удобство создания руководства пользователя по образцу
Вы бережете своё время.
Адаптируя уже созданный образец под свой продукт, вы не тратите время на создание основы с нуля, вам не нужно тратить время, чтобы найти мастер-класс о том, как правильно это сделать. Используя готовый шаблон документации, вы значительно экономите время на создание структуры проекта с нуля и на поиск и изучение информации о том, как это делается.
Вы сосредотачиваете внимание на вашей программе, а не на создании файл-справки
В шаблоне уже есть текстовые и графические вставки, вы можете сами добавлять нужный контент в предложенные места и не продумывать вариант оформления.
Наглядность.
Все образцы и костяки инструкций для пользователя изначально настроенные с динамическими стилями оформления, которые помогут вам быстрее освоиться и разобраться, как можно использовать это для быстрого выполнения своей цели.
Адаптация шаблонов и образцов под ваш проект.
Всё, что находится в шаблонах, можно назвать нашим советом, который был создан на основе многолетнего опыта в данной сфере и выработанной экспертностью. Абсолютно всё в этих шаблонах может быть подвержено адаптации, так как для пользовательской документации нет жестких стандартов, она должна быть выстроена персонально под ваш продукт.
О шаблонах
За 15 лет мы смогли подвергнуть аналитике более сотни разных файл-справок, инструкций и технических документаций, что дало нам возможность сделать вывод и определить шаблонные разделы, которые могут быть применены к огромному количеству программ, после чего мы интегрировали их в наши образцы. Давайте немного подробнее поговорим о структуре.
Обзор возможностей программ. Здесь идет краткое содержание сути вашего продукта. Где вы рассказываете о том, для чего нужна ваша программа. Какие боли и потребности она удовлетворяет, на что способна.
Пользовательский интерфейс. Здесь вы можете наглядно показать вашему клиенту интерфейс, ознакомить его со всеми режимами, дополнительными кнопками и.т.д. Если пользователь может персонализировать интерфейс под себя, об этом тоже лучше указать именно в этом разделе.
Типовые задачи. Здесь нужно максимально подробно познакомить пользователя со всеми основными возможностями программы и детально описать ряд задач и вопросов, которые клиент сможет решить с её помощью. В нашем образце этот блок сформирован из двух подразделов. В подразделе «Примеры использования» лучше всего рассказать пользователю, как ваш продукт будет решать его вопросы и задачи. Если обобщить, то в этом подразделе вы рассказываете про клишированные проблемы, с которыми сталкивается большинство пользователей. В подразделе «Лучшие практики» лучше разместить максимально полезную информацию о том, как упростить свою работу в программе и как пользоваться ей максимально эффективно.
Особые случаи. Здесь нужно рассказать пользователю про то, какие трудности могут возникнуть и как их решить, выделить часто задаваемые вопросы и дать на них самый доступный ответ. Подразделы: «FAQ» и «Устранение типовых проблем»
Вспомогательная и юридическая информация. Здесь вы размещаете информацию о компании, размещаете контактные данные тех.поддержки, информацию о сотрудничестве, сайт, а также лицензионные соглашения.
Названия проекта публиковать не будем, Хабр ругается.
P.S. Мы будем рады, если наши образцы помогут вам закрыть вопрос и успешно реализовать документацию в своем проекте.
Подборка по базе: 3. Работа.pdf, контрольная работа по сурдопсихологии.docx, КОНТРОЛЬНАЯ РАБОТА.docx, Практическая работа №3.docx, МАРСЕЛЬ КУРСОВАЯ РАБОТА.doc, Курсовая работа (проект) по дисциплине «Основы научных исследова, Практическая работа 2 Школа управленцев.docx, Практическая работа 3.doc, Документооборот практическая.docx, Лабараторная работа WordPress Никольский А.А. МИЗ-401.docx
3 3
СОДЕРЖАНИЕ
ПРАКТИЧЕСКАЯ РАБОТА №1 Написание руководства пользователя заданной программы ……………………………………… 5
Цель работы ………………………………………………………………….. 5
Краткие сведения из теории ……………………………………………. 5
Задания к работе ………………………………………………………….. 16
Контрольные вопросы ………………………………………………….. 16
ПРАКТИЧЕСКАЯ РАБОТА №2 Написание руководства системного программиста (администратора) заданной программы ……………………………………………………………………… 17
Цель работы ………………………………………………………………… 17
Краткие сведения из теории ………………………………………….. 17
Задания к работе ………………………………………………………….. 21
ПРАКТИЧЕСКАЯ РАБОТА №3 Разработка руководства по сопровождению ПО …………………………………………………………. 22
Цель работы ………………………………………………………………… 22
Краткие сведения из теории ………………………………………….. 22
Задание к работе ………………………………………………………….. 23
ПРАКТИЧЕСКАЯ РАБОТА №4 Разработка справочной системы программного продукта………………………………………. 25
Цель работы ………………………………………………………………… 25
Краткие сведения из теории ………………………………………….. 25
Задания к работе ………………………………………………………….. 27
ПРАКТИЧЕСКАЯ РАБОТА №5 Разработка буклетов, рекламных листков по программному продукту ………………… 29
Цель работы ………………………………………………………………… 29
Краткие сведения из теории ………………………………………….. 29
Задание к работе ………………………………………………………….. 30
ПРАКТИЧЕСКАЯ РАБОТА №6 Тестирование по методу
«черного ящика» ……………………………………………………………… 31
Цель работы ………………………………………………………………… 31
Краткие сведения из теории ………………………………………….. 31
Задание к работе ………………………………………………………….. 36
ПРАКТИЧЕСКАЯ РАБОТА №7 Тестирование по методу
«белого ящика» ……………………………………………………………….. 38
4 4
Цель работы ………………………………………………………………… 38
Краткие сведения из теории ………………………………………….. 38
Задание к работе ………………………………………………………….. 39
Приложение 1 …………………………………………………………………. 40
Приложение 2 …………………………………………………………………. 42
5 5
ПРАКТИЧЕСКАЯ
РАБОТА
№1
Написание
руководства пользователя заданной программы
Цель работы
изучение нормативно правовой документации, регламентирующей разработку документации на программные средства.
приобретение навыков разработки руководства пользователя программного средства (ПС).
Краткие сведения из теории
Основу отечественной нормативной базы в области документирования ПС составляет комплекс стандартов
Единой системы программной документации (ЕСПД).
Основная и большая часть комплекса
ЕСПД была разработана в 70-е и 80-е годы. Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПС, и связаны, по большей части, с документированием функциональных характеристик ПС.
Согласно ЕСПД программный документ – это документ, содержащий сведения, необходимые для разработки, изготовления, эксплуатации и сопровождения программного изделия. Номенклатуру программных документов определяет
ГОСТ 19.101-77 «ЕСПД. Виды программ и программных
документов».
В качестве основных видов программ стандартом определяются:
компоненты – программы, рассматриваемые как единое целое, выполняющие законченную функцию и применяемые самостоятельно или в составе комплекса;
комплексы – программы, состоящие из двух или более компонентов, выполняющие взаимосвязанные функции и применяемые самостоятельно или в составе другого комплекса.
Виды программных документов и их краткое содержание представлены в стандарте описаниями, приведенными в таблице 1.
6 6
Таблица 1. Виды программных документов
Вид документа
Содержание документа
Спецификаци я
Состав программы и документация на нее
Ведомость держателей подлинников
Перечень предприятий, на которых хранятся подлинники программных документов
Текст программы
Запись программы с необходимыми комментариями
Описание программы
Сведения о логической структуре и функционировании программы
Программа и методика испытаний
Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля
Техническое задание
Назначение и область применения программы; технические, технико-экономические и специальные требования, предъявляемые к программе; необходимые стадии и сроки разработки; виды испытаний
Пояснительна я записка
Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений
Эксплуатацио нные документы
Сведения для обеспечения функционирования и эксплуатации программы
Перечень эксплуатационных документов, рекомендуемых
ЕСПД, представлен в табл. 2.
Таблица 2. Виды эксплуатационных документов
Вид документа
Содержание документа
Ведомость эксплуатационных документов
Перечень эксплуатационных документов на программу
7 7
Вид документа
Содержание документа
Формуляр
Основные характеристики программы, комплектность и сведения об эксплуатации программы
Описание применения
Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств
Руководство системного программиста
Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения
Руководство программиста
Сведения для эксплуатации программы
Руководство оператора
(пользователя)
Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы
Описание языка
Описание синтаксиса и семантики языка
Руководство по техническому обслуживанию
Сведения для применения тестовых и диагностических программ при обслуживании технических средств
Допускается объединение отдельных видов эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра), необходимость объединения указывается в техническом задании.
Объединенному документу присваивают наименование и обозначение одного из объединяемых документов.
В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ.
8 8
ГОСТ 19.701-90 (ИСО 5807-85) «Единая система
программной
документации.
Схемы
алгоритмов,
программ, данных и систем. Обозначения условные и
правила выполнения». Стандарт распространяется на условные обозначения (символы) в схемах алгоритмов, программ, данных и систем и устанавливает правила выполнения схем, используемых для отображения различных видов задач обработки данных и средств их решения.
В РФ действует ряд стандартов в части документирования
ПС, разработанных на основе прямого применения международных стандартов ИСО.
ГОСТ
Р
ИСО/МЭК
9294-93
«Информационная
технология.
Руководство
по
управлению
документированием программного обеспечения». Стандарт устанавливает рекомендации по эффективному управлению документированием ПС для руководителей, отвечающих за их создание. Целью стандарта является оказание помощи в определении стратегии документирования
ПС; выборе стандартов по документированию; выборе процедур документирования; определении необходимых ресурсов; составлении планов документирования.
ГОСТ Р ИСО 9127-94 «Системы обработки информации.
Документация пользователя и информация на упаковке
для потребительских программных пакетов». В контексте настоящего стандарта под потребительским программным пакетом
(ПП) понимается
«программная продукция, спроектированная и продаваемая для выполнения определенных функций; программа и соответствующая ей документация, упакованные для продажи как единое целое».
Под документацией пользователя понимается документация, которая обеспечивает конечного пользователя информацией по установке и эксплуатации ПП. Под информацией на упаковке понимают информацию, воспроизводимую на внешней упаковке ПП. Ее целью является предоставление потенциальным покупателям первичных сведений о ПП.
9 9
Содержание документа «Руководство пользователя»
Документ «Руководство пользователя», разрабатывается на основании методических указаний РД 50-34.698-90.
Данный документ формируется IT-специалистом, или функциональным специалистом, или техническим писателем в ходе разработки рабочей документации на систему и её части на стадии «Рабочая документация».
Состав руководства пользователя в соответствии со стандартом:
1. Введение.
2. Назначение и условия применения.
3. Подготовка к работе.
4. Описание операций.
5. Аварийные ситуации.
6. Рекомендации по освоению.
1. Введение
В разделе «Введение» указывают:
область применения;
краткое описание возможностей;
уровень подготовки пользователя;
перечень эксплуатационной документации, с которой необходимо ознакомиться пользователю.
1.1. Область применения
Требования настоящего документа применяются при:
предварительных комплексных испытаниях;
опытной эксплуатации;
приемочных испытаниях;
промышленной эксплуатации.
1.2. Краткое описание возможностей
Например:
Информационно-аналитическая система Корпоративное
Хранилище
Данных
(ИАС
КХД)
предназначена
для
оптимизации
технологии
принятия
тактических
и
стратегических управленческих решений конечными бизнес-
10 10
пользователями на основе информации о всех аспектах
финансово-хозяйственной деятельности Компании.
ИАС КХД предоставляет возможность работы с
регламентированной и нерегламентированной отчетностью.
1.3. Уровень подготовки пользователя
Например:
Пользователь ИАС КХД должен иметь опыт работы с ОС
MS Windows (95/98/NT/2000/XP), навык работы с ПО Internet
Explorer, Oracle Discoverer, а также обладать следующими
знаниями:
знать соответствующую предметную область;
знать основы многомерного анализа;
понимать многомерную модель соответствующей
предметной области;
знать и иметь навыки работы с аналитическими
приложениями.
Квалификация пользователя должна позволять:
формировать отчеты в Oracle Discoverer Plus;
осуществлять анализ данных.
1.4. Перечень эксплуатационной документации, с
которой необходимо ознакомиться пользователю
Например:
Информационно-аналитическая система «Корпоративное
хранилище данных». ПАСПОРТ;
Информационно-аналитическая система «Корпоративное
хранилище данных». ОБЩЕЕ ОПИСАНИЕ СИСТЕМЫ.
2. Назначение и условия применения
В разделе «Назначение и условия применения» указывают:
виды деятельности, функции, для автоматизации которых предназначено данное средство автоматизации;
условия, при соблюдении (выполнении, наступлении) которых обеспечивается применение средства автоматизации в соответствии с назначением (например, вид ЭВМ и конфигурация технических средств, операционная среда и общесистемные программные средства, входная информация,
11 11
носители данных, база данных, требования к подготовке специалистов и т. п.).
Например:
Oracle Discoverer Plus в составе ИАС КХД предназначен
для автоматизации подготовки, настройки отчетных форм
по показателям деятельности, а также для углубленного
исследования данных на основе корпоративной информации
хранилища данных.
Работа с Oracle Discoverer Plus в составе ИАС КХД
возможна всегда, когда есть необходимость в получении
информации для анализа, контроля, мониторинга и принятия
решений на ее основе.
Работа с Oracle Discoverer Plus в составе ИАС КХД
доступна всем пользователям с установленными правами
доступа.
3. Подготовка к работе
В разделе «Подготовка к работе» указывают:
состав и содержание дистрибутивного носителя данных;
порядок загрузки данных и программ;
порядок проверки работоспособности.
3.1. Состав и содержание дистрибутивного
носителя данных
Например:
Для
работы
с
ИАС
КХД
необходимо
следующее
программное обеспечение:
Internet Explorer (входит в состав операционной системы
Windows);
Oracle JInitiator устанавливается автоматически при
первом обращении пользователя к ИАС КХД.
3.2. Порядок загрузки данных и программ
Например:
Перед началом работы с ИАС КХД на рабочем месте
пользователя необходимо выполнить следующие действия:
Необходимо зайти на сайт ИАС КХД ias-dwh.ru.
12 12
Во время загрузки в появившемся окне «Предупреждение
о безопасности», которое будет содержать следующее:
‘Хотите установить и выполнить «Oracle JInitiator» …’
Нажимаем на кнопку «Да».
После чего запуститься установка Oracle JInitiator на Ваш
компьютер. Выбираем кнопку Next и затем OK.
3.3. Порядок проверки работоспособности
Например:
Для проверки доступности ИАС КХД с рабочего места
пользователя необходимо выполнить следующие действия:
Открыть Internet Explorer, для этого необходимо кликнуть
по ярлыку «Internet Explorer» на рабочем столе или вызвать из
меню «Пуск».
Ввести в адресную строку Internet Explorer адрес: ias-
dwh.ru и нажать «Переход».
В форме аутентификации ввести пользовательский логин и
пароль. Нажать кнопку «Далее».
Убедиться, что в окне открылось приложение Oracle
Discoverer Plus.
В случае если приложение Oracle Discoverer Plus не
запускается, то следует обратиться в службу поддержки.
4. Описание операций
В разделе «Описание операций» указывают:
описание всех выполняемых функций, задач, комплексов задач, процедур;
описание операций технологического процесса обработки данных, необходимых для выполнения функций, комплексов задач (задач), процедур.
Для каждой операции обработки данных указывают:
наименование;
условия, при соблюдении которых возможно выполнение операции;
подготовительные действия;
основные действия в требуемой последовательности;
заключительные действия;
13 13
ресурсы, расходуемые на операцию.
В описании действий допускаются ссылки на файлы подсказок, размещенные на магнитных носителях.
4.1. Выполняемые функции и задачи
Например:
Oracle Discoverer Plus в составе ИАС КХД выполняет
функции и задачи, приведенные в таблице ниже:
Функции Задачи
Описание
Обеспеч
ивает
многоме
рный
анализа
в
табличн
ой
и
графиче
ской
формах
Визуализация
отчетности
В ходе выполнения данной задачи
пользователю
системы
предоставляется
возможность
работы с выбранным отчетом из
состава преднастроенных.
Формирование
табличных
и
графических
форм
отчетности
В ходе выполнения данной задачи
пользователю
системы
предоставляется
возможность
формирования собственного отчета
в табличном или графическом виде
на
базе
преднастроенных
компонентов.
4.2.
Описание
операций
технологического
процесса обработки данных, необходимых для
выполнения задач
Например:
Задача: «Визуализация отчетности»
Операция 1: Регистрация на портале ИАС КХД
Условия, при соблюдении которых возможно выполнение
операции:
Компьютер пользователя подключен к корпоративной
сети.
Портал ИАС КХД доступен.
ИАС КХД функционирует в штатном режиме.
Подготовительные действия:
14 14
На компьютере пользователя необходимо выполнить
дополнительные настройки, приведенные в п. 3.2 настоящего
документа.
Основные действия в требуемой последовательности:
На иконке «ИАС КХД» рабочего стола произвести
двойной щелчок левой кнопкой мышки.
В открывшемся окне в поле «Логин» ввести имя
пользователя, в поле «Пароль» ввести пароль пользователя.
Нажать кнопку «Далее».
Заключительные действия:
Не требуются.
Ресурсы, расходуемые на операцию:
15-30 секунд.
5. Аварийные ситуации
В разделе «Аварийные ситуации» указывают:
1. действия в случае несоблюдения условий выполнения технологического процесса, в том числе при длительных отказах технических средств;
2. действия по восстановлению программ и/или данных при отказе магнитных носителей или обнаружении ошибок в данных;
3. действия в случаях обнаружении несанкционированного вмешательства в данные;
4. действия в других аварийных ситуациях.
Например:
В случае возникновения ошибок при работе ИАС КХД, не
описанных ниже в данном разделе, необходимо обращаться к
сотруднику подразделения технической поддержки ДИТ
(HelpDesk) либо к ответственному Администратору ИАС
КХД.
Класс
ошибки
Ошибка
Описание
ошибки
Требуемые
действия пользователя
при
возникновении ошибки
Сбой в
электр
Нет
электроп
Рабочая
станция
Перезагрузить
рабочую
станцию.
15 15
опитан
ии
рабоче
й
станци
и
итания
рабочей
станции
или
произоше
л сбой в
электроп
итании.
выключил
ась
или
перезагру
зилась.
Проверить
доступность
сервера ИАС КХД по порту 80,
выполнив следующие команды:
—
нажать
кнопку
«Пуск»
— выбрать пункт «Выполнить»
— в строке ввода набрать
команду telnet ias_dwh.ru 80
— если открылось окно Telnet,
значит соединение возможно.
Повторить
попытку
подключения (входа) в ИАС КХД
Сбой
локальн
ой
сети
Нет
сетевого
взаимоде
йствия
между
рабочей
станцией
и
сервером
приложе
ний ИАС
КХД
Отсутст
вует
возможн
ость
начала
(продолж
ения)
работы с
ИАС
КХД.
Нет
сетевого
подключе
ния
к
серверу
ИАС КХД
Перезагрузить
рабочую
станцию.
Проверить
доступность
сервера ИАС КХД по порту 80,
выполнив следующие команды:
—
нажать
кнопку
«Пуск»
— выбрать пункт «Выполнить»
— в строке ввода набрать
команду telnet ias_dwh.ru 80
— если открылось окно Telnet,
значит соединение возможно.
После восстановления работы
локальной
сети
повторить
попытку подключения (входа) в
ИАС КХД.
6. Рекомендации по освоению
В разделе «Рекомендации по освоению» указывают рекомендации по освоению и эксплуатации, включая описание контрольного примера, правила его запуска и выполнения.
Например:
Рекомендуемая литература:
Oracle® Business Intelligence Discoverer Viewer User’s Guide
Oracle® Business Intelligence Discoverer Plus User’s Guide
16 16
Рекомендуемые курсы обучения:
Discoverer 10g: Создание запросов и отчетов
В
качестве
контрольного
примера
рекомендуется
выполнить операции задачи «Визуализация отчетности»,
описанные в п. 4.2. настоящего документа.
Задания к работе
1. Подготовить документ (*.doc), содержащий структуру основных разделов руководства пользователя стандартного форматирования: шрифт TimesNewRoman, 12 пт, поля, межстрочный интервал — стандартные, как в техническом задании, имя файла — <ФИО студента. Руководство пользователя>.
2. На основании технического задания на разработку
(практическая работа МДК 03.01), заполнить разделы руководства пользователя «Введение», «Назначение и условия применения», «Подготовка к работе».
3. Сохранить документ с именем (Фамилия, инициалы студента. Наименование работы).
4. Прикрепить файл руководства пользователя в разделе
Руководство пользователя (практическая работа 1) учебного сервера.
Контрольные вопросы
1. Перечислить состав разделов руководства пользователя.
2. Пояснить состав раздела «Введение».
3. Пояснить состав раздела «Назначение и условия применения2 применения».
4. Пояснить состав раздела «Подготовка к работе»
5. Пояснить состав раздела «Описание операций»
6. Пояснить состав раздела «Аварийные ситуации»
7. Пояснить состав подраздела
«Рекомендации по освоению»
17 17
ПРАКТИЧЕСКАЯ
РАБОТА
№2
Написание
руководства системного программиста (администратора)
заданной программы
Цель работы
изучение нормативно правовой документации, регламентирующей разработку документации на программные средства.
приобретение навыков разработки руководства системного программиста ПС.
Краткие сведения из теории
Если программа более-менее проста, пользователь может установить ее себе на компьютер самостоятельно.
Поддерживать ее работоспособность, например, выполнить переустановку, если возникнут какие-нибудь проблемы, он тоже, как правило, в состоянии.
Сложными, в том числе, серверными и сетевыми программными продуктами приходится заниматься квалифицированным специалистам, системным
администраторам. Более того, во многих компаниях сотрудникам запрещено устанавливать на своих рабочих местах программы по своему усмотрению. Даже простые программы там ставит только системный администратор.
В обязанности системного администратора также входит поддержание работоспособности программ, используемых в рамках тех или иных систем. Эта деятельность может заключаться в периодической проверке логов, резервном копировании данных, замерах производительности, устранении различных технических проблем.
Руководство системного администратора — программный документ, предоставляющий специалисту информацию, необходимую для выполнения этой работы.
В ЕСПД специалист, сходный по обязанностям с современным системным администратором, называется системным программистом, а адресованный ему документ — руководством системного программиста.
18 18
Содержание документа «Руководство системного
программиста (администратора)»
Если речь идет о сложных программных или аппаратно- программных комплексах, то системный программист
(администратор) — это квалифицированный специалист, которому приходится принимать нетривиальные решения.
Чтобы удовлетворить его потребности в информации, составителю документации необходимо понимать, как мыслит его читатель, что и в какой момент может его заинтересовать, какая подробность изложения материала будет достаточной для него.
Поэтому разрабатывать руководство системного администратора должен либо его коллега, имеющий к тому же навыки технического писателя, либо технический писатель, имеющий хотя бы небольшой опыт работы системным администратором.
В случае небольших «монолитных» программ руководство системного администратора может оказаться документом небольшим по объему и простым по структуре.
Руководство системного администратора на программный или аппаратно-программный комплекс сложнее, поскольку в нем приходится описывать каждый компонент по отдельности и способы их интеграции как друг с другом, так и со сторонним программным обеспечением: серверами баз данных, почтовыми серверами, антивирусами, средствами шифрования и пр.
Итак, в руководстве системного администратора должны быть изложены:
назначение и область применения программы (или комплекса);
состав программы, основные принципы ее функционирования;
комплект поставки (если он не указан в отдельном документе);
19 19
системные требования для программы или ее компонентов;
предпочтительная очередность установки компонентов;
процедура установки программы или каждого ее компонента;
порядок обязательной первоначальной настройки программы;
способы интеграции установленных копий компонентов между собой;
интеграция программы со сторонним ПО, например, с сервером БД;
способы и периодичность контроля правильности работы программы;
порядок текущего обслуживания работающих копий программы;
порядок решения всевозможных вспомогательных задач;
аварийные ситуации и способы их устранения.
Нередко в руководстве системного администратора вдобавок приходится описывать:
пользовательский интерфейс административной консоли;
утилиты командной строки и синтаксис их запуска;
конфигурационные файлы и правила их написания;
язык для составления управляющих скриптов.
Все зависит от того, какие средства для установки и настройки программы реализовали ее разработчики, какие именно инструменты они дают в руки системному администратору.
Методика и стиль изложения материала
Методика изложения материала в руководстве системного администратора сильно зависит от того, каким образом программой можно управлять.
Если большинство задач решается через административную консоль с графическим интерфейсом, то документ будет
20 20
больше похож на руководство пользователя или руководство администратора.
Если системному администратору придется активно составлять конфигурационные файлы и писать скрипты, документ будет ближе к руководству программиста или описанию языка программирования.
Типовая
структура
руководства
системного
программиста
Структура руководства системного программиста, приведена в ГОСТ 19.503-79:
Общие сведения о программе.
Структура программы.
Настройка программы.
Проверка программы.
Дополнительные возможности.
Сообщения системному программисту.
Приблизительная современная структура руководства системного администратора.
Общие сведения о программе (комплексе).
Архитектура и принципы функционирования.
Системные требования.
Установка программы (комплекса).
Административная консоль и работа с ней.
Файл конфигурации. Составление и правка.
Обязательная начальная настройка программы
(комплекса).
Проверка правильности функционирования программы
(комплекса).
Мероприятия по текущему обслуживанию программы
(комплекса).
Оптимизация работы программы (комплекса).
Аварийные ситуации и способы их устранения.
Особенности.
21 21
Задания к работе
1. Подготовить документ (*.doc), содержащий структуру основных разделов руководства системного программиста стандартного форматирования: шрифт TimesNewRoman, 12 пт, поля, межстрочный интервал — стандартные, как в техническом задании, имя файла — <ФИО студента. Руководство пользователя>.
2. На основании технического задания на разработку
(практическая работа МДК 03.01), заполнить разделы руководства пользователя «Общие сведения о программе»,
«Структура программы», «Настройка программы».
3. Сохранить документ с именем (Фамилия, инициалы студента. Наименование работы).
4. Прикрепить файл руководства в разделе Руководство системного программиста (практическая работа 2) учебного сервера.
22 22
ПРАКТИЧЕСКАЯ РАБОТА №3 Разработка руководства
по сопровождению ПО
Цель работы
приобретение навыков разработки руководства по сопровождению ПС
Краткие сведения из теории
Документация по сопровождению
ПС
(system documentation) описывает ПС с точки зрения его разработки.
Эта документация необходима, если ПС предполагает изучение того, как оно устроена (сконструирована), и модернизацию его программ.
То есть тексты пишутся для разработчиков , подобных
исполнителям (исполнители — это те, кто изначально
создали ПС).
В случае необходимости модернизации ПС к этой работе привлекается специальная команда разработчиков- сопроводителей. Этой команде придется иметь дело с такой же документацией, которая определяла деятельность команды первоначальных (основных) разработчиков ПС, — с той лишь разницей, что эта документация для команды разработчиков- сопроводителей будет, как правило, чужой (она создавалась другой командой).
Документацию по сопровождению ПС можно разбить на группы:
документация, определяющая строение программ и структур данных ПС и технологию их разработки;
документацию, помогающую вносить изменения в ПС.
Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС.
Она включает следующие документы:
Внешнее описание ПС (Requirements document).
Описание
архитектуры
ПС
(description of the system architecture), включая внешнюю спецификацию каждой ее программы.
23 23
Для каждой программы ПС — описание ее модульной
структуры, включая внешнюю спецификацию каждого включенного в нее модуля.
Для каждого модуля — его спецификация и описание его строения (design description).
Тексты
модулей на выбранном языке программирования (program source code listings).
Документы
установления
достоверности
ПС
(validation documents), описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к
ПС.
Документы установления достоверности ПС включают прежде всего документацию по тестированию (схема тестирования и описание комплекта тестов), но могут включать и результаты других видов проверки ПС, например, доказательства свойств программ.
Документация второй группы содержит:
Руководство
по
сопровождению
ПС
(system maintenance guide), известные проблемы, связанные с ПС,
какие части системы являются
аппаратно-
и
программно-зависимыми,
возможности дальнейшего развития ПС.
Задание к работе
1. Изучить РД 50-34.698-90, определить состав разделов руководства по сопровождению программы
(
http://prj- exp.ru/patterns/pattern_user_guide.php
).
2. Подготовить документ (*.doc), содержащий структуру основных разделов руководства по попровождению стандартного форматирования: шрифт TimesNewRoman, 12 пт, поля, межстрочный интервал — стандартные, как в техническом задании, имя файла — <ФИО студента. Руководство по сопровождению>.
24 24 3. На основании результатов разработки ПС (в рамках курсового проектирования или производственной практики, заполнить разделы руководства.
4. Сохранить документ с именем (Фамилия, инициалы студента. Руководство по сопровождению).
5. Прикрепить файл руководства в разделе Руководство по сопровождению.(практическая работа 5) учебного сервера.
25 25
ПРАКТИЧЕСКАЯ РАБОТА №4 Разработка справочной
системы программного продукта
Цель работы
изучение нормативно правовой документации, регламентирующей разработку документации на программные средства.
изучение структуры справочной системы ПС.
закрепление навыков разработки справочной системы
ПС.
Краткие сведения из теории
Общие сведения о структуре справочной системы
В справочную систему следует включать разделы, ознакомление с которыми предшествует работе с программой: системные требования, установка программы и т. п.
Когда пользователь запрашивает справку, например, нажатием на клавишу F1, на экран автоматически выводится раздел, связанный с активным элементом. Таковым может оказаться верхнее диалоговое окно, элемент интерфейса, на котором находится фокус ввода, элемент интерфейса, на который пользователь навел указатель мыши и т. д.
В разных операционных системах, графических оболочках и прикладных платформах способы запроса справки, вообще говоря, могут быть оригинальными. На практике в общем и целом пользователю везде предлагается примерно один и тот же набор возможностей и методов доступа к справке.
Возможно включение в справочные системы мультимедийный контент: звуковые и видео-файлы, а также
Flash.
Полноценная справочная система состоит, по крайней мере, из двух частей: общей и контекстной. Более того, материал, который из-за большого объема невыгодно печатать на бумаге или неудобно искать в линейном документе, нередко включают только в справочную систему.
26 26
Общая часть справочной системы
В общую часть обычно включают материал всех имеющихся руководств: пользователя или оператора, администратора, системного администратора и других документов, разумеется при наличии таковых. Общей частью читатель пользуется как электронной книгой.
Таким образом получается электронная энциклопедия по программе или программно-аппаратному комплексу. Удобство ее еще и в том, что большинство форматов справки (и, следовательно, большинство просмотровых программ) позволяет снабдить справку удобными средствами навигации и поиска, в том числе, полнотекстового.
Контекстная часть справочной системы
В контекстную часть справочной системы включают:
описание каждого режима и диалогового окна;
подсказки по элементам главного окна, окон документов и диалоговых окон;
подсказки по пунктам меню и кнопкам панелей инструментов;
подсказки по употребляемым терминам.
Разделы контекстной части связывают с определенными элементами интерфейса, что требует координации, (как правило, несложной) действий автора справки и разработчиков программы.
Методика и стиль изложения информации в
справочной системе
На практике справочная система часто представляет собой текст руководства пользователя, представленный в определенном электронном формате.
Как правило, справочная система — это гипертекст.
Гипертекст не предполагает последовательного чтения.
Читатель может выполнить поиск или нажать на клавишу F1 и в результате получить доступ к произвольному (с точки зрения автора) разделу гипертекста.
27 27
Составляя тот или иной раздел, автор не может рассчитывать на то, что читатель уже усвоил материал предшествующих разделов или хотя бы осведомлен об их существовании. Поэтому следует стремиться к тому, чтобы каждый раздел представлял собой самодостаточную статью, при ограниченном объеме в понятную пользователю в отрыве от остального материала.
Таким образом, раздел должен быть чем-то вроде статьи в энциклопедии или обстоятельного ответа на заданный кем-то вопрос. Это может достигаться, в частности, более активным дублированием текста (определений, концепций), чем в линейном документе.
Если полное понимание раздела невозможно без ознакомления с некоторыми другими разделами справки, на них должны быть сделаны ссылки.
Глоссарий – перечень уникальных понятий, используемых в приложении и его интерфейсе. В качестве примера таковых могут выступать названия элементов меню, окон, режимов, текст командных кнопок и т.д.
Недопустимо наличие различных терминов для определения одного и того же понятия. Описание понятий должно отвечать промышленному руководству, соответствующему выбранной платформе (MS Microsoft).
Задания к работе
1. Составить схему меню программы, определить количество режимов работы, количество диалоговых окон.
2. В тетради для практических работ составить список основных терминов предметной области для определения глоссария приложения.
3. Определить разделы, которые должны быть включены в содержание и предметный указатель справочной системы.
4. С использованием текстового редактора подготовить 5-
6 статей по каждому разделу справочной системы: изложение алгоритмов выполнения пользователем отдельных функций
28 28
(процедурная справка). Размер статьи — 1 -2 экранных страницы.
5. Добавить описания общей концепции приложения, ее функциональности в целом, а также отдельных функций, предоставляемых пользователю для выполнения (обзорная справка).
6. Сформировать файл тем справок в виде файла *.rtf .
7. Сформировать файл справочной системы *.hlp, создав файл Проекта справки и откомпилировав его средствами программы MS Help Workshop (HCRTF).
8. Используя те же средства создания справочной системы, сформировать файл содержания *.cnt
29 29
ПРАКТИЧЕСКАЯ РАБОТА №5 Разработка буклетов,
рекламных листков по программному продукту
Цель работы
приобретение навыков формулирования назначения программы и ее основных конкурентных преимуществ,
приобретение навыков разработки рекламных буклетов для продвижения ПС.
Краткие сведения из теории
ЛИСТОВКИ — ЭТО.
непериодическое издание на листе бумаги…
лист бумаги с текстом и иллюстрациями…
вид агитационной или рекламной полиграфии…
полиграфическая продукция для раздачи…
средство распространения информации
ЛИСТОВКИ — это вид полиграфической продукции. И как любая полиграфия, листовки подразделяются по различным параметрам.
Рекламные листовки — самый распространенный вид листовок.
Данный вид листовок предназначен для привлечения новых клиентов к своей продукции или услугам.
Или же рекламные листовки предлагают уже имеющимся клиентам новый продукт или новую услугу.
Рекламные листовки могут быть как дешевыми (бюджетный вариант листовки), напечатанными на простой писчей или офсетной бумаге в 1-2 цвета, так и более качественными, напечатанными на хорошей мелованной бумаге офсетным или трафаретным способом.
На рекламных листовках могут быть применены различные способы привлечения внимания.
Информационные листовки содержат развернутую информацию о конкретном товаре или конкретной услуге. Как правило, в таких листовках описывается или один вид деятельности предприятия, или один товар / группа товаров.
30 30
Информационные листовки оформляются в корпоративном стиле компании-продавца или в корпоративном стиле предлагаемого товара/услуги.
Задание к работе
1. Изучить предложенные преподавателем рекламные буклеты: структурирование текстовой и графической информации, цветовые характеристики.
2. Составить макет буклета в тетради для практических работ: размер бумаги, количество сложений, расположение блоков информации.
3. Используя MS Publisher выбрать наиболее подходящий шаблон, подготовить рекламный буклет на программное изделие.
4. Сохранить файл буклета с именем (Фамилия, инициалы студента. Наименование работы).
5. Прикрепить файл буклета в разделе Рекламный буклет
(практическая работа 5) учебного сервера.
31 31
ПРАКТИЧЕСКАЯ РАБОТА №6 Тестирование по методу
«черного ящика»
Цель работы
приобретение навыков разработки тестовых заданий по методу «черного ящика».
Краткие сведения из теории
Одним из способов проверки программ является стратегия тестирования, называемая стратегией «черного ящика» или тестированием с управлением по данным. В этом случае программа рассматривается как «черный ящик» и такое тестирование имеет целью выяснения обстоятельств, в которых поведение программы не соответствует спецификации.
Стратегия «черного ящика» включает в себя следующие методы формирования тестовых наборов:
1.
эквивалентное разбиение;
2.
анализ граничных значений;
3.
анализ причинно-следственных связей;
4.
предположение об ошибке.
1. Эквивалентное разбиение
Основу метода составляют положения:
1. Исходные данные программы необходимо разбить на конечное число классов эквивалентности.
2. Каждый тест должен включать по возможности максимальное количество различных входных условий, что позволяет минимизировать общее число необходимых тестов.
Первое положение используется для разработки набора «интересных» условий, которые должны быть протестированы, а второе — для разработки минимального набора тестов.
Разработка тестов методом эквивалентного разбиения осуществляется в два этапа:
выделение классов эквивалентности;
построение тестов.
Выделение классов эквивалентности
32 32
Классы эквивалентности выделяются путем выбора каждого входного условия (обычно это предложение или фраза из спецификации) и разбиением его на две или более групп (таблица 1).
Таблица 1 Классы эквивалентности
Входное условие
Правильные классы эквивалентно сти
Неправильны е классы эквивалентно сти
Если входные условия описывают область значени й (например «целое данное может принимать значения от 1 до 999») выделяют один правильный класс
1<=х<=999 два неправильных х<1 и X>999.
Если входное условие описывает число значений
(например, «в автомобиле могут ехать от одного до шести человек») определяется один правильный класс эквивалентно сти и два неправильных
(ни одного и более шести человек).
Если входное условие описывает множество входных значений и есть основания полагать, что каждое значение программист трактует особо
(например,
«известные способы передвижения на
АВТОБУСЕ, ГРУЗОВИКЕ,
ТАКСИ, МОТОЦИКЛЕ или
ПЕШКОМ»), определяется правильный класс эквивалентно сти для каждого значения один неправильный класс
(например
«на
ПРИЦЕПЕ»)
Если входное условие описывает ситуацию
«должно быть» (например,
«первым символом один правильный класс эквивалентно один неправильный
(первый символ — не
33 33
идентификатора должна быть буква»), сти
(первый символ
— буква) буква)
Если есть основание считать, что различные элементы класса эквивалентности трактуются программой неодинаково, то данный класс разбивается на меньшие классы эквивалентности.
Построение тестов
Этот шаг заключается в использовании классов эквивалентности для построения тестов. Этот процесс включает в себя:
Назначение каждому классу эквивалентности уникального номера.
Проектирование новых тестов, каждый из которых покрывает как можно большее число непокрытых классов эквивалентности, до тех пор, пока все правильные классы не будут покрыты (только не общими) тестами.
Запись тестов, каждый из которых покрывает один и только один из непокрытых неправильных классов эквивалентности, до тех пор, пока все неправильные классы не будут покрыты тестами.
Разработка индивидуальных тестов для неправильных классов эквивалентности обусловлено тем, что определенные проверки с ошибочными входами скрывают или заменяют другие проверки с ошибочными входами. Недостатком метода эквивалентных разбиения в том, что он не исследует комбинации входных условий.
2. Анализ граничных значений
Граничные условия — это ситуации, возникающие на, выше или ниже границ входных классов эквивалентности.
Применение метода анализа граничных условий требует определенной степени творчества и специализации в рассматриваемой проблеме. Тем не менее, существует несколько общих правил этого метода:
34 34 1.
Построить тесты для границ области и тесты с неправильными входными данными для ситуаций незначительного выхода за границы области, если входное условие описывает область значений (например, для области входных значений от -1.0 до +1.0 необходимо написать тесты для ситуаций -1.0, +1.0, -1.001 и +1.001).
2.
Построить тесты для минимального и максимального значений условий и тесты, большие и меньшие этих двух значений, если входное условие удовлетворяет дискретному ряду значений. Например, если входной файл может содержать от 1 до 255 записей, то проверить 0, 1, 255 и 256 записей.
3.
Использовать правило 1 для каждого выходного условия.
Причем, важно проверить границы пространства результатов, поскольку не всегда границы входных областей представляют такой же набор условий, как и границы выходных областей. Не всегда также можно получить результат вне выходной области, но, тем не менее, стоит рассмотреть эту возможность.
4.
Использовать правило 2 для каждого выходного условия.
5.
Если вход или выход программы есть упорядоченное множество (например, последовательный файл, линейный список, таблица), то сосредоточить внимание на первом и последнем элементах этого множества.
6.
Попробовать свои силы в поиске других граничных условий.
3. Анализ причинно-следственных связей
Метод анализа причинно-следственных связей помогает системно выбирать высокорезультативные тесты. Он дает полезный побочный эффект, позволяя обнаруживать неполноту и неоднозначность исходных спецификаций.
Для использования метода необходимо понимание булевской логики (логических операторов — и, или, не).
Построение тестов осуществляется в несколько этапов.
35 35
1.
Спецификация
разбивается
на
«рабочие
»
участки, так как таблицы причинно-следственных
связей становятся громоздкими при применении
метода к большим спецификациям.
2.
В спецификации определяются множество причин и
множество
следствий. ^ Причина есть
отдельное
входное условие или класс эквивалентности входных
условий. Следствие есть
выходное
условие
или
преобразование
системы.
Каждым
причине
и
следствию приписывается отдельный номер.
3.
На основе анализа семантического (смыслового)
содержания
спецификации
строится
таблица
истинности,
в
которой
последовательно
перебираются все возможные комбинации причин и
определяются следствия каждой комбинации причин.
4.
Каждая
строка
таблицы
истинности
преобразуется в тест.
4. Предположение об ошибке
Часто программист с большим опытом выискивает ошибки «без всяких методов». При этом он подсознательно использует метод «предположение об ошибке».
Процедура метода предположения об ошибке в значительной степени основана на интуиции.
Основная идея метода состоит в том, чтобы перечислить в некотором списке возможные ошибки или ситуации, в которых они могут появиться, а затем на основе этого списка составить тесты.
Другими словами, требуется перечислить те специальные случаи, которые могут быть не учтены при проектировании.
Общая стратегия тестирования
Все методологии проектирования тестов могут быть объединены в общую стратегию. Это оправдано тем, что каждый метод обеспечивает создание определенного набора
36 36
тестов, но ни один из них сам по себе не может дать полный набор тестов. Приемлемая стратегия состоит в следующем:
1. Если спецификация состоит из комбинации входных условий, то начать рекомендуется с применения метода функциональных диаграмм.
2. В любом случае необходимо использовать анализ граничных значений.
3. Определить правильные и неправильные классы эквивалентности для входных и выходных данных и дополнить, если это необходимо, тесты, построенные на предыдущих шагах.
4. Для получениядополнительных тестов рекомендуется использовать метод предположения об ошибке.
Задание к работе
Всем доброго времени суток, кто решил прочитать статью, посвященную документации. Здесь вы найдёте как общие, так и довольно специфические советы по созданию руководства пользователя. Надеюсь, они будут вам полезны.
Приятного чтения.
Если перед вами стоит вопрос – нужно ли вашему продукту пользовательское руководство, то отвечу сразу – да, нужно. Почему? На это есть две причины:
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 можно ознакомиться здесь:
Ниже представлен пример (образец) документа «Руководство пользователя«, разработанного на основании методических указаний РД 50-34.698-90.
Данный документ формируется IT-специалистом, или функциональным специалистом, или техническим писателем в ходе разработки рабочей документации на систему и её части на стадии «Рабочая документация».
Для формирования руководства пользователя в качестве примера был взят инструмент Oracle Discoverer информационно-аналитической системы «Корпоративное хранилище данных».
Ниже приведен состав руководства пользователя в соответствии с ГОСТ. Внутри каждого из разделов кратко приведены требования к содержанию и текст примера заполнения (выделен вертикальной чертой).
Разделы руководства пользователя:
- Введение.
- Назначение и условия применения.
- Подготовка к работе.
- Описание операций.
- Аварийные ситуации.
- Рекомендации по освоению.
1. Введение
В разделе «Введение» указывают:
- область применения;
- краткое описание возможностей;
- уровень подготовки пользователя;
- перечень эксплуатационной документации, с которой необходимо ознакомиться пользователю.
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
В разделе «Назначение и условия применения» указывают:
- виды деятельности, функции, для автоматизации которых предназначено данное средство автоматизации;
- условия, при соблюдении (выполнении, наступлении) которых обеспечивается применение средства автоматизации в соответствии с назначением (например, вид ЭВМ и конфигурация технических средств, операционная среда и общесистемные программные средства, входная информация, носители данных, база данных, требования к подготовке специалистов и т. п.).
Oracle Discoverer Plus в составе ИАС КХД предназначен для автоматизации подготовки, настройки отчетных форм по показателям деятельности, а также для углубленного исследования данных на основе корпоративной информации хранилища данных.
Работа с Oracle Discoverer Plus в составе ИАС КХД возможна всегда, когда есть необходимость в получении информации для анализа, контроля, мониторинга и принятия решений на ее основе.
Работа с Oracle Discoverer Plus в составе ИАС КХД доступна всем пользователям с установленными правами доступа.
3. Подготовка к работе
В разделе «Подготовка к работе» указывают:
- состав и содержание дистрибутивного носителя данных;
- порядок загрузки данных и программ;
- порядок проверки работоспособности.
3.1. Состав и содержание дистрибутивного носителя данных
Для работы с ИАС КХД необходимо следующее программное обеспечение:
- Internet Explorer (входит в состав операционной системы Windows);
- Oracle JInitiator устанавливается автоматически при первом обращении пользователя к ИАС КХД.
3.2. Порядок загрузки данных и программ
Перед началом работы с ИАС КХД на рабочем месте пользователя необходимо выполнить следующие действия:
- Необходимо зайти на сайт ИАС КХД ias-dwh.ru.
- Во время загрузки в появившемся окне «Предупреждение о безопасности», которое будет содержать следующее: ‘Хотите установить и выполнить «Oracle JInitiator» …’ Нажимаем на кнопку «Да».
- После чего запуститься установка Oracle JInitiator на Ваш компьютер. Выбираем кнопку Next и затем OK.
3.3. Порядок проверки работоспособности
Для проверки доступности ИАС КХД с рабочего места пользователя необходимо выполнить следующие действия:
- Открыть Internet Explorer, для этого необходимо кликнуть по ярлыку «Internet Explorer» на рабочем столе или вызвать из меню «Пуск».
- Ввести в адресную строку Internet Explorer адрес: ias-dwh.ru и нажать «Переход».
- В форме аутентификации ввести пользовательский логин и пароль. Нажать кнопку «Далее».
- Убедиться, что в окне открылось приложение Oracle Discoverer Plus.
В случае если приложение Oracle Discoverer Plus не запускается, то следует обратиться в службу поддержки.
4. Описание операций
В разделе «Описание операций» указывают:
- описание всех выполняемых функций, задач, комплексов задач, процедур;
- описание операций технологического процесса обработки данных, необходимых для выполнения функций, комплексов задач (задач), процедур.
Для каждой операции обработки данных указывают:
- наименование;
- условия, при соблюдении которых возможно выполнение операции;
- подготовительные действия;
- основные действия в требуемой последовательности;
- заключительные действия;
- ресурсы, расходуемые на операцию.
В описании действий допускаются ссылки на файлы подсказок, размещенные на магнитных носителях.
4.1. Выполняемые функции и задачи
Oracle Discoverer Plus в составе ИАС КХД выполняет функции и задачи, приведенные в таблице ниже:
| Функции | Задачи | Описание |
|---|---|---|
| Обеспечивает многомерный анализа в табличной и графической формах | Визуализация отчетности | В ходе выполнения данной задачи пользователю системы предоставляется возможность работы с выбранным отчетом из состава преднастроенных. |
| Формирование табличных и графических форм отчетности | В ходе выполнения данной задачи пользователю системы предоставляется возможность формирования собственного отчета в табличном или графическом виде на базе преднастроенных компонентов. |
4.2. Описание операций технологического процесса обработки данных, необходимых для выполнения задач
Ниже приведено описание пользовательских операций для выполнения каждой из задач.
Задача: «Визуализация отчетности»
Операция 1: Регистрация на портале ИАС КХД
Условия, при соблюдении которых возможно выполнение операции:
- Компьютер пользователя подключен к корпоративной сети.
- Портал ИАС КХД доступен.
- ИАС КХД функционирует в штатном режиме.
Подготовительные действия:
На компьютере пользователя необходимо выполнить дополнительные настройки, приведенные в п. 3.2 настоящего документа.
Основные действия в требуемой последовательности:
- На иконке «ИАС КХД» рабочего стола произвести двойной щелчок левой кнопкой мышки.
- В открывшемся окне в поле «Логин» ввести имя пользователя, в поле «Пароль» ввести пароль пользователя. Нажать кнопку «Далее».
Заключительные действия:
Не требуются.
Ресурсы, расходуемые на операцию:
15-30 секунд.
Операция 2: Выбор отчета
Условия, при соблюдении которых возможно выполнение операции:
Успешная регистрация на Портале ИАС КХД.
Подготовительные действия:
Не требуются.
Основные действия в требуемой последовательности:
1. В появившемся окне «Мастер создания рабочих книг» поставить точку напротив пункта «Открыть существующую рабочую книгу».
2. Выбрать нужную рабочую книгу и нажать кнопку «Откр.»:
Заключительные действия:
После завершения работы с отчетом необходимо выбрать пункт меню «Файл», далее выбрать пункт «Закрыть».
Ресурсы, расходуемые на операцию:
15 секунд.
Задача: «Формирование табличных и графических форм отчетности»
Заполняется по аналогии.
5. Аварийные ситуации
В разделе «Аварийные ситуации» указывают: 1. действия в случае несоблюдения условий выполнения технологического процесса, в том числе при длительных отказах технических средств; 2. действия по восстановлению программ и/или данных при отказе магнитных носителей или обнаружении ошибок в данных; 3. действия в случаях обнаружении несанкционированного вмешательства в данные; 4. действия в других аварийных ситуациях.
В случае возникновения ошибок при работе ИАС КХД, не описанных ниже в данном разделе, необходимо обращаться к сотруднику подразделения технической поддержки ДИТ (HelpDesk) либо к ответственному Администратору ИАС КХД.
| Класс ошибки | Ошибка | Описание ошибки | Требуемые действия пользователя при возникновении ошибки |
|---|---|---|---|
| Портал ИАС КХД | Сервер не найден. Невозможно отобразить страницу | Возможны проблемы с сетью или с доступом к порталу ИАС КХД. | Для устранения проблем с сетью обратиться к сотруднику подразделения технической поддержки (HelpDesk). В других случаях к администратору ИАС КХД. |
| Ошибка: Требуется ввести действительное имя пользователя | При регистрации на портале ИАС КХД не введено имя пользователя. | Ввести имя пользователя. | |
| Ошибка: Требуется ввести пароль для регистрации | При регистрации на портале ИАС КХД не введен пароль. | Ввести пароль. | |
| Ошибка: Сбой аутентификации. Повторите попытку | Неверно введено имя пользователя или пароль, либо такая учетная запись не зарегистрирована. | Нужно повторить ввод имени пользователя и пароля, однако после третей неудачной попытки регистрации учетная запись блокируется. Если учетная запись заблокирована, нужно обратиться к администратору ИАС КХД. | |
| Сбой в электропитании рабочей станции | Нет электропитания рабочей станции или произошел сбой в электропитании. | Рабочая станция выключилась или перезагрузилась. |
Перезагрузить рабочую станцию. Проверить доступность сервера ИАС КХД по порту 80, выполнив следующие команды: — нажать кнопку «Пуск» — выбрать пункт «Выполнить» — в строке ввода набрать команду telnet ias_dwh.ru 80 — если открылось окно Telnet, значит соединение возможно. Повторить попытку подключения (входа) в ИАС КХД |
| Сбой локальной сети | Нет сетевого взаимодействия между рабочей станцией и сервером приложений ИАС КХД | Отсутствует возможность начала (продолжения) работы с ИАС КХД. Нет сетевого подключения к серверу ИАС КХД |
Перезагрузить рабочую станцию. Проверить доступность сервера ИАС КХД по порту 80, выполнив следующие команды: — нажать кнопку «Пуск» — выбрать пункт «Выполнить» — в строке ввода набрать команду telnet ias_dwh.ru 80 — если открылось окно Telnet, значит соединение возможно. После восстановления работы локальной сети повторить попытку подключения (входа) в ИАС КХД. |
6. Рекомендации по освоению
В разделе «Рекомендации по освоению» указывают рекомендации по освоению и эксплуатации, включая описание контрольного примера, правила его запуска и выполнения.
Рекомендуемая литература:
- Oracle® Business Intelligence Discoverer Viewer User’s Guide
- Oracle® Business Intelligence Discoverer Plus User’s Guide
Рекомендуемые курсы обучения:
- Discoverer 10g: Создание запросов и отчетов
В качестве контрольного примера рекомендуется выполнить операции задачи «Визуализация отчетности», описанные в п. 4.2. настоящего документа.