Практическая
работа № 29
Изучить
методы разработки документации
Цель: научиться
составлять техническую документацию программного продукта.
Оборудование: компьютер
установленным программным обеспечением, методические рекомендации для проведения
практической работы.
ПО: OS Windows
XP/7/8/8.1,MS Word.
Общеобразовательные и
профессиональные компетенции:
|
Код |
Наименование результата обучения |
|
ОК 1 |
Понимать сущность и социальную значимость своей |
|
ОК 2 |
Организовывать собственную деятельность, выбирать |
|
ОК 3 |
Принимать решения в стандартных и нестандартных ситуациях и |
|
ОК 4 |
Осуществлять поиск и использование информации, необходимой для |
|
ОК 5 |
Использовать информационно-коммуникационные технологии в |
|
ОК 6 |
Работать в коллективе и в команде, эффективно общаться с |
|
ОК 7 |
Брать на себя ответственность за работу членов команды |
|
ОК 8 |
Самостоятельно определять задачи профессионального и личностного |
|
ОК 9 |
Ориентироваться в условиях частой смены технологий в |
План:
1. Изучите теоретические сведения
2. Ознакомьтесь с постановкой задачи.
3. Подготовить
отчет в тетради.
4. Ответить
на контрольные вопросы.
Теоретические
сведения.
Программная
документация, включает:
1. техническое
задание (назначение, область применения
программы, требования, предъявляемые к программе);
2.
текст программы (запись программы с необходимыми комментариями);
3.
описание программы (сведения о логической структуре и функционировании
программы);
4. пояснительная записка (схема
алгоритма, общее описание алгоритма и/или функционирования программы,
обоснование принятых решений);
5.
эксплуатационные документы.
К эксплуатационным документам относят:
–
описание применения
(сведения о назначении программы, области применения, применяемых методах,
классе решаемых задач, ограничениях для применения, минимальной конфигурации
технических средств);
–
руководство системного
программиста (сведения для проверки, обеспечения функционирования и настройки
программы на условия конкретного применения);
–
руководство программиста
(сведения для эксплуатации программы);
–
руководство оператора
(сведения для обеспечения общения оператора с вычислительной системой в
процессе выполнения программы);
–
описание языка (описание
синтаксиса и семантики языка);
–
руководство по техническому
обслуживанию (сведения для применения тестовых и диагностических программ при
обслуживании технических средств)
Основная часть программной документации составляется на стадии рабочего проекта. Необходимость того или иного
документа определяется на этапе составления технического задания. Допускается
объединять отдельные виды документов.
Эксплуатационный документ «Описание языка»
включается в программную документацию, если разработанный программный продукт
реализует некий язык программирования, управления заданиями, организации
вычислительного процесса и т. п.
Эксплуатационный документ «Руководство по техническому
обслуживанию» включается в программную
документацию, если разработанный программный продукт требует использования тестовых
или диагностических программ.
Описание применения
Документ «Описание применения» относится к
эксплуатационным документам и состоит из следующих разделов:
–
назначение программы
(возможности, основные характеристики, ограничения области применения);
–
условия применения
(требования к техническим и программным средствам, общие характеристики входной
и выходной информации, а также требования и условия организационного,
технического и технологического характера);
–
описание задачи (указываются
определения задачи и методы её решения);
–
входные и выходные данные.
–
Руководство программиста
Документ «Руководство программиста» относится к эксплуатационным документам и включается в программную
документацию, если разработанный программный продукт требует обслуживания программистом.
Документ состоит из следующих разделов:
–
назначение и условия
применения программы (назначение и функции программы, сведения о технических и
программных средствах, обеспечивающих выполнение данной программы);
–
характеристики программы
(временные характеристики, режимы работы, средства контроля правильности
выполнения и т. п.);
–
обращение к программе
(способы передачи управления и параметров данных);
–
входные и выходные данные
(формат и кодирование);
–
сообщения (тексты сообщений,
выдаваемых программисту или оператору в ходе выполнения программы и описание
действий, которые необходимо предпринять по этим сообщениям).
Руководство оператора
Документ «Руководство оператора» относится
к эксплуатационным документам и состоит из следующих разделов:
–
назначение программы
(информация, достаточная для понимания функций программы и её эксплуатации);
–
условия выполнения программы
(минимальный и/или максимальный набор технических и программных средств и т.
п.);
–
выполнение программы
(последовательность действий оператора, обеспечивающих загрузку, запуск,
выполнение и завершение программы; описываются функции, форматы и возможные
варианты команд, с помощью которых оператор осуществляет загрузку и управляет
выполнением программы, а также ответы программы на эти команды);
–
сообщения оператору (тексты
сообщений, выдаваемых оператору в ходе выполнения программы и описание
действий, которые необходимо предпринять по этим сообщениям).
Ход работы
Задание
1. Для готового программного модуля, создать руководство пользователя
программного продукта.
Документация
должна содержать необходимые сведения по установке, обеспечению надёжной работы
продукта, справочное пособие для пользователя, демонстрационные версии, примеры
документов, создаваемых при помощи данного программного продукта, обучающие
программы.
Время выполнения: 100 минут
Перечень объектов контроля и оценки
|
Наименование объектов контроля и оценки |
Основные показатели оценки результата |
|
У 4. Оформлять документацию на программные средства. |
Текстовый документ, выполненный согласно общим положениям о |
|
У 5. Использовать инструментальные средства для автоматизации |
Использование текстового редактора. |
|
З 3. Основные принципы отладки и тестирования программных |
Изложение требований к тестированию, определение граничных |
|
З 4. Методы и средства разработки технической документации |
Наличие титульного листа, постановки задачи, спецификаций, |
Контрольные
вопросы:
1.
Что такое ТЗ?
2.
Что такое руководство пользователя?
3.
Что такое руководство администратора?
4. Что такое руководство по техническому обслуживанию?
5.
Что относиться к эксплуатационным документам?
Результат
деятельности:
Отчет/вывод/классификация/ таблица/
решение/расчет/рецензия и т.д.
Защита:
Устная
Критерии
оценки:
–
Зачет/не зачет
–
Оценка
«5» — ответил на все контрольные вопросы и смог защитить практическую
работу, выполнил решение полностью без замечаний.
«4» — ответил на все вопросы, но были
погрешности в защите практической работы.
«3» — ответил не на все вопросы и не смог
защитить практическую работу.
«2» — не ответил/недостаточное кол-во ответов
для зачета.
Качественная характеристика степени умений студента
–
на стадии:
–
испытывает
затруднения
–
умеет
–
владеет
–
может
научить другого и др.
Как написать руководство пользователя программы или сайта — инструкции, советы, помощь, программное обеспечение
Журавлев Денис
Что такое руководство пользователя и для чего его создавать
Ежедневно создаются новые продукты, программы, сервисы и часто пользователям приходится несладко при освоении какой-нибудь сложной программы, поэтому каждому новому продукту желательно собственное руководство. Для чего?
Большинство людей не хочет разбираться с чем-то незнакомым без персонального, всегда доступного и понятного помощника. А именно им и является хорошее руководство пользователя.
Общие советы по созданию пользовательской документации
Перед тем как приступить к созданию руководства, нужно определиться с некоторыми важными моментами. Например, определить, для кого вы его пишете? Кто его будет читать — рядовые пользователи, для которых важны базовые функции продукта, или люди, которым нужны особые, нечасто используемые функции программы/сервиса.
После этого важно подумать о том:
- Где пользователь будет к нему обращаться: дома, на работе, в машине?
- Как часто он будет его просматривать?
- Насколько объективно сложен для понимания продукт?
Из этого можно сделать вывод, насколько интенсивно пользователь будет работать с документацией, а значит уже можно выбрать между сжатым «справочником» или объемным «путеводителем» Также важно, чтобы руководство писал профессионал, знающий продукт. Так что по возможности делегируйте написание техническому специалисту или аналитику, у которого есть полное представление о всех тонкостях продукта.
Определившись со всеми представленными пунктами, станет понятнее, какой нужно использовать стиль изложения, какого объема написать текст. Но помните, что излишне стилистически окрашенные слова мешают пользователю добраться до сути. Так что лучшим вариантом в большинстве случаев будет нейтрально-формальный стиль. Пишите так, чтобы пользователь вас понял. Постарайтесь по возможности избегать технических терминов, но проанализируйте — не сделает ли полное отсутствие терминов ваше руководство бесполезным?
Структура руководства пользователя
После того как вы ответили на предыдущие вопросы, создайте структуру руководства. У любого хорошего «путеводителя» хорошая и логичная структура. Начните с оглавления. Информативное содержание поможет читателю легко ориентироваться в документе.
В первом разделе желательно рассказать общую информацию о программе:
- Для чего создан продукт.
- Какие задачи он решает.
- Какие основные выгоды от использования для клиента.
В следующем разделе можно указать основные элементы пользовательского интерфейса. Пользователю будет трудно разобраться в софте, если он не поймёт для чего служат различные элементы интерфейса, или он не разберётся в основных режимах работы ПО. Опишите понятным языком предназначение экранов и окон.
Создайте раздел, где расскажете о наиболее эффективных способах применения продукта для решения типовых задач. Какие цели стоят перед клиентом, и как ваша программа/сервис помогает достичь их. Укажите информацию о том, как быстро и продуктивно пользоваться программой.
Ни одно руководство не обойдется без таких разделов как: «Частые вопросы» и «Устранение типовых проблем» В них разбираются вопросы и проблемы, с которыми часто сталкиваются пользователи. Для заполнения данного раздела вам скорее всего понадобятся уже готовые отзывы клиентов. Если у вас абсолютно новый продукт, вы можете предугадать проблемы ваших клиентов либо на первое время не включать данный пункт в ваше руководство.
Иногда технические писатели забывают о важном моменте в руководстве пользователя — контактная информация. Этот раздел поможет пользователям связаться с вами, даже если у них нет никаких вопросов и руководство полностью закрывает все их потребности. Клиент может дать совет, поделиться опытом или предложить выгодное вам сотрудничество.
Инструменты для быстрого создания руководства пользователя
Но как создать руководство пользователя, если пишешь его впервые? Или что делать, если руководство пользователя нужно постоянно обновлять и дорабатывать? Или нужны особые функции, которых нет в традиционных текстовых редакторах, например, в 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 — инструмент для создания мобильной версии пользовательской документации к программным продуктам
- Шаблоны файлов помощи, руководства пользователя программного обеспечения или сайта, шаблон базы знаний — бесплатные шаблоны и примеры пользовательской документации
Цель
работы: разработать документацию
для пользователя, разработать справочную
систему для программного продукта.
Постановка
задачи: разработать программный
документ «Руководство пользователя»
для программного продукта «Калькулятор
комплектующих ПК». На основе созданного
документа разработать справочную
систему.
1. Назначение
программы.
Калькулятор
комплектующих ПК – программа,
предназначенная для сборки настольного
компьютера по отдельным комплектующим.
С помощью приложения «Калькулятор
комплектующих ПК» пользователь может
быстро и с экономией бюджета собрать
собственную сборку системного блока.
2. Условия
выполнения программы.
Минимальные
системные требования для успешного
выполнения программного продукта
«Калькулятор комплектующих ПК»:
– операционная
система: Windows XP;
– оперативная
память: 256 Мб;
– процессор: Intel
Celeron с тактовой частотой 233 МГц;
– видеоадаптер: видеокарта
с поддержкой DIRECTX 9;
– свободное
место на жестком диске: 20 Мб.
3. Выполнение
программы.
Для
запуска программы «Калькулятор
комплектующих ПК» нужно дважды нажать
левой кнопкой мыши по исполняемому
файлу «kalkkomppk.exe».
После того, как программа запустилась,
на экране появиться главная форма
программного продукта «Калькулятор
комплектующих ПК», внешний вид которой
представлен на рисунке 3.9.
Рисунок
3.9 – Главная форма программы
«Калькулятор
комплектующих ПК»
На
главной форме программы «Калькулятор
комплектующих ПК» располагаются
следующие элементы: главное меню,
панель быстрых кнопок, вкладки с
комплектующими компьютера, таблицы,
выпадающие списки, список текстовых
полей, текстовые поля с ценами, панель
состояния.
Главное
меню содержит следующие
пункты: «Файл» – «Выход»;
«Действия» – «Фильтр», «Сумма»,
«Вставить в БД»; «Компоненты» –«Процессор»,
«Видеокарта», «Материнская плата»,
«Оперативная память», «Жесткий диск и
SSD»;
«Помощь» – «Справка о программе».
Панель
быстрых кнопок состоит из следующих
кнопок, которые дублируют функции
пунктов главного меню: «Фильтр»,
«Сумма», «Вставить в БД», «Справка о
программе». Внешний вид панели быстрых
кнопок программы «Калькулятор
комплектующих ПК» изображен на рисунке
3.10.
Рисунок
3.10 – Панель быстрых кнопок
Каждая
комплектующая имеет свою вкладку, внутри
которой находится таблица с записями
о комплектующих компьютера. Вкладки с
названиями комплектующих представлены
на рисунке 3.11.
Рисунок
3.11 – Вкладки с комплектующими компьютера
Список
текстовых полей содержит названия
выбранных комплектующих компьютера.
Каждое текстовое поле закреплено за
определенным комплектующим компьютера.
Внешний вид текстовых полей с названиями
комплектующих представлен на рисунке
3.12.
Рисунок
3.12 – Текстовые поля с названиями
комплектующих
Панель
состояния предназначена для отображения
подробного описания того или иного
элемента пользовательского интерфейса
программы. Для того чтобы увидеть
подробное описание элемента интерфейса,
на этот элемент нужно навести указателем
мыши. Панель состояния с подсказкой для
кнопки «Поиск» представлена на рисунке
3.13.
Рисунок
3.13 – Панель состояния с подробными
подсказками
Для
того чтобы выбрать комплектующую и
добавить ее в список, нужно один раз
нажать левой кнопкой мыши на строчку в
таблице с названием определенной
комплектующей. Нажатая строчка выделится
синим цветом так, как показано на рисунке
3.14.
Рисунок
3.14 – Выделение синим цветом выбранной
комплектующей
После
нажатия на запись название выбранной
комплектующей отобразиться в
соответствующем текстовом поле, а справа
от текстового поля с названием появится
цена выбранной комплектующей. Заполненные
текстовые поля с названием и ценой
представлены на рисунке 3.15.
Рисунок
3.15 – Название и цена выбранной
комплектующей компьютера
Для
того чтобы выполнить поиск определенной
комплектующей необходимо в выпадающих
списках выбрать желаемые параметры
так, как показано на рисунке 3.16. В
программе реализована возможность
поиска комплектующих компьютера по
одному или нескольким параметрам.
Рисунок
3.16 – Выбор параметров для поиска из
выпадающих списков
После
того, как выбраны параметры для поиска,
нужно нажать либо на кнопку «Фильтр»,
расположенную на панели быстрых кнопок,
либо нажать сочетание клавиш «Shift+F»,
либо зайти в раздел главного меню
«Действия» и выбрать пункт «Фильтр»
для того, чтобы был выполнен поиск
комплектующей по выбранным параметрам.
Когда
выбраны все комплектующие, то в правом
нижнем углу будет указана итоговая цена
системного блока так, как показано на
рисунке 3.17.
Рисунок
3.17 – Результат работы программы
«Калькулятор
комплектующих ПК»
4. Сообщения
пользователю.
При
работе с программой «Калькулятор
комплектующих ПК» у пользователя могут
возникнуть вопросы по элементам
графического пользовательского
интерфейса. Например, что делает та или
иная кнопка, или, что выводится в то или
иное текстовое поле. Для ответа на эти
вопросы существует строка состояния,
в которую выводятся подробные описания
того или иного элемента графического
пользовательского интерфейса программы.
Для того чтобы увидеть подробное описание
элемента интерфейса программы, на этот
элемент нужно навести указателем мыши.
Также
в программе «Калькулятор комплектующих
ПК» существуют различные всплывающие
диалоговые окна. Ниже приведен список
этих окон:
– диалоговое
окно при выходе из программы;
– диалоговое
окно при добавлении новой записи о
комплектующей компьютера в таблицу
базы данных, которое указывает, что не
все поля заполнены, и запись в таблицу
добавлена не будет;
– диалоговое
окно при удалении записи о комплектующей
компьютера из таблицы базы данных.
Результаты
выполнения лабораторной работы: в
рамках данной лабораторной работы был
разработан программный документ
«Руководство пользователя» для приложения
«Калькулятор комплектующих ПК». В
документе «Руководство пользователя»
были указаны сведения о назначении,
функциональных особенностях и системных
требованиях программы «Калькулятор
комплектующих ПК». Также был описан
порядок работы с программой, было
приведено описание функций и
пользовательского интерфейса. На основе
документа «Руководство пользователя»
в программе HTML
Help Workshop
была создана справочная система для
программного приложения «Калькулятор
комплектующих ПК».
ЗАКЛЮЧЕНИЕ
Выпускная
квалификационная работа была посвящена
разработке учебно-методического
комплекса
по дисциплине «Разработка программных
приложений». Созданный учебно-методический
комплекс имеет удобную структуру и
содержит всю необходимую информацию
для самостоятельного изучения и освоения
дисциплины «Разработка программных
приложений».
В
целях
повышения
качества восприятия методической
информации
учебно-методический
комплекс был
разработан в электронном виде.
Электронный учебно-методический комплекс
представляет собой веб-сайт,
который можно использовать
на любом локальном компьютере без
доступа к интернету.
Все страницы
были
оформлены
с помощью языков HTML
и CSS.
Разработанный
учебно-методический комплекс предназначен
для использования студентами очной
формы обучения, направления 230700.62 –
«Прикладная информатика», профиля
«Прикладная информатика в экономике»,
изучающих дисциплину «Разработка
программных приложений». Методический
комплекс будет оказывать помощь в
изучении и систематизации теоретических
знаний, а также будет формировать
практические навыки работы в предметной
области с использованием современных
информационных технологий.
В
ходе выполнения выпускной квалификационной
работы были выполнены все поставленные
задачи:
1. Разработана
структура учебно-методического комплекса
по дисциплине «Разработка программных
приложений».
2. Разработана
рабочая программа, которая содержит
основные сведения по дисциплине
«Разработка программных приложений».
3. Определены
требования для учебно-методического
материала, а также для электронного
учебно-методического комплекса по
дисциплине «Разработка программных
приложений».
4. Подобраны
программные и инструментальные средства
для создания электронного учебно-методического
комплекса по дисциплине «Разработка
программных приложений».
5. Разработан
макет для электронного учебно-методического
комплекса по дисциплине «Разработка
программных приложений».
6. Сверстан
макет для электронного учебно-методического
комплекса по дисциплине «Разработка
программных приложений».
7. Приведены
результаты проделанной работы, а именно:
– представлены
содержания разделов по дисциплине
«Разработка программных приложений»;
– представлены
содержания лабораторных работ по
дисциплине «Разработка программных
приложений»;
– представлены
веб-страницы электронного учебно-методического
комплекса по дисциплине «Разработка
программных приложений».
Таким
образом, в результате выпускной
квалификационной работы был создан
учебно-методический комплекс по
дисциплине «Разработка программных
приложений», который может быть внедрен
в процесс обучения и успешно использоваться
преподавателями и студентами.
СПИСОК
ЛИТЕРАТУРЫ
1. Рудаков
А.В., Федорова Г.Н. Технология разработки
программных продуктов. Практикум. –
М.: Академия, 2012. – 192 с.
2. Лешек
Мацяшек. Практическая программная
инженерия на основе учебного примера.
– М.: Бином. Лаборатория знаний, 2012. –
956 с.
3. Орлов
С.А. Прогаммная инженерия. Учебник для
вузов. – СПб.: Питер, 2016. – 640 с.
4. Гагарина
Л.Г. Разработка и эксплуатация
автоматизированных информационных
систем. Учебное пособие. – М.: Инфра-М,
2015. – 384 с.
5. Алан
Купер, Роберт Рейман, Дэвид Кронин и
Кристофер Носсел. Интерфейс. Основы
проектирования взаимодействия. – СПб.:
Питер, 2017. – 720 с.
6. Тео
Мандел. Разработка пользовательского
интерфейса. – М.: Книга по Требованию,
2001. – 410 с.
7. Джеф
Раскин.
Интерфейс. Новые направления в
проектировании компьютерных систем. –
СПб.: Символ-Плюс, 2007. – 272 с.
8. Алфимцев
А.Н. 25
упражнений по юзабилити. – Саарбрюккен:
LAP Lambert Academic Publishing, 2014. – 108 с.
9. Макаровских
Т.А. Документирование программного
обеспечения. В помощь техническому
писателю. Учебное пособие. – М.: Ленанд,
2015. – 266 с.
10. Глаголев
В.А. Разработка технической документации.
Руководство для технических писателей
и локализаторов ПО. – СПб.: Питер, 2008. –
192 с.
11. Фленов
М.Е. Библия Delphi.
– СПб.: БХВ-Петербург, 2011. – 688 с.
12. Дарахвелидзе
П.Г., Марков Е.П. Программирование в
Delphi
7. – СПб.:
БХВ-Петербург, 2003. – 784 с.
13. Хоменко
А.Д., Гофман В.Э., Мещеряков Е.В. Delphi
7. – СПб.:
БХВ-Петербург, 2010. – 1136 с.
14. Шкрыль
А.А. Разработка клиент-серверных
приложений в Delphi. – СПб.: БХВ-Петербург,
2006. – 480 с.
15. Кириллов
В.В., Громов Г.Ю. Введение в реляционные
базы данных. – СПб.: БХВ-Петербург, 2009.
– 464 с.
16. Хоменко
А.Д., Гофман В.Э. Работа с базами данных
в Delphi. – СПб.: БХВ-Петербург, 2005. – 640 с.
17. Осипов
Д.Л. Базы данных и Delphi. Теория и практика.
– СПб.: БХВ-Петербург, 2011. – 752 с.
18. Астахова
И.Ф., Мельников В.М., Толстобров А.П.,
Фертиков В.В. СУБД: язык SQL в примерах и
задачах. – М.: Физматлит, 2009. – 168 с.
19. Маркин
А.В. Построение запросов и программирование
на SQL. Учебное пособие. – М.: Диалог-Мифи,
2014. – 384 с.
20. Дунаев
В.В. Базы данных. Язык SQL. – СПб.:
БХВ-Петербург, 2006. – 288 с.
21. Кисленко
Н.П. HTML.
Самое необходимое. – СПб.: БХВ-Петербург,
2008. – 352 с.
22. Петюшкин
А.В. HTML
в
Web-дизайне.
– СПб.: БХВ-Петербург, 2004. – 400 с.
23. Луис
Лазарис. CSS.
Быстрый старт. – М.: Эксмо, 2014. – 192 с.
24. Джон
Дакетт. HTML
и CSS.
Разработка и дизайн веб-сайтов. – М.:
Эксмо, 2013. – 480 с.
25. Захарова
И.Г. Информационные технологии в
образовании. – М.: Академия, 2013. – 192 с.
26. Федеральные
государственные образовательные
стандарты высшего профессионального
образования по направлениям подготовки
бакалавриата. URL: http://fgosvo.ru/fgosvpo/7/6/1
(дата обращения
–
20.03.2017).
27. ГОСТ
Р 55751-2013. Информационно-коммуникационные
технологии в образовании. Электронные
учебно-методические комплексы. Требования
и характеристики. – М.: Стандартинформ,
2014. – 11 с.
28. Шалкина
Т.Н., Запорожко В.В., Рычкова А.А. Электронные
учебно-методические комплексы:
проектирование, дизайн, инструментальные
средства. –
Оренбург: ГОУ
ОГУ,
2008.
– 160
с.
29. Фреймворк
Bootstrap
| ИТ Шеф.
URL: https://itchief.ru/lessons/bootstrap-3
(дата
обращения – 28.03.2017).
30. НОУ
ИНТУИТ | Лекция | Создание
справочной системы.
HTML
Help Workshop.
URL: http://www.intuit.ru/studies/courses/13745/1221/lecture/23323
(дата обращения – 13.05.2017).
Писать руководство пользователя по шаблону. Удобно? Удобно
Время на прочтение
4 мин
Количество просмотров 5.1K
Команда, разрабатывающая софт для создания пользовательской документации, делится лайфхаками на тему написания идеальной пользовательской документации для тех, кто далёк от написания руководств к программе.
Для чего мы сами конструируем некоммерческие образцы документации и инструкций для пользователей
Наш проект существует и развивается уже долгое время, практически шестнадцать лет, если быть точнее. За этот срок была сформирована определенная база, где собраны самые актуальные и насущные вопросы, которые возникают перед людьми, создающими справочные элементы к своему проекту.
Ведя диалог с нашими клиентами, мы смогли выделить их потребности и понять основную «боль». Если обобщить, основная проблема заключалась в том, что ни одна программа для создания файл-справок и инструкций не могла выполнить самую нудную, энергозатратную часть проекта — само разрабатывание и оформление этой пользовательской документации
Даже имея осознание того, что файл-справка — неотъемлемый и действительно полезный элемент для пользователя, очень редко возникает мотивация оформить его грамотно и качественно. Еще реже желание возникает, когда в написании пользовательской документации нет опыта или специалистов, которые бы этот опыт имели. Обычно, эта обязанность с легкой руки падает на плечи самих создателей программы, людей, занимающихся тестированием, аналитикой, специалистам поддержки или даже руководителей компании, которые тоже не совсем понимают, как грамотно создать что-то подобное.
Отсюда вытекает еще одна загвоздка. Люди, у которых нет опыта и в принципе понимания, как начать и что туда вносить, просто не знают, как создать качественное руководство для пользователей. В таких случаях большинство следует привычному пути: загуглить определение и найти готовый шаблон.
И с какой-то стороны, это разумно. Мы достаточно часто сталкиваемся с такими запросами, пользователи просят у нас пошаговое руководство или хотя бы костяк готовой инструкции.
Так вышло, что потребности наших клиентов практически на сто процентов входят в нашу экспертную сферу. И мы приняли решение по возможности помочь всем, кто хочет (или вынужден) заниматься созданием файл-справок и инструкций к своему продукту и предоставить возможность получить образцы, которые могут послужить базой и легко быть адаптированными под конкретный запрос.
В связи с этим, мы сами создали готовые образцы и костяки шаблонных проектов в программе. Что входит в нашу базу:
-
Руководство пользователя программного обеспечения.
-
Руководство пользователя 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. Для получениядополнительных тестов рекомендуется использовать метод предположения об ошибке.
Задание к работе
Автор: Виктор Амосов, аналитик компании Индиго Байт, которая разрабатывает программу для управления технической документацией.
В наше время тестировщика часто заставляют писать техническую документацию к продукту. И на это есть ряд очевидных причин. Тестировщик как никто другой знаком с функционалом ПО, знает все его тонкости, знаком со всеми проблемами и ошибками. Но тестировщик — не писатель, а документация, которую будет читать пользователь, должна быть понятна и легко читаема. Так как же написать качественную документацию, которая будет отвечать всем запросам пользователей?
Данная статья предлагает правила написания и проверки технической документации, а также инструменты, для упрощения работы «технического писателя».
Советы по созданию пользовательской документации
Мы стремимся создавать документацию, которая будет полезна. То есть мы хотим, чтобы наши пользователи оперативно находили нужные разделы и применяли их для решения своих задач при работе с программным продуктом. Я опираюсь на девять эмпирических правил или эвристик удобства использования документации при разработке, оценке и правке технического контента до того, как документация будет опубликована. Применение этих эвристик может помочь техническим писателям не совершать классических структурных ошибок и даст более глубокое понимание того, как пользователи работают с документацией.
Правила качественной документации, описанные в этой статье, основываются на десяти основных принципах юзабилити в дизайне, разработанных Jakob Nielsen и Rolf Molich в 1990 году. Однако — мне пришлось переработать многие из них на основе собственного опыта по оценке качества документации.
1. Поиск и навигация
Самое, казалось бы, простое и очевидное правило – но из раза в раз сталкиваюсь с этой проблемой в руководствах – кнопка поиска по документации спрятана или вовсе отсутствует.
У пользователя должна быть возможность находить нужный раздел, пользуясь поиском или перемещаясь по оглавлению. Если требуется прочитать несколько разделов, переход между ними должен быть простым.
2. Ориентирование
В любой момент пользователь должен понимать, в какой части документации он находится и где он был перед этим. Выстраивайте разделы так, чтобы их логика соответствовала логике пользователя и логике выполнения сложных задач.
Как понять логику пользователя? На самом деле, тут точного ответа нет, но есть базовые вещи, в которых писатели до сих пор совершают ошибки. Вряд ли пользователю сразу понадобится контактная информация вашей компании, так что ее лучше разместить в конце, а вот разделы с объяснением элементов интерфейса и описанием возможностей программы поместите в начале.
Поставьте себя на место пользователя. С какой проблемой он столкнется в первую очередь, какие затруднения будут потом, и примерно в таком порядке составляйте руководство.
3. Решение задач
Пользуясь документацией и переходя от раздела к разделу, пользователь должен идти по самому эффективному пути при достижении своих целей. Поэтому, если проблема имеет два пути решения, то описывайте только самый простой и эффективный способ ликвидации проблемы.
4. Обобщение задач
Пользователь должен быть способен экстраполировать информацию из документации на ситуации, которые не задокументированы явным образом. Например, он должен понимать, как входные данные соответствуют различным режимам работы программы.
Нецелесообразно описывать в руководстве похожие ситуации по отдельности, так как оно станет громоздким и трудночитаемым. Обобщите и напишите об одном так, чтобы пользователь смог понять и применить полученные знания на похожие случаи.
5. Диагностика ошибок и устранение их последствий.
Пользователя надо научить не бояться проблем и решать их.
Говорить о своих проблемах – лучше, чем умалчивать…
В каждой программы возможны баги… Вы знаете о них, но пока нет времени исправлять? Лучше напишите и предупредите пользователя. Следуя моему опыту, лучше «признать» ошибку и показать себя, возможно, не с лучшей стороны, чем промолчать и потом терять клиентов из-за их неоправданных ожиданий. Если у пользователя будет инструкция по ликвидации проблем – он вряд ли задумается о смене программы.
Ну и, конечно же, создайте раздел в руководстве с контактами технической поддержки и ее режимом работы, чтобы пользователь мог обратиться за помощью.
6. Соответствие между документацией и реальным миром с точки зрения терминов и концепций
Чаще всего документацию к продукту пишут те, кто его создает или тестирует. Это логично и нормально, но не стоит забывать, что читать ее будут другие люди, которые, скорее всего, далеки от программирования. Им будут не понятны такие слова и выражения: деплой, релиз, инкапсуляция и так далее.
Документация должна использовать язык и концепции, которые знакомы пользователю, и стоит избегать профессиональной терминологии и жаргона. Очень важно придерживаться системы ключевых слов, которые будут использоваться людьми в документации при поиске решений своих проблем.
7. Писательский минимализм
Следует избегать ненужной и иррелевантной информации. Каждый дополнительный блок информации в документации будет конкурировать за пользовательское внимание. Это осложнит пользователю поиск нужной информации.
8. Согласованность и стандарты.
Читатель не должен догадываться, означают ли разные слова, ситуации и действия одну и ту же вещь. Несогласованность перегружает мозг и мешает быстрому решению задач. Следуйте конвенциям, принятым для данной платформы, отрасли или типа программ.
Если что-то принято называть «разделом», то надо придерживаться этого термина, и не использовать альтернативы — «секция, топик, тема».
9. Интеграция с программным продуктом.
Пользователю грустно видеть программу, в которой он не может открыть «файл-помощник»!
Пользователь не должен прерывать процесс работы в программе для того, чтобы обратиться к документации. Старайтесь реализовать функцию поиска по документации прямо из программы, а также сделайте контекстно-зависимую справку.
А вообще, документация должна быть многоформатной! Пользователь может читать документацию и не работая в программе, поэтому следует загрузить документацию на сайт, тем самым сделав online-справку. Также стоит разместить на сайте PDF версию документации, для случаев, если у пользователя нет доступа к интернету.
Мини-итог
Прежде чем проводить оценку документации, определитесь с предполагаемой целью, которую многие пользователи пытаются достичь с помощью программного продукта. При этом неплохо удостовериться, что эта цель, стоящая перед большинством пользователей, согласуется с целью, которую компания-разработчик закладывала в продукт. Например, компания производит, как она полагает, «программу для моделирования», в то время как пользователь хочет «моделировать контроллеры».
Запустите программу. Затем решите задачу как обычный пользователь, пользуясь документацией. Вы также можете привлечь пару друзей для этого. Поскольку ваши приятели скорее всего меньше знакомы с вашей документацией, имитировать обычных пользователей и их работу в программе у них получится гораздо лучше.
Инструменты для быстрого создания руководства пользователя
Используя вышеперечисленные советы, думаю вам станет проще писать документацию, но кроме вопроса КАК писать документацию еще важен вопрос ГДЕ.
Я много лет «кручусь» в области технического писательства, потому что создаю и модернизирую свой собственный продукт для создания качественных «хэлпов»
И на правах рекламы мне хочется о нем рассказать. Возможно именно с ним вам станет проще создавать и поддерживать пользовательскую документацию. Понимаю, что рекламные части статей отталкивают читателей, поэтому я постараюсь сделать его кратким и лаконичным.
Далее вы ознакомитесь с некоторыми возможностями программы для создания руководства пользователя – Dr.Explain.
1. Аннотирование
Часто техническим писателям при документировании пользовательского интерфейса приходится снабжать изображения пояснительными выносками. Для того, чтобы этот процесс стал проще и быстрее программа умеет автоматически аннотировать изображения. Это значит, что при создании скриншота программа проанализирует структуру окна и добавит пояснительные выноски к значимым элементам. (по ее мнению конечно же) Но вы также сможете добавлять аннотации к скриншоту или фотографии самостоятельно – для этого есть специальный редактор аннотирования скриншотов.
2. Шаблоны
Гораздо проще работать по образцу. Для этого в Dr.Explain есть шаблоны руководств пользователя. В них разделы уже частично заполнены текстовым и графическим контентом. В некоторых случаях писателю, работающему в шаблоне, нужно будет только вставить текст из разряда: название программы, имя компании или адрес технической поддержки. В программе на данный момент есть три шаблона – для ПО, для WEB-сервиса и для корпоративной базы знаний.
3. Многоформатность.
Я говорил уже о том, что документация должна быть многоформатной, и это не моя прихоть, а требование эпохи. Например, для того, чтобы программе попасть в Реестр Отечественного ПО, сейчас обязательно наличие онлайн-документации.
В Dr.Explain, имея текстовый документ, вы сможете:
— экспортировать его на сайт продукта в формате HTML, тем самым создать online-справку;
— сделать контекстно-зависимую справку в формате CHM для интеграции с ПО;
— экспортировать текст в формат PDF для создания «печатной» документации;
В программе множество функций для облегчения работы по написанию документации. Вы можете ознакомиться с ними по адресу: https://www.drexplain.ru/features/
Скачать Dr.Explain бесплатно можно по адресу: https://www.drexplain.ru/download/
Подытожим
Создание и написание хорошей пользовательской документации — это труд, который требует много времени и усилий. Но если успешно справиться с задачей, можно навсегда получить лояльных и довольных клиентов. Не забывайте о том, что недовольство от некачественного руководства может быть спроецировано пользователем на сам продукт и повлиять на дальнейшее решение о переходе на аналогичные программы.
Успешных вам разработок!
Обсудить в форуме
Многие согласятся, что написание документации пользователя к ПО или сервису нелегкая задача.
Разработчики часто откладывают создание подобной документации в долгий ящик, поскольку считают ее трудоемкой, требующей дополнительных расходов или прямо-таки скучной.
Нужно досконально изучить программу, предсказать, с какими трудностями могут столкнуться пользователи, описать все возможности продукта, создать логичную структуру, добавить достаточно скриншотов и пояснений. И когда все будет готово – выложить документацию на сайт продукта и/или внедрить справку в ПО.
Часто подобную документацию пишут в текстовых редакторах, но это значительно усложняет и без того скучный процесс. Специализированное ПО имеет множество функций, упрощающих процесс создания руководства. Например, возможность структурировать будущую документацию, создавать разделы, делать пояснения на скриншотах, экспортировать контент в различные форматы (HTML, CHM, PDF) и многое другое.
Если вам не нравится процесс документирования продукта, над которым вы работаете, этот обзор для вас.
В нем мы расскажем, про лучшие инструменты для создания пользовательской документации на рынке, которые превратят эту тяжелую и, казалось бы, невыполнимую задачу – в легкую прогулку.
Но разве техническая поддержка не может стать заменой документации?
— Скорее нет, чем да. Есть внушительное число пользователей, которые с радостью обратятся к справочной документации, нежели будут писать в поддержку, ждать ответа, общаться с людьми.
— Поддержка может подвести. Случайно или из-за некомпетентности сотрудников. Грубость техподдержки – тоже нередкое явление.
Также, техподдержку могут просто завалить вопросами, и она не будет успевать отвечать.
Подобные случаи негативно сказываются на репутации и лучше заранее застраховаться. Например – создать руководство пользователя.
Сегодня мы подобрали для вас 5 лучших программ и сервисов для создания пользовательской документации, которые, по нашему мнению, лучше всего подходят для своей роли.
1. Dr.Explain
Операционная система – Windows
Цена – от 10 000 рублей в год или 16000 рублей навсегда в рамках старшей версии (есть бесплатная версия)
Dr.Explain – одна из немногих программ, которая автоматизирует процесс создания документации пользователя. При написании документации перед писателем стоит задача наглядно показать, как все работает и где что находится. Для этого в руководства вставляют скриншоты с пояснениями к элементам интерфейса программы. В Dr.Explain есть специальный инструмент, который выделяет все важные элементы на скриншоте, например, кнопки или поля, и добавляет к ним аннотации (выноски) с пояснениями. Все что останется сделать писателю – снабдить их описаниями.
Второе, что бросается в глаза, когда изучаешь возможности программы — встроенные шаблоны документации. Всегда проще работать по образцу, смотреть на пример документации, дополнять и видоизменять под свой продукт. Именно это и предлагает Dr.Explain. В программе существует три шаблона документации: руководство пользователя для ПО, руководство пользователя для web-сервиса и шаблон корпоративной базы знаний.
Как бы хорошо программа не помогала писать документацию, конечная цель – это публикация контента на сайте продукта и интеграция его в продукт, чтобы пользователи могли прочитать ваше руководство. Dr.Explain позволяет экспортировать ваш проект в популярные форматы: HTML – для сайта, CHM – для встроенной в ПО справки и PDF.
Dr.Explain позволяет работать в команде через облачный сервис или локальный сервер. В программе можно задавать разделам «степень готовности». Так вы сможете контролировать процесс написания справки.
В программе имеется удобный и продуманный WYSIWYG (What You See Is What You Get, «что видишь, то и получишь») редактор, возможность настраивать стиль вашей документации, возможность настроить контекстно-зависимую справку и что немаловажно – в ней есть русский интерфейс, так как Dr.Explain – проект отечественной команды разработчиков и продукт включен в реестр отечественного ПО.
+ Большой перечень возможностей, позволяющих создать качественное и полное руководство пользователя (аннотирование скриншотов, шаблоны документации и т.д.)
+ Русский интерфейс
+ Простая оплата для российских пользователей
Минусы:
— Отсутствие веб-интерфейса
— Отсутствие версии для Mac и Linux
— Нет вывода в ePub, markdown и другие специфические форматы
2. HelpnDoc
Операционная система – Windows
Цена – от $99 в год (есть бесплатная версия)
Главный плюс HelpnDoc – возможность экспорта в невообразимое множество форматов, тем самым возможность создания мультиформатной документации.
Создаёте документацию для мобильного приложения? Вашим пользователям нужно читать документацию с электронной книги? Нужно создать документацию к продукту на Linux, Ubutu, UNIX? Эта программа поможет.
Мощная система медиабиблиотеки. Все медиа-элементы, такие как изображения, видео, документы, фрагменты HTML-кода, управляются библиотекой: эти медиа-элементы можно использовать повторно много раз.
Нужно изменить одну картинку, а она размещена в документации десятки раз? Просто обновите элемент библиотеки, и он будет распространен на все темы, использующие его.
Благодаря редактору сценариев можно легко автоматизировать повторяющиеся задачи и сфокусировать своё внимание на сложных. Вам нужно изменить порядок тем? Заменить все элементы библиотеки? Запустите редактор сценариев, введите несколько инструкций, нажмите «Выполнить», после чего часть рутинной работы будет выполнена автоматически.
HelpnDoc анализирует написанную документацию и может показать вам неработающие ссылки, ссылки с ошибками, отсутствующие или дублирующие элементы мультимедиа. Все подобные ошибки можно увидеть в одном месте (анализаторе) и сразу же приступить к их устранению.
Плюсы:
+ Возможность создания мультиформатной документации.
+ «Сценарии» значительно упрощают и ускоряют процесс написания руководства
+ Умный анализ и проверка вашего проекта.
Минусы:
— нет русского интерфейса, и если вы будете создавать руководство на русском языке, то некоторые возможности по анализу и проверке будут недоступны.
— сравнительно сложный пользовательский интерфейс.
— сложность с оплатой лицензий для российских пользователей.
3. ClickHelp
Операционная система – любая.
Цена – от $50 в месяц.
ClickHelp в отличие от двух предыдущих – не программа, это web-сервис для создания документации.
Сервис полезен для продуктов, которые хотят выйти на международный рынок. В ClickHelp существует возможность перевода вашего руководства на любой язык, при помощи Google, конечно. Что немаловажно, изменяя исходный текст, изменения будут отображаться во всех переведенных вариантах на этих же языках.
Представьте, что пользователи открывают руководство и пытаются найти что-то по определенной теме. Вводят в поиск термин и им выдается все множество совпадений, которые только есть.
Специально для этого в ClickHelp есть ряд функций, чтобы клиенты всегда могли найти ответ на свой вопрос:
— Система полнотекстового поиска, в которой читатель можете осуществлять поиск по всему порталу документации или только по определенному набору руководств пользователя. Она обрабатывает формы слов и времена, чтобы читатели могли использовать естественный язык, учитывает близость терминов и другие факторы при ранжировании результатов.
— Система индексов. Если вы думаете, что пользователю все равно будет трудно найти какую-то информацию в вашей документации – система индексов или таксономий в ClickHelp решит эту проблему. Данная функция предназначена для того, чтобы сделать темы доступными для поиска по терминам, которые не находятся непосредственно в их содержании. Например, если в документации есть тема о SSL-шифровании, вы можете присвоить ей индексное ключевое слово «безопасность», и даже если в теме нет ни единого упоминания «безопасности» или каких-либо производных, она все равно будет доступны для поиска по этому термину.
В ClickHelp можно работать в команде. Сервис позволяет следить за процессом разработки, оставлять комментарии, от которых уведомления будут приходить на почту, раздавать роли.
Плюсы:
+ Возможность работы в команде через веб-интерфейс и отслеживание результатов.
+ Поиск по документации.
+ Автоматический перевод документации на любые языки.
Минусы:
— Достаточно сложный в освоении продукт и интерфейс только английский, что усложнит задачу понимания сервиса и его функций.
— Высокая стоимость лицензии.
— Нет возможности работать в offline-режиме.
4. HelpSmith
Операционная система – Windows
Цена – от $199.
Одной из основных возможностей HelpSmith является создание нескольких форматов справки из единого источника. Таким образом, имея один исходный текст, вы можете экспортировать его в HTML для создания веб-справки, в PDF, MS Word, а также в формат ePub для электронных книг.
Программа имеет встроенный инструмент по работе с изображениями, чем-то напоминающий Dr.Explain. В нем вы можете редактировать изображения и добавлять к ним аннотации. Кроме того, всё медиа, которое вы используете в проекте, хранится в едином репозитории, что упрощает процесс обновления и сохранения изображений в документации.
Для опытных технических писателей HelpSmith предоставляет гибкие возможности условной компиляции, позволяющие создавать разные версии одного и того же файла справки для разных аудиторий пользователей.
Следует отметить, что файл справки или систему веб-справки можно легко интегрировать в ваше приложение или веб-сайт, поэтому вы можете предоставлять контекстно-зависимую справку, экспортируя список тем в файл заголовка, совместимый с вашей IDE, такой как C #, VB .NET, Delphi, C++, MS Office VBA.
Также, из необычных дополнительных функций HelpSmith является — «Подсветка синтаксиса» — для создания документации API, файлов справки с примерами кода и любых других видов документации, содержащей программный код, написанный на различных языках программирования.
Плюсы:
+ большой перечень возможностей, позволяющих создать качественное и полное руководство пользователя
+ простота и удобства использования.
Минусы:
— Отсутствие простого механизма многопользовательской работы
— Интерфейс и материалы на английском языке
— Отсутствие Mac и веб-версии
5. MarkdownPad
Операционная система – Windows
Цена – бесплатно. Есть платная версия – $15.
MarkdownPad — известный редактор Markdown для Windows. Он прост и так же удобен в использовании, как Microsoft Word, и поставляется с редактором WYSIWYG, поэтому вам даже не нужно знать Markdown.
MarkdownPad отлично подходит, если вам нужно быстро выложить документацию на сайт, создать веб-сайт и все, что связано с HTML. Вы можете в любой момент посмотреть, как будет выглядеть ваша документация, используя предварительный просмотр.
Все настраивается под себя. Вы можете воспользоваться широкими возможностями настройки, такими как макеты, шрифты и размеры. Вы также можете включить свои собственные таблицы стилей CSS. Он поставляется со встроенным в платформу редактором CSS, поэтому вы можете стилизовать текст по своему вкусу.
Плюсы:
+ Очень удобная и в целом простая программа, что даже не получилось написать про неё больше 3 абзацев
+ Стоимость.
Минусы:
— Малый функционал, по сравнению с большинством подобных инструментов.
Заключение
Пользовательская документация – незаменимый инструмент, позволяющий укреплять лояльность пользователей, прикрывать техподдержку, повышать SEO-факторы продукта. Кроме того, наличие технической документации — один из основных критериев допуска в Реестр отечественного ПО Минцифра России.
Создание действительно качественной документации, которая будет приносить пользу – тяжелая задача, на которую придется потратить немало времени и сил. Специально для упрощения этой задачи и были созданы программы для написания документации, а мы постарались предоставить вам список лучших таких инструментов.
Аннотация. В данной статье рассмотрены особенности разработки руководства пользователя для программного обеспечения «Зарплата и кадры». Автором изучены назначение и структура руководства пользователя.
В современном мире программное обеспечение отличается высоким уровнем функциональности и гибкости. Таким образом, чтобы успешно эксплуатировать программное обеспечение, пользователь должен иметь исчерпывающее описание возможностей используемого программного продукта. Функцию необходимого источника знаний, о программном обеспечении, выполняет документ «Руководство пользователя».
После разработки программы разработчик обязан написать документ «Руководство пользователя», который относится к пакету эксплуатационной документации. Часто у разработчиков возникают проблемы с его разработкой. В статье предлагается структура «Руководства пользователя» и описывается детально содержание данного документа.
Основная цель документа «Руководство пользователя» заключается в обеспечении пользователя необходимой информацией для самостоятельной работы с программой или автоматизированной системой. Документ должен отвечать на следующие вопросы: назначение программы, её возможности; что необходимо для обеспечения ее корректного функционирования и, что делать в случае отказа системы [1].
В статье приводится пример структуры «Руководства пользователя» для программного обеспечения «Зарплата и кадры», используемого в Инновационном Евразийском университете (ИнЕУ).
«Руководство пользователя» должно состоять из двух частей:
- руководство пользователя;
- руководство оператора.
Структура руководства пользователя содержит:
- Введение. Данный раздел должен предоставлять пользователю общую информацию о приложении. Введение должно состоять из следующих подразделов:
- Область применения. В подразделе описывается список задач, для которых предназначается программное обеспечение. Программное обеспечение «Зарплата и кадры» предназначено для учета кадров и расчета заработной платы сотрудникам ИнЕУ.
- Описание возможностей. В подразделе описываются основные возможности, которые предоставляет программное обеспечение. Программное обеспечение «Зарплата и кадры» включает в себя такие функции как прием сотрудника, оформление отпуска сотрудника, начисление заработной платы, удержание налогов и многие другие.
- Уровень подготовки пользователя. Подраздел содержит в себе информацию о знаниях и навыках, которыми должен обладать пользователь, чтобы работать с приложением, используя весь его потенциал. Например, сотрудники, работающие с программным обеспечением «Зарплата и кадры», обязаны обладать знаниями необходимыми для бухгалтерского расчета заработной платы, а также иметь навыки работы на компьютере.
- Перечень эксплуатационной документации. В подразделе перечислена документация, которая позволит пользователю избежать определенного рода ошибок. Пользователям программного обеспечения «Зарплата и кадры» предоставлен список литературы, которая позволит им повысить свои навыки работы на компьютере.
- Назначение и условия применения. Раздел подразделяет основную задачу приложения на подзадачи и описывает каждую из них.
- Виды деятельности и функции. В этом подразделе описываются функции, для автоматизации которых предназначена программа.
- Условия применения. В подразделе описываются условия, при которых обеспечивается полноценное применение программного обеспечения. В качестве таких условий могут выступать требования к аппаратному обеспечению, на котором будет использоваться программное обеспечение, и квалификация сотрудников, которые будут работать с описываемым программным продуктом. Например, для корректной работы программного обеспечения «Зарплата и кадры» рекомендовано не выполнять на компьютере параллельно других ресурсоемких задач [2].
- Подготовка к работе. Данный раздел должен содержать пошаговую инструкцию для запуска приложения. К этапу подготовки системы к работе можно отнести установку дополнительных приложений, идентификацию, аутентификацию. Программное обеспечение «Зарплата и кадры» является многопользовательским, следовательно, каждый пользователь несет ответственность за обрабатываемые и хранимые данные.
- Состав и содержание дистрибутивного носителя данных. В подразделе описываются все файлы, входящие в дистрибутив программного обеспечения.
- Порядок загрузки данных и программ. Подраздел описывает корректный порядок запуска программного обеспечения, чтобы предотвратить нестабильность в работе приложения, и, как следствие, избежать потери данных.
- Проверка работоспособности. В подразделе описываются показатели, по которым можно определить, что программное обеспечение работает нестабильно. Процесс проверки программного обеспечения «Зарплата и кадры» требует определенного промежутка времени, так как необходимо протестировать большое количество различных функций при различных условиях.
- Описание операций. Это основной раздел, который содержит пошаговую инструкцию для выполнения того или иного действия пользователем. Если работа автоматизированной системы затрагивает целый бизнес-процесс, то в руководстве пользователя перед описанием операций целесообразно предоставить информацию о данном процессе, его назначении и участниках. Подобное решение позволяет человеку четко представить свою роль в данном процессе и те функции, которые реализованы для него в системе. Далее в руководстве пользователя следует представить описание функций, разбитых на отдельные операции. Необходимо выделить подразделы, описывающие функции данного процесса, и действия, которые необходимо совершить для их выполнения.
- Описание всех выполняемых функций, задач, комплексов задач, процедур. В подразделе производится подробное описание каждого процесса, выполняемого программным обеспечением.
- Описание операций технологического процесса обработки данных, необходимых для выполнения функций, задач, процедур. В подразделе описываются технологические процессы, которые состоят из нескольких процедур.
- Аварийные ситуации. В разделе описываются действия в случае длительных отказов технических средств, обнаружении несанкционированного вмешательства в данные, действия по восстановлению программ или данных.
Руководство оператора отличается от руководства пользователя. В этом руководстве все процессы, выполняемые программным обеспечением, рассматриваются с технической точки зрения.
Структура руководства оператора содержит:
- Установка а сервер. Программное обеспечение «Зарплата и кадры» является многопользовательским, следовательно, оно имеет централизованную базу данных. В разделе описывается процесс установки программного обеспечения на сервер. Пошаговая инструкция дает точные указания, каким образом необходимо выполнить установку, в зависимости от технического состояния сервера. Настройка сервера для обеспечения работоспособности программного приложения «Зарплата и кадры» является основным моментом администрирования, так как сервер хранит большие объемы различной информации.
- Установка локальная. В разделе описывается процесс настройки компьютеров, использующих программное приложение, также даются рекомендации по оптимизации настройки рабочих станций, чтобы улучшить процесс взаимодействия сервера и компьютеров пользователей.
- Администрирование пользователей. В разделе подробно описывается процесс администрирования учетных записей пользователей программного обеспечения «Зарплата и кадры». Подробная инструкция описывает все ситуации, которые могут возникнуть при управлении пользователями. Например, с помощью данной подсистемы можно централизованно завершать все активные соединения с информационной базой и устанавливать блокировку новых соединений на определенный период времени. Такая возможность полезна при выполнении различных административных действий с информационной базой.
- Информационная база. В разделе рассматриваются вопросы администрирования, сохранения, переноса базы данных. Описаны рекомендации по настройке базы данных. Например, рассматривается ситуация резервного копирования. Программное обеспечение «Зарплата и кадры» позволяет создавать резервные копии информационной базы. Резервное копирование может выполняться как в автоматическом режиме, так и в ручном. Для автоматического режима предварительно необходимо выполнить настройки. В любой момент можно восстановить данные информационной базы из созданной ранее резервной копии.
- Технические неполадки. Этот раздел содержит информацию о возможных технических проблемах, которые могут возникнуть в процессе эксплуатации программного обеспечения. Рассматриваются проблемы, возникающие в результате некорректной работы оборудования, а также ситуации, возникающие в результате некорректного использования функций программного обеспечения «Зарплата и кадры».
- Программный код. В разделе подробно описывается структура программного кода. Если в процессе использования программного обеспечения возникают ошибки или потребуется доработка, то для этого необходимо знать программный код. Указываются особенности программного кода, создающие затруднения в процессе доработки. Раздел является очень важным, так как может потребоваться добавить, удалить или изменить определенные функции программного обеспечения «Зарплата и кадры».
Документ «Руководство пользователя» является неотъемлемой частью программного обеспечения, следовательно и чем лучше, он будет составлен, тем меньше проблем будет возникать в процессе эксплуатации разработанной программы.
СПИСОК ЛИТЕРАТУРЫ
- Радченко М.Г. 1С: Предприятие 0. Практическое пособие разработчика. Примеры и типовые приемы . – 1С – Паблишинг, 2004. – 656 с.
- Тимофеев Г., Шумейко Д. Конфигурирование и администрирование 1С: Предприятия. – Ростов н/Д: Феникс, 2003. – 320 с.
Эх… вот она «жизнь»!
На личном примере убедилась, что писать руководства пользователя – не такая уж и простая задача… Особенно если не знаешь программный продукт по которому его нужно составить!
Так как же написать руководство пользователя?
Не так давно, я устроилась на новую работу в компанию, занимающуюся разработкой и внедрением программного продукта… все бы хорошо.. но я споткнулась уже на первом своем задании..
Передо мной поставили задачу написать руководство пользователя по программе, которую я даже никогда до этого не видела (кажется, что-то из бухгалтерского учета, в чем я не так уж и шибко разбираюсь). Никаких старых версий руководств пользователя, никаких примеров.. только я и программа.. В процессе работы я столкнулась с некоторыми подводными камнями, которые и попытаюсь описать в данной статье.
Казалось бы, что может быть сложного! Есть программа.. немного мозгового штурма – и все сделано!!! Конечно, самый идеальный вариант, это если руководство пользователя пишет сам разработчик «чуда-природы» или, по меньшей мере, пользователь, давно работающий в описываемой системе.
А что делать, если это не так?! Первым делом бежать к разработчику и хорошенько «сесть ему на шею», чтобы он «разжевал» свое «детище» от начала до самого предельного уровня!!! В таких случаях лучше представить себя «Почемучкой» и докапываться до самых мелочей. К сожалению, нервы программиста такого порыва не оценят! Но тут выбор прост, либо хорошее руководство, либо обмен любезностями и только…
В любом случае, нужно посмотреть на программу «со стороны» глазами первопроходца! Предварительно выделив функциональные модули, и модуль, который представляет наибольший интерес для конечного пользователя (его лучше всего описать мах подробно!), необходимо определить степень детализации проектируемого руководства. Обычно этот вопрос обсуждается с руководством организации –разработчика, но можно и на свое усмотрение.
По своему опыту, могу сказать, что при написании руководства пользователя лучше потратить немного времени на проектирование общей структуры пояснительной записки, чем потом писать для каждого функционального модуля отдельные руководства. Дело в том, что чем стандартизованней (структурированней) руководство, тем проще ориентироваться пользователю и описывать легче! При продуманной структуре описания вероятность «забыть» отобразить какой-то ключевой момент значительно снижается!
Еще есть такой хороший момент – это ГОСТы! Для описания руководств пользователя существует такой замечательный ГОСТ, как ГОСТ 19.505-79 (описание см. в разделе сайта).
Как написать руководство пользователя:
Основным ориентиром для написания руководства можно выделить следующее описание:
- назначение программы (зачем она вообще нужна, на кого ориентирована и т.п.);
- сообщения оператору (описание возможных ошибок, сообщений пользователей и т.п.).
- условия выполнения программы (min и max аппаратные и программные требования);
- выполнение программы (описание функционала программы, последовательность действий оператора и т.п.);
В качестве примера, могу предложить свою методику описания выполнения программы. В начале нужно проанализировать весь описываемый программный продукт и определить разбивку по отдельным модулям (разделам и т.п.).
Параллельно нужно определить функции меню, повторяющиеся наименования полей и другой функционал, которые стандартны по всему модулю, разделу программного продукта и т.д.
Далее формируем следующую структуру:
1.Краткое описание
2.Модуль А
- Подмодуль А.1
- Подмодуль А.2
3.Модуль В
- Подмодуль В.1
- Подмодуль В.2
В раздел «Краткое описание» помещается краткое описание модулей А и В, а также описываются те повторяющиеся пункты меню, наименования полей и т.п., характерные для обоих модулей. Далее в описании самого модуля/подмодуля описывается краткий алгоритм работы с модулем/подмодулем (загрузка, просмотр, добавление, редактирование, удаление, формирование отчетов и т.д), после чего осуществляется более подробное описание всего функционала и всех имеющихся полей.. Иными словами все в деталях!
Описывается специфика полей, с какими операциями связано их заполнение, какие значения присваиваются автоматически, в каких случаях вообще отображаются поля, типы полей, все кнопочки, галочки.. В общем, тут можно описывать до бесконечности!!!
Если модуль содержит в себе подмодули, то лучше описать все в строгой последовательности.. Т.е. в начале описать сам модуль (от начала до конца), при этом сделать ссылку на соответствующий подмодуль, а ниже –подробно описать весь подмодуль! Получается достаточно красивая картинка! Пользователю не приходится перескакивать от одной части документа в другую и обратно..
И так описывается весь программный продукт. В концовке можно написать список используемых сокращений, употребленных при описании руководства пользователя.
Бесспорно, что данная методика носит обобщенный характер! Но из своего опыта могу сказать точно, очень удобна! Удобно пользователю, удобно разработчику руководства пользователя! Все довольны.. 😉
Но как говорится, на вкус и цвет товарища нет! Остается пожелать успешных разработок!
————
Автор: Рожкова Елена
См. похожие статьи по теме:
Как определить роли пользователей в системе
Разработка технического задания на систему
ГОСТ 19.505-79. Руководство оператора
GD Star Rating
loading…
Как написать руководство пользователя, 4.3 out of 5 based on 6 ratings