Использование тестирования для контроля
знаний учащихся по информатике позволяет
выявить уровень и качество знаний учащихся по
определенному материалу, объективно оценить их
независимо от учителя.
В данной статье рассматриваются типы и виды
тестовых заданий; их особенности, преимущества и
недостатки; требования, предъявляемые при
составлении к тестовым заданиям; методика
составления тестовых заданий по информатике и их
применение на практике.
В самом общем виде тестовые задания должны:
- соответствовать содержанию учебного материала;
- быть составлены с учетом соответствующих
правил; - быть апробированы на практике;
- быть понятными испытуемому [2, с. 77].
С помощью тестовых заданий можно измерять
уровень и качество знаний учащихся по
информатике. Тогда тестовые задания должны
отвечать следующим требованиям:
- надежность – показывать те же результаты
неоднократно, в схожих условиях; - валидность – обнаруживать и измерять уровень
усвоения именно тех знаний, которые хочет
измерить разработчик теста; - объективность [3, с. 358].
С точки зрения разработчика минимальные
требования к составу тестового задания состоят в
наличии:
1. Инструкции (должна содержать указания
на то, что испытуемый должен сделать, каким
образом выполнить задание, где и как делать
пометки и записи. Инструкция должна обеспечивать
доступность задания и понимание способов его
выполнения для любых испытуемых).
2. Текста задания или вопроса (представляет
собой содержательное наполнение задания.
Структура и состав вопроса определяются
содержанием учебного материала).
3. Правильного ответа.
Перечисленные три составные части тестового
задания являются минимально необходимыми для
составления тестов.
Кроме того, составителям тестовых заданий
целесообразно указывать еще ряд необходимых
сведений, таких как:
- возраст (класс), на который рассчитано это
задание; - тему (предмет или предметную область);
- предполагаемое составителем время выполнения
задания; - сроки предъявления;
- уровень, который соответствует данному заданию,
или умения, которые оно выясняет; - соответствие стандарту или программному
материалу; - данные об авторе.
Виды и типы тестовых заданий. Их
особенности, преимущества и недостатки
Рассмотрим, типологию тестовых заданий, и
выделим требования к ним. Существуют два типа
заданий, которые объединяют шесть видов [2, с.
82–101].
Схема 1. Типы и виды тестовых заданий
К заданиям открытого типа относятся два вида –
задания дополнения и задания свободного
изложения. Их отличительной особенностью
является то, что для их выполнения ученику
необходимо записать одно или несколько слов
(цифр, букв, словосочетаний, предложений).
Задания закрытого типа (альтернативных
ответов, множественного выбора, восстановления
соответствия и восстановления
последовательности) предусматривают различные
варианты ответа на поставленный вопрос: из ряда
предлагаемых выбираются один или несколько
правильных ответов, выбираются правильные (или
неправильные) элементы списка и др. Эти задания
предполагают наличие ряда предварительно
разработанных вариантов ответа на заданный
вопрос.
Задания закрытого типа
1. Задания альтернативных ответов.
К каждой задаче альтернативных ответов дается
только два варианта ответов. Испытуемый должен
выбрать один из них – “да – нет”, “правильно –
неправильно” и др.
Форма задания
Текст задания (вопрос) |
Ответ |
|
Утверждение 1 | да | нет |
Утверждение 2 | да | нет |
Утверждение 3 | да | нет |
… | … | … |
Инструкция для задания альтернативных ответов:
Вам необходимо выбрать один вариант ответа,
который Вы считаете правильным.
Задания альтернативных ответов в большей
степени подходят для выявления уровня овладения
сложными определениями, знания достаточно
сложных графиков, диаграмм, схем и др.
Особенностью заданий альтернативных ответов
является то, что вопрос должен быть
сформулирован в форме утверждения, поскольку он
предполагает согласие или несогласие, которое
можно отнести к утверждению.
Пример.
Инструкция: Вам необходимо выбрать один
вариант ответа, который Вы считаете правильным.
Вопрос: Программа Paint не является программой
для работы с электронными таблицами.
Варианты ответов:
- да
- нет
Ответ: да.
Эти альтернативные задания в наибольшей
степени соответствуют задаче выявления того, в
какой степени испытуемый понимает данные. Они
могут содержать проверку умений работать с
графиками, навыками приближенного вычисления.
Любая другая форма представления заданий будет
гораздо более громоздкой и менее удобной.
2. Задания множественного выбора.
Это основной вид заданий, применяемый в тестах
достижений. Задачи с множественным выбором
предполагают наличие вариативности в выборе.
Испытуемый должен выбрать один из предложенных
вариантов, среди которых чаще всего только один
правильный.
Форма предоставления заданий множественного
выбора:
Вопрос (утверждение):
A. Вариант ответа 1
B. Вариант ответа 2
C. Вариант ответа 3
Инструкция для заданий множественного выбора: Выберите
букву (ы), соответствующую (не) варианту (ом)
правильного (ых) ответа (ов).
Приведем несколько примеров:
Пример 1.
Инструкция: Выберите букву, соответствующую
варианту правильного ответа.
Вопрос: Для какой операции с таблицами служит
окно, фрагмент которого представлен <Рисунок
1>:
Рис. 1.
Варианты ответов:
A. Суммирование по строкам.
B. Суммирование по столбцам.
C. Фильтрация таблицы.
D. Консолидация данных.
Ответ: D.
Пример 2.
Инструкция: выберите буквы, соответствующие
вариантам правильных ответов. Вопрос: Выберите
из приведенного списка типы объектов, с которыми
работает Access.
Варианты ответов:
A. Таблицы.
B. Сведения.
C. Запросы.
D. Формы.
E. Стили.
F. Отчеты.
G. Макросы.
Н. Модули.
Ответ: А, С, D, F, G, H.
3. Задания на восстановление соответствия.Новая таблица
К заданиям данного типа относятся задания на
восстановление соответствия между элементами
двух списков, порядка ряда.
Форма представления заданий на восстановление
соответствия:
Инструкция: Соотнесите написанное в столбцах
1 и 2.
Вопрос:
Варианты ответа:
Столбец 1 Столбец 2 А. 1. Б. 2. C. 3. D. 4. Е. 5.
Пример 1.
Инструкция: Соотнесите написанное в столбцах
1 и 2.
Вопрос: При создании таблицы СУБД можно
использовать 5 возможностей. Выберите из
приведенных определений те, которые им
соответствуют <Рисунок 2>:
Рисунок2
Варианты ответа.
Столбец 1 Столбец 2 А. Режим таблицы. 1. Ввод таблицы из другой базы данных. В. Конструктор. 2. В этом режиме составляется список
имен полей и задаются свойства каждого поля.С. Мастер таблиц. 3. Создание таблицы вводом имен полей в
заголовок.D. Импорт таблиц. 4. Создание таблицы с использованием
связи с таблицей из другой базы данных.Е. Связь с таблицами. 5. Создание таблицы с помощью мастера,
предлагающего выбрать поля из списка.
Ответ: А. 3. В. 2. С. 5. D. 1. Е. 4.
Главными преимуществами заданий этого вида
являются: возможностью быстрой оценки знаний,
умений и навыков в конкретной области знаний, и
экономичность размещения задач в тесте.
4. Задания на восстановление
последовательности
Задания на восстановление последовательности
можно рассматривать как вариант задания на
восстановления соответствия, когда одним из
рядов является время, расстояние, или иной
континуальный конструкт, который
подразумевается в виде ряда.
Задания на восстановление последовательности
– это очень качественная форма тестовых заданий,
обладающая значительными преимуществами:
краткостью, простотой проверки.
Задание.
Инструкция: Расположите в правильной
последовательности.
Вопрос.
Варианты ответа.
1. А.
2. B.
3. С.
Приведем несколько примеров:
Пример:
Инструкция: Расположите в правильной
последовательности.
Вопрос: Установите последовательность этапов
проектирования экспертных систем.
Варианты ответов:
Столбец 1 Столбец 2
1 А. Выбор подходящей проблемы. 2 В. Доработка прототипа до промышленной
экспертной системы.3 С. Стыковка экспертной системы. 4 D. Разработка прототипа экспертной
системы.5 Е. Оценка экспертной системы. 6 F. Поддержка экспертной системы.
Ответ: 1. А. 2. D. 3. В. 4. Е. 5. С. 6. F.
Преимущества заданий закрытого типа
- Задания могут быть надежны, поскольку
отсутствуют факторы, связанные с субъективными
оценками, которые снижают надежность. - Оценивание заданий полностью объективно: между
оценками различных проверяющих не может быть
различий. - Не учитывается умение испытуемых хорошо
формулировать ответы. - Задания этого типа легко обрабатываются,
тестирование быстро проводится. - Простой алгоритм заполнения снижает количество
случайных ошибок и описок. - Эти задания позволяют охватить большие области
знания, что для тестов достижений особенно важно. - Возможна машинная обработка ответов.
- Низкая вероятность угадывания правильных
ответов. - Возможно получение точной оценки
содержательности теста, что особенно важно для
определения соответствия теста целям
исследования [2, с. 98].
Задания открытого типа
К ним относятся задания двух видов:
1) дополнения (задачи с ограничением на
ответы). В этих заданиях испытуемые также
самостоятельно давать ответы на вопросы, однако
их возможности ограничены.
Ограничения обеспечивают объективность
оценивания результата выполнения задания, а
формулировка ответа должна дать возможность
однозначного оценивания.
Инструкция для заданий дополнения: вместо
многоточия впишите только одно слово (символ,
знак и т.д.).
Пример задания дополнения.
Инструкция: Вместо многоточия впишите только
одно слово.
Вопрос: Фирма, предоставляющая сетевые услуги
– это …
Ответ: провайдер.
2) Свободного изложения или свободного
конструирования. Они предполагают свободные
ответы испытуемых по сути задания. На ответы не
накладываются ограничения. Однако формулировки
заданий должны обеспечивать наличие только
одного правильного ответа.
Инструкция для заданий свободного изложения:
закончите предложение (фразу), впишите вместо
многоточия правильный ответ (словосочетание,
фразу, предложение или несколько предложений).
Пример задания свободного изложения.
Инструкция: Закончите предложение.
Вопрос: Специальная программа, реализующая
правила передачи информации между компьютерами
– это … …
Ответ: сетевой протокол.
Трудность в применении этого вида задач
заключается в сложности с формализацией ответов,
необходимость подготовки оценочных схем
затрудняет стандартизацию, громоздкость
процедуры и большие затраты времени на
проведение.
Основная трудность при составлении заданий
открытого типа – соблюдения основного
требования к тестовым заданиям (наличия
однозначного правильного ответа).
Положительными сторонами хорошо составленных
заданий дополнения и свободного изложения
являются:
1) невозможность угадать ответ;
2) краткость и однозначность ответов;
3) необходимость воспроизведения ответа по
памяти;
4) отсутствие необходимости искать несколько
вариантов ответа;
5) простота формулировки вопроса;
6) простота проверки [2, с. 101].
Список используемой литературы
1. Лефрансуа Г. Прикладная педагогическая
психология. – СПб.: ПРАЙМ ЕВРОЗНАК, 2003. – 416 с.
2. Майоров А.Н. Теория и практика создания
тестов для системы образования. – М.:
“Интеллект-центр”, 2001. – 296 с.
3. Пидкасистый П.И. Педагогика. Учебное
пособие для педагогических вузов и
педагогических колледжей. – М.: Педагогическое
общество России, 1998. – 640 с.
4. Сластенин В.А. и др. Педагогика: Учеб.
Пособие для студ. высш. пед. учеб. заведений / В.А.
Сластенин, И.Ф. Исаев, Е.Н. Шиянов. – М.:
Издательский центр “Академия”, 2003. – 576 с.
С точки зрения
разработчика минимальные требования
к составу тестового задания состоят в
наличии трех частей:
1. Инструкции.
2. Текста задания
(вопроса).
3. Правильного
ответа.
Инструкция должна
содержать указания на то, что испытуемый
должен сделать, каким образом выполнять
задание. Это может быть фраза «Выбрать
правильный ответ», «наиболее правильный
ответ», «все правильные ответы», «хотя
бы один правильный ответ» и др. Инструкция
должна быть составлена так, чтобы задание
и способ его выполнения были абсолютно
ясны любому из испытуемых и не приводили
к ошибкам.
Испытуемому важно
понять, что от него требуется, как он
должен выполнять задание. Мало понять
то, что необходимо установить правильную
последовательность, то есть выполнить
интеллектуальную операцию, но и то, как
собственно ее устанавливать. Кроме
этого, для многих заданий важно и то, в
каком порядке эту правильную
последовательность восстанавливать:
от раннего (большего) к более позднему
(меньшему) или наоборот. Например, задание
на установление правильной
последовательности, в которой в качестве
элементов для упорядочивания предложены
фамилии авторов физических законов
становится непонятным, если не указать
в каком именно порядке следует их
располагать: в алфавитном, в хронологическом,
по продолжительности жизни, по тому,
кто сколько законов открыл, по географии
проживания (с востока на запад) и др.
Для разработчиков
тестовых заданий подготовка инструкции
для испытуемых в каждом задании является
необходимой, поскольку это позволяет
взглянуть на задание с точки зрения
испытуемого.
Текст задания или
вопроса представляет собой содержательное
наполнение задания.
У некоторых авторов
можно встретить выделенные части текста
задания. Например:
Стимулирующий
материал:
материал, о котором говорится в вопросе,
представлен обычно в виде текста,
рисунка, таблицы или другого представления
данных.
Вопрос:
существенная часть вопроса, например:
«До каких пределов падает значение X?»
или «Какие достоинства имеют открытые
вопросы?».
Ограничения
ответа:
вопрос должен быть высокого качества,
чтобы предотвратить нежелательные
интерпретации испытуемых, используя
ограничения, такие как: «По мнению
автора…» или «Вычислите до 2-х десятичных
знаков».
Правильный ответ
(эталон) или
оценочная схема – обязательный атрибут
любого тестового задания – без него
задание теряет смысл, поскольку не может
быть точно проанализировано и оценено.
Перечисленные
три составных части тестового задания
являются минимально необходимыми для
составления тестов. Кроме этого,
составителям тестовых заданий
целесообразно указывать еще ряд
необходимых сведений.
Таблица 1.5
Сведения разработчиков о заданиях и их целевое назначение
Сведения |
Дальнейшее |
возраст (курс, на |
для |
сведения |
дальнейшее |
тему |
для проверки технологической |
предполагаемое выполнения |
для компоновки предназначенного |
сроки |
для |
предполагаемую |
для |
уровень, |
для |
соответствие |
для |
данные |
для |
возможные варианты поддержки |
для |
Основное требование
к тестовым заданиям – тестовое задание
должно иметь однозначный правильный
ответ. Понятие однозначности ответа
трактуется не столько как требование
единственности ответа, но обязательное
наличие предполагаемого образца.
Ясная схема оценки
должна обеспечить пользователя тестом
аппаратом оценивания именно в рамках
заложенной в тест оценки разработчика.
Многие вопросы толкования могут быть
сняты при разработке ясной и недвусмысленной
схемы оценивания, которая содержит
наиболее возможные варианты ответов,
которые можно принять к рассмотрению
и оценить как зачетные. Схема оценивания
должна полностью соответствовать
конкретному вопросу. Все формулировки
ожидаемых ответов должны быть предельно
ясными и недвусмысленными.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
МЕТОДИЧЕСКИЕ
РЕКОМЕНДАЦИИ
по
составлению и оформлению тестовых заданий
ВВЕДЕНИЕ
Один из
элементов системы оценки качества – тестирование учебных достижений обучающихся.
Система тестирования – универсальный инструмент определения уровня обученности обучающихся
на всех этапах образовательного процесса, в том числе для оценки уровня
остаточных знаний.
Тест обладает
способностью сравнивать индивидуальный уровень знания каждого обучающегося с
некими эталонами, уровень знания отражается в тестовом балле испытуемого.
Индивидуальные результаты тестирования можно сравнить с результатами других обучающихся
этой же группы и проранжировать их, можно сравнить результаты тестирования
нескольких групп и т.д.
С помощью теста можно
оценить структуру знаний, то есть установить наличие последовательности
в усвоенных обучающимися знаниях, отсутствие пробелов.
Методические
рекомендации по составлению и оформлению тестовых заданий имеют целью
определить единые требования к составлению тестов по учебным дисциплинам/МДК,
предназначенных для проверки уровня и структуры знаний обучающихся техникума.
Объективность
результатов тестирования, в первую очередь, зависит от качества тестовых материалов,
поэтому при разработке необходимо учитывать комплекс требований, диктуемых
положениями теории и практики тестирования.
Методические
рекомендации помогут унифицировать тестовые материалы. Тестирование —
лишь один из способов оценки качества подготовки обучающихся. Тестирование
не заменяет, а дополняет другие формы диагностики, контроля и оценки уровня
обученности.
Методические
рекомендации призваны способствовать:
— формированию культуры тестирования в
системе оценки качества обученности обучающихся;
— повышению объективности процессов и
результатов оценки учебных достижений обучающихся;
— созданию необходимых предпосылок и
условий для совершенствования содержания и структуры образовательного процесса;
—
повышению уровня квалификации педагогов, непосредственно разрабатывающих и
применяющих тестовые материалы.
- СЛОВАРЬ ТЕРМИНОВ
Тестирование —
один из наиболее эффективных методов выявления и оценки уровня учебных
достижений обучающихся, осуществляемый посредством стандартизированных
материалов — тестовых заданий; технологический процесс, реализуемый в форме
алгоритмически упорядоченного взаимодействия студента с системой тестовых
заданий и завершающийся оцениванием результатов.
Тестовое задание (ТЗ)
— варьирующаяся по элементам содержания и по трудности единица контрольного
материала, сформулированная в утвердительной форме предложения с неизвестным.
Подстановка правильного ответа вместо неизвестного компонента превращает
задание в истинное высказывание, подстановка неправильного ответа приводит к
образованию ложного высказывания, что свидетельствует о незнании студентом
данного учебного материала.
Тест —
система заданий возрастающей трудности специфической формы, позволяющая
качественно и эффективно определить уровень и оценить структуру
подготовленности тестируемого.
Контролирующий тест
— тест, выступающий в качестве метода или способа измерения уровня и структуры
знаний обучающихся.
Банк тестовых заданий
– логически упорядоченный набор тестовых заданий, позволяющих генерировать
множество тестов.
Спецификация теста
— система характеристик теста, отражающая его содержание и структуру.
Надежность теста –
характеристика теста, свидетельствующая о постоянстве эмпирических измерений,
то есть многократном повторении.
Валидность теста —
действительная способность теста измерять ту характеристику, для диагностики
которой он заявлен.
Дистрактор —
близкий искомому по своему смыслу вариант ответа, но не являющийся таковым.
Эталон – это
правильный и полный ответ или метод выполнения заданной деятельности.
II. ФОРМЫ
ТЕСТОВЫХ ЗАДАНИЙ
По
классификации тестов, предложенной Аванесовым В.С., можно выделить тестовые
задания четырех основных форм:
·
задания
закрытой формы, в которых испытуемый выбирает один или несколько
вариантов ответов из списка предложенных;
·
задания
открытой формы, требующие от испытуемого самостоятельного ответа (в
текст задания вписывается слово, вставляется формула и т.д.);
·
задания
на установление соответствия, выполнение которых связано с выявлением
соответствия между элементами двух множеств;
·
задания
на установление правильной последовательности, в которых требуется
указать правильный порядок действий или процессов.
Задания закрытой
формы:
— задания с
выбором одного правильного ответа (предлагается
несколько ответных альтернатив, но только один ответ – правильный);
— задания с
выбором наиболее правильного ответа (предлагается несколько
ответных альтернатив, в числе которых могут быть и неправильные, и правильные,
но в разной степени. От испытуемого требуется выбрать наиболее правильный
ответ);
— задания с
выбором всех правильных ответов (предлагается несколько ответных
альтернатив, в числе которых может быть несколько правильных. Испытуемый должен
выбрать все правильные ответы).
Задания закрытой формы
сопровождаются инструкцией: «Запишите номер/-а (цифру/-ы, букву/-ы)
правильного/-ых ответа/-ов».
Задания
открытой формы
В
заданиях открытой формы готовые ответы не даются, их должен получить или
придумать сам испытуемый. Задания открытой формы бывают двух типов:
— задания на
дополнение;
— задания со
свободно конструируемым ответом.
Для
задания открытой формы рекомендуется использовать инструкцию, состоящую из
слов: «Дополните фразу», «Дайте определение..» и т.п..
Задания
на установление соответствия
Они могут быть
двух типов:
— Соответствия
взаимно-однозначные: любому элементу из левого столбца соответствует только
один элемент из правого столбца и наоборот;
— Соответствия
не взаимно-однозначные: различным элементам из левого столбца может
соответствовать один и тот же элемент из правого столбца.
К
заданиям предлагается стандартная инструкция, состоящая из двух слов:
«Установите соответствие».
Задания
на установление правильной последовательности
Эта
форма заданий проверяет определенные знания: алгоритмические, процессуальные,
процедурные, технологические.
Стандартная инструкция к заданиям этой формы имеет вид
«Установите правильную последовательность».
Сопоставительный
анализ характеристик тестовых заданий
Характеристики |
Задания закрытой формы |
Задания открытой формы |
Задания на установление соответствия |
Задания на установление |
Проверка знания фактов |
Годны |
Годны |
Годны |
Годны |
Применение знаний по образцу |
Годны |
Годны |
Годны |
Годны |
Применение знаний в нестандартных ситуациях |
Негодны |
Годны |
Негодны |
Годны |
Простота конструирования |
Есть |
Есть |
Нет |
Нет |
Исключение угадывания |
Не исключено |
Исключено |
Не исключено |
Не исключено |
Объективность оценки |
Да |
Нет |
Да |
Да |
Исключение описок |
Нет |
Да |
Нет |
Нет |
Возможность оригинального ответа |
Нет |
Да |
Да/Нет |
Нет |
III. Уровни сложности тестовых заданий
ТЗ должны быть различного уровня сложности
(классификация тестов по В.С. Беспалько).
Первый
уровень
– ознакомительный (узнавание ранее изученных объектов, свойств): тесты
на узнавание, т.е. отождествление объекта и его обозначения (задания на
опознание, различение или классификацию объектов, явлений и понятий,
соотнесение). Вопросы задаются в открытой и закрытой формах по основным дидактическим
единицам дисциплины («да» — «нет», «выбрать один или несколько правильных
ответов», «соотнести объекты и их характеристики, свойства»).
Второй
уровень
— репродуктивный (выполнение деятельности по образцу, инструкции):
тесты-подстановки, в которых намеренно пропущено слово, фраза,
формула или другой какой-либо существенный элемент текста, и конструктивные
тесты, в которых обучающимся в отличие от теста-подстановки не
содержится никакой помощи даже в виде намеков и требуется дать определение
какому-либо понятию, указать случай действия какой-либо закономерности и т.д. В
качестве тестов второго уровня могут использоваться и типовые задачи,
условия которых позволяют «с места» применять известную разрешающую их
процедуру (правило, формулу, алгоритм) и получать необходимый ответ на
поставленный в задаче вопрос.
Третий
уровень
– продуктивный (планирование и самостоятельное выполнение
деятельности, решение проблемных задач): нетиповые задачи на
применение знаний в реальной практической деятельности и тест «Черный
ящик».
Условия нетиповой задачи формулируются близкими к тем,
которые имели место в реальной жизненной обстановке. Решение такой задачи
состоит в сведении ее к типовой путем преобразования известных формул или
нахождения алгоритма решения. Проверяется деятельность в нестандартной ситуации
по аналогии, сходству между изученными и не изучавшимися ранее элементами.
Тест «Черный ящик»
представляет собой проблемную ситуацию, решение которой содержится в известных
обучающимся знаниях и умениях. Опираясь на них, обучающиеся
решают предложенное задание. («Определите то, что находится в чёрном ящике:
Через него пропускают переменный ток. Чем меньше его частота, тем меньше
сопротивление того. Что в чёрном ящике?» Эталон: конденсатор).
Рекомендуемое распределение
заданий в одном тесте по уровням:
заданий
I уровня –
не более 30% (20-25% заданий разных форм),
заданий
II уровня –
60-70%;
заданий
III уровня –
5-10%.
IV.
ТРЕБОВАНИЯ К ТЕСТОВЫМ ЗАДАНИЯМ
Общие требования
1. Соответствие
ФГОС и рабочей программе учебной дисциплины.
2. Содержание
ТЗ должно отражать знания, умения, практический опыт, которые необходимо
проверить.
3. Содержание
каждого ТЗ должно охватывать какую-либо одну смысловую единицу, то есть должно
оценивать что-то одно.
4. Наличие
ТЗ различной формы и уровня сложности.
5. Формулировка
задания должна быть не в форме вопроса, а в форме утверждения. Предложение
должно быть сформулировано грамотно, коротко, четко, ясно, без повторов,
малопонятных слов и символов, без использования отрицательных частиц. Не
рекомендуется начинать ТЗ с предлога, союза, частицы.
6. Наличие
правильного ответа к разработанному заданию.
7. Среднее время,
отводимое на выполнение одной задачи (вопроса) теста обучающимся, должно быть
минимум 1 минута, а максимум – 3-5 минут.
8. Соблюдение
единого стиля оформления заданий, входящих в один тест.
В дополнение к
общим требованиям существует еще ряд других, обусловленных спецификой
выбранной тестовой формы.
Требования к заданиям закрытой формы:
— Основная
часть задания формулируется в форме утверждения, которое обращается в истинное
или ложное высказывание после подстановки одного из вариантов ответа.
— Задание
формулируется предельно кратко, как правило, в форме предложения, состоящего из
7-8 слов. В основную часть задания следует включать как можно больше слов,
оставляя для ответа не более 2-3 наиболее важных, ключевых для данной проблемы
понятий.
— Из текста
задания необходимо исключать все ассоциации, способствующие выбору правильного
ответа с помощью догадки.
— ТЗ
закрытой формы должны содержать не более пяти вариантов ответов на каждый
вопрос (оптимально – 4 варианта).
— Среди
предложенных вариантов ответа может быть как один, так и несколько верных.
— В ответах
не рекомендуется использовать слова «все», «ни одного», «никогда», «всегда» и
т.п., так как в отдельных случаях они способствуют угадыванию правильного
ответа.
Примеры (уровень
сложности — 1):
1. Преобразование
электрических колебаний в звуковые происходит в …
а) микрофоне;
б) динамике;
в) детекторе
радиоприёмника;
г) приёмной
антенне.
2.
В данном списке найдите два региона России, в которых нет
городов-миллионеров:
Требования
к тестовым заданиям открытой формы:
—
Текст
задания должен обладать предельно простой синтаксической конструкцией. В тексте
задания не должно быть повторов и двойного отрицания.
—
Место
пропущенного понятия обозначается точками или нижним подчеркиванием. Точки/подчеркивание
ставятся на месте ключевого элемента, знание которого является наиболее
существенным для контролируемого материала. Если это возможно, то после точек/подчеркивания
указываются единицы измерения. Все точки/подчеркивания
в заданиях для одного теста рекомендуется делать равной длины.
—
Обычно
ответом служит одно слово или словосочетание, состоящее не более чем из двух
слов.
—
При
указании составителем теста правильного ответа должны быть перечислены все
возможные варианты написания слова-ответа.
Примеры (уровень
сложности 2):
1. Конституцией
определено, что забастовка – это временный … отказ работников от выполнения
обязанностей в целях разрешения спора.
Ответ:
добровольный.
2.
Низменность – это вид ______, с ____ высотой до __ метров.
Ответ:
равнины, абсолютной, 2000.
Требования
к тестовым заданиям на установление соответствия
—
Группы
объектов, между которыми устанавливается соответствие, могут быть одинакового
размера, но предпочтительнее, чтобы одна была больше другой (допускается одна
лишняя позиция).
—
Соответствие
между объектами групп должно быть однозначным, одному элементу первого
множества должен соответствовать один элемент второго множества.
— К
заданиям предлагается стандартная инструкция, состоящая из слов: «Установите
соответствие».
Пример
(уровень сложности 1):
Установите
соответствие между видами конфликтов и их характеристикой.
Столкновение |
Внутригрупповой |
Внутреннее |
Внутриличностный |
Столкновение |
Межгрупповой |
Столкновение |
Межличностный |
Требования
к тестовым заданиям на установление правильной последовательности
—
Последовательность
устанавливаемых объектов должна быть однозначной, не рекомендуется составлять
последовательность, требующую повторения одного из объектов.
—
В
основном тексте задания должно быть указание на направление последовательности.
— Стандартная
инструкция к заданиям четвертой формы имеет вид «Установите правильную
последовательность».
Пример
(уровень сложности 2):
Установите
последовательность этапов переговорного процесса:
o Подготовительный
этап
o Взаимное
уточнение позиций участников
o Выдвижение
аргументов и обоснование своих взглядов
o Согласование
позиций и выработка договоренностей
o Анализ
результатов переговоров
Примеры заданий 3 уровня сложности:
1.
Составьте алгоритм трудовых действий продавца по продаже сыра в молочном
отделе.
2.
Группа обучающихся выполняла облицовку стен в столовой керамической плиткой.
После окончания работы оказалось, что ширина швов на облицованной поверхности —
неодинаковая. Раствор был качественный, поверхность была подготовлена
правильно. Отчего это произошло?
V. Структура теста
Основными структурными
компонентами теста являются:
·
Спецификация
теста
·
Инструкция
для тестируемых
·
Основной
текст
·
Эталон ответов и критерии оценки
Спецификация
теста
В
спецификации теста описываются основные характеристики теста. К характеристикам
теста относятся: название дисциплины, по которой составлен тест; название темы,
по которой составлен тест; цель теста; содержание теста, критерии оценки.
Возможные цели тестов: для контролирующих тестов
основной целью является проверка (контроль) усвоенных обучающимися знаний и
навыков по конкретной учебной дисциплине.
Целью текущего контроля является проверка знаний и навыков по
одной или нескольким темам учебной дисциплины, по одному разделу.
Целью итогового контроля является проверка знаний и навыков по
всей учебной дисциплине в целом.
Целью может быть проверка уровня остаточных знаний по дисциплине.
Инструкция
для тестируемых
Инструкция должна содержать указания на то, что и как обучающийся
должен сделать, какое количество времени дается на его выполнение, какой
стратегии должен придерживаться испытуемый (например, если не знаете ответ на
задание, приступайте к выполнению следующего), что надо сделать, чтобы записать
правильный ответ.
Перед группой однотипных заданий можно поместить общую инструкцию.
Очень важно указать, каким образом нужно делать отметки при выполнении заданий:
например, для тестовых заданий открытой формы – вписать ответ в отведенное
место.
Если тест включает различные формы заданий, то при смене форм,
перед каждой частью теста можно дать дополнительную инструкцию по выполнению
данной формы задания.
Эталон ответов и
критерии оценки
Данный
компонент является обязательной составной частью теста, который предназначен
преподавателям, которые должны проверить тест.
VI. Этапы составления тестов
Для облегчения процедуры
составления тестов учебный материал должен быть достаточно формализован, т.е.
каждый раздел, тему учебной дисциплины (МДК) необходимо представить в виде
таких задач и (или) вопросов, которые наиболее полно отображают содержание дисциплины
(МДК). При этом важно выделить главные (проблемные) вопросы, не увлекаясь
второстепенными.
На втором этапе, в зависимости
от цели тестирования (текущий контроль знаний, итоговый контроль знаний, оценка
остаточных знаний и др.) и формы теста, разрабатывается план раскладки задач и
вопросов в тестовые задания. Формализация учебного материала и составление
тестовых заданий — наиболее ответственные и сложные этапы составления тестов.
Рекомендуемое время
тестирования и количество вопросов (из расчёта 1-3 минуты — на выполнение
одного тестового задания):
—
тест для текущего контроля на 12-15 мин может содержать 6-7
тестовых заданий,
—
тесты для промежуточной аттестации на 90 мин должны включать не
менее 30 тестовых заданий,
—
тесты для промежуточной аттестации на 45 мин – не менее 15
тестовых заданий.
После составления тестовых
заданий педагог оформляет эталон ответов (Приложение 2), инструкцию для
тестируемых, определяет критерии оценки.
VII. методика оценивания ответов
Методика
оценивания ответов обучающихся должна быть проста, объективна и удобна для
обработки результатов тестирования.
Пример системы оценивания для разноуровневых заданий:
— ТЗ
1 уровня: правильный ответ – 1 балл; неправильный ответ – 0 баллов.
— ТЗ
2 уровня: правильный ответ – 2 балла; частично правильный ответ – 1 балл;
неправильный ответ – 0 баллов.
— ТЗ
3 уровня: правильный ответ – 3 балла; правильный ответ, но сопровождающие
записи с ошибками, или неправильный ответ, но записи свидетельствуют о
правильности хода размышлений – 2 балла; частичное решение или частичный ответ,
который не доведен до логического завершения – 1 балл; в остальных случаях – 0
баллов.
Суммируя
количество баллов за каждое задание, получаем максимальное количество баллов –
100%. Затем рассчитываем количество баллов на «4» и «3».
Рекомендуемая шкала оценки текста:
«3» — от 50% до 70% правильных ответов
«4» — от 71% до 90%
«5» — от 91% до 100%
ЗАКЛЮЧЕНИЕ
Рассмотрим достоинства и недостатки тестовой
проверки знаний.
Достоинства
От традиционных оценок
контроля знаний обучающихся тесты отличаются объективностью измерения
результатов обучения, поскольку они ориентируются не на субъективное мнение преподавателя,
а на объективные эмпирические критерии; быстротой получения результата, установления
связи с обучающимся и обсуждения результатов. Тест позволяет охватить большее
число обучающихся на уроке, экономя время на контроле. Эта форма контроля дисциплинирует
обучающихся, приучая их постоянно готовиться к систематическому тестовому
контролю, а так же улучшает психологическую атмосферу учебного процесса, преподаватель
перестаёт быть источником отрицательных эмоций при оценивании знаний.
Недостатки
Одним из недостатков тестовой формы
является возможность угадывания в заданиях закрытого типа. Если тестовое
задание содержит всего два варианта ответа, то половину ответов на такое
тестовое задание можно угадать. Так же существует возможность списать ответы на
тесты закрытого типа. Преподаватель не видит хода решения (хода мыслительной
деятельности обучающегося), если результаты своей работы обучающийся
представляет только в виде номера ответа, гарантии наличия знаний у обучающегося
нет. В тестах трудно выявить степень овладения умениями проводить наблюдения,
опыты, определять объекты, не развивается речь обучающегося.
На основании сказанного, можно
сделать вывод о преимуществе тестовой проверки знаний по сравнению с
традиционными формами контроля. Тестовые задания удобно использовать при организации
самоконтроля, при повторении учебного материала, при подготовке к уроку. Тесты
с успехом можно использовать наряду с другими формами контроля. Главное
достоинство тестовой проверки – в ее скорости, а традиционной проверки – в её
основательности.
Подборка по базе: Практическая работа по дисциплине Статистика.docx, Экономическая безопасность Практическая работа.docx, Контрольная работа по математике.docx, Практическая работа.docx, англ яз практическая.docx, Контрольная работа по международному экономическому праву .rtf, Практическая работа №1.docx, Практическая работа 2.docx, крсовая работа лера корепанова.docx, Практическая работа № 2 (Часть 2) САА.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. Для получениядополнительных тестов рекомендуется использовать метод предположения об ошибке.
Задание к работе
Практическая работа №24 —
25
Составление руководства пользователя
ИС
Цель работы:
Ознакомиться с процедурой разработки руководства пользователя на создание программного
продукта (ПП) с применением РД 50-34-698-90 «Автоматизированные системы
требования к содержанию документов»
Основные теоретические
сведения
Формальные
требования к документации программного обеспечения описаны в ЕСПД (Единая
система программной документации), неформально: состав документации к
программному обеспечению состоит из описания его внешнего эффекта и описания
его внутреннего устройства.
Первая часть
документации, так называемая «Инструкция пользователю» или «Руководство
пользователю» предназначена для того, кто собирается использовать программное
обеспечение (для пользователя), не вникая в подробности его внутреннего
устройства.
Вторая часть —
«Руководство программисту» необходима при модификации программного обеспечения
или при необходимости исправить в нем ошибку.
В целом,
документация к программному обеспечению может содержать ниже перечисленные
сведения:
1.Наименование
ПО и описание задачи, которую оно решает.
2.Область
применимости ПО.
3.Режим работы
ПО, сообщения, выдаваемые по ходу его работы, ответы пользователя на них (если
это необходимо).
4.Исходные
данные, необходимые для работы ПО; а также выдаваемые им результаты;.
5.Правила
подготовки исходных данных на внешних носителях (если они применяются) и вид
выдаваемой информации.
6.Описание
структуры данных. Для любой переменной описывается ее назначение, атрибуты
(тип, размер массива и т.д.), структура информации в ней, если она не очевидна.
Описание переменных должно начинаться с тех, которые служат исходными данными и
результатами.
7.Описания
форм, объектов. Опись свойств форм и объектов.
8.Тексты
программ, процедур (в виде распечатки ЭВМ) с комментариями.
9.Тесты.
10.Инструкция
(руководство) пользователю.
Инструкция по
использованию программы (или просто «Инструкция пользователю», или «Руководство
для пользователя») — это выдержка из полной документации, предназначенная для
эксплуатации программы. Она представляет собой независимый документ для
пользователя программы, в котором описывается: что делает программа и как им
пользоваться.
«Инструкция
пользователю» должна содержать всю необходимую для пользователя информацию и
должна быть ему понятна без дополнительных материалов (без обращения к другим
спецификациям). Следовательно, необходимая для этой инструкции информация
переписывается полностью из соответствующих спецификаций.
Первая часть
инструкции является описательной и должна содержать:
-наименование
программы;
-краткое
описание программы;
-перечень
выполняемых программой функций;
-краткую
характеристику метода (или методов) решения поставленной задачи, его достоинство
и недостатки;
-полную
библиографическую ссылку на полное описание метода;
-описание
входных и выходных данных.
-описание
структуры базы данных (если она имеется), всех ее таблиц в словесной
(вербальном) форме.
Вторая часть
документа должна описывать порядок работы с программой. Она должна содержать
описание всех режимов работы программы, а также содержание всех печатей и
диагностических сообщений, которые выдаются по ходу выполнения программы.
Следует
помнить, что пользователь по своей квалификации не является программистом и
поэтому его работа с программой описывается на понятном ему языке и достаточно
подробно, а именно:
-как запустить
программу;
-как продолжить
работу с программой (описывается подробный интерактивный режим работы
пользователя с программой);
-подготовка и
ввод исходных данных в программу;
-как
реагировать на запросы программы;
-как вести
работу в исключительных ситуациях;
-как
реагировать на ошибки;
-как
восстановить работу программы в случае аварийного его завершения;
-как получить
требуемый результат;
-как правильно
закончить работу с программой (запланированный программой выход);
-другие
сведения, необходимые пользователю программы.
Задания для выполнения
1.Во
время выполнения лабораторной работы необходимо составить документ «Руководство
пользователю» к разработанной ранее программе.
2.Работа
должна быть оформлена в виде документа «Руководство пользователя» согласно РД
50-34-698-90 «Автоматизированные системы требования к содержанию документов».
3.
Сдать и защитить работу.
Журавлев Денис
Когда и у кого возникает необходимость создания руководства пользователя по ГОСТ
Многие IT-компании, которые занимаются разработкой и сопровождением программного обеспечения и автоматизированных комплексов, сталкиваются с задачей создания пользовательской документации или руководств для своих продуктов в соответствии с требованиями ГОСТ.
Как правило, необходимость в наличии пользовательского руководства, составленного по ГОСТ, возникает при сотрудничестве с государственными организациями, крупными производствами и компаниями, при заказной разработке программного обеспечения по тендерам и госзаказам или при необходимости добавить программный продукт в «Единый реестр российских программ для электронных вычислительных машин и баз данных (реестр отечественного ПО)».
Какие ГОСТ используются при написании руководства пользователя приложения
Существует две серии (набора) стандартов, которые регламентируют набор создаваемых документов и правила их оформления при разработке автоматизированных систем, комплексов и программного обеспечения:
- ГОСТ 34 — Автоматизированные системы
- ГОСТ 19 — Единая система программной документации (ЕСПД)
С одной стороны, эти два стандарта конкурируют между собой, предлагаю различные варианты комплектности документации на проект. С другой стороны, они фокусируются на разных аспектах, и поэтому хорошо дополняют друг друга.
ГОСТ 34 главным образом определяет комплектность, виды, структуру и содержание создаваемых документов.
ГОСТ 19 в большей степени определяет правила оформления документов.
Поэтому, на практике часто используются сразу оба этих ГОСТа.
Руководство пользователя — основной документ для конечного пользователя
Если говорить именно о документации для конечного пользователя системы, то из перечня описываемых в ГОСТ 34 документов нас интересует «Руководство пользователя». В ГОСТ 19 аналогичный по смыслу документ называется «Руководство оператора», но для программного обеспечения чаще используется именно первый вариант.
Руководство пользователя поставляется с любым изделием, программой, системой. Он должен предоставлять пользователю информацию о свойствах продукта, его функциональности, способах использования и работе с ним.
Сложности написания руководства пользователя по ГОСТ
Для начинающего технического писателя или простого специалиста, которому неожиданно поручили написать руководство пользователя по ГОСТ, эта задача является серьезной проблемой.
Мало того, что необходимо изучить большое число нормативных документов, изобилующих перекрестными ссылками и написанных сложным, излишне канцелярским, почти юридическим языком, так еще необходимо выбрать оттуда требования, относящиеся именно к создаваемому виду документа. Затем, на протяжении всей работы, нужно постоянно контролировать соблюдение этих требований в рабочем документе, постоянно сверяясь со стандартами.
Обычно проблема усугубляется еще и нехваткой времени, так как писать пользовательскую документацию, к сожалению, часто принято в самом конце проекта, перед самым дедлайном — датой сдачи или запуска системы.
У опытного технического писателя документирование по ГОСТ, возможно, не вызовет серьезных затруднений. Однако, даже у него подготовка шаблонов новых документов, приведение к требованиями стандартов существующей документации или проверка финального документа на соответствие этим требованиям может занять существенное время.
Dr.Explain упрощает создание руководства пользователя по ГОСТ
Начиная с версии 5.5.1100 программа для создания пользовательской документации Dr.Explain предлагает функцию автоматизированной поддержки ГОСТ в проектах. Эта функция призвана значительно облегчить жизнь пользователям, перед которыми стоит задача создания руководства пользователя в соответствии с требованиями государственных стандартов.
В частности программа Dr.Explain контролирует и автоматизирует поддержку следующих требований стандартов:
- Наличие обязательных разделов документа “Руководство пользователя” [ГОСТ 34 РД 50-34.698-90]. Все разделы снабжаются пояснениями по их содержанию.
- Оформление титульных листов, аннотации и содержания [ГОСТ 19.105-78, 19.104-78].
- Параметры печатных страниц документа и расположение основных элементов на них [ГОСТ 19.106-78].
- Структуру и оформление колонтитулов [ГОСТ 19.106-78].
- Оформление текстовой части документа: стили шрифтов, абзацные отступы, межстрочные интервалы [ГОСТ 19.106-78].
- Формирование и оформление заголовков, разделов, перечислений (списков) [ГОСТ 19.106-78].
Управление функцией поддержки ГОСТ для проекта доступно в Настройках проекта в разделе Общие.
При включенном режиме поддержки ГОСТ для проекта соответствующие пользовательские настройки для печатаемых форматов RTFDOC и PDF автоматически перекрываются программой, что гарантирует полное соответствие параметров выходных документов требованиям стандартов.
Для выходных форматов HTML и CHM будут использоваться пользовательские настройки вне зависимости от активности режима поддержки ГОСТ. Это снимает ограничение на свободную стилизацию этих форматов и позволяет, например, оформить онлайн-справку полностью в корпоративном или тематическом стиле.
Важно: Перед включением режима поддержки ГОСТ для уже существующих в формате Dr.Explain проектов необходимо сделать резервную копию gui-файла проекта.
Важно: Функция поддержки ГОСТ доступна в Dr.Explain только в русскоязычной версии интерфейса. Язык интерфейса программы выбирается в меню НастройкиВыбор языка программы (OptionsApplication language).
Создание нового руководства пользователя по ГОСТ
Для создания нового руководства пользователя по требованиям ГОСТ 34 в программе Dr.Explain можно использовать команды меню Файл Создать локальный проект — Руководство пользователя по ГОСТ 34 или Файл Создать общий проект на tiwri.com — Руководство пользователя по ГОСТ 34
или аналогичные кнопки на стартовом экране приложения.
Программа создаст новый проект, в котором уже присутствуют шаблон титульного листа, аннотация, оглавление и обязательные разделы, оформленные по ГОСТ.
В тексте каждого раздела будет приведена краткая инструкция-подсказка о том, что необходимо включить в данный раздел. Пользователю необходимо только наполнить разделы актуальным содержимым.
Настройки оформления для печатных форматов RTF/DOC и PDF будут выставлены в соответствии с требованиям ГОСТ 19.
Приведение существующей пользовательской документации в соответствие с требованиями ГОСТ
Также программа Dr.Explain позволяет привести существующую пользовательскую документацию в соответствии с требованиями ГОСТ.
Важно: Перед включением режима поддержки ГОСТ для уже существующих в формате Dr.Explain проектов необходимо сделать резервную копию gui-файла проекта.
Если исходная документация еще не ведется в Dr.Explain, а хранится в других форматах, первым шагом необходимо выполнить импорт существующих документов в программу. Dr.Explain поддерживает импорт документов из ряда популярных форматов. Команды импорта доступны как на стартовом окне программы, так и в меню Файл.
Затем необходимо включить режим поддержки ГОСТ в свойствах проекта описанным ранее способом.
Программа проверит структуру документа на наличие обязательных разделов и, если они отсутствуют, создаст их. Остальные существующие разделы, наличие которых не регламентировано ГОСТами, будут перенесены в скрытый от экспорта раздел “Старое дерево разделов”.
Пользователь должен будет перенести содержимое этих разделов или разделы целиком методом drag-n-drop в основное дерево проекта и отредактировать их по необходимости.
Как и в первом случае настройки оформления для печатных форматов RTF/DOC и PDF будут выставлены в соответствии с требованиям ГОСТ 19.
Создайте документацию, соответсвующую ГОСТ 19 и ГОСТ 34 в Dr.Explain бесплатно
Смотрите также
- Шаблоны файлов помощи, руководства пользователя программного обеспечения или сайта, шаблон базы знаний — бесплатные шаблоны и примеры пользовательской документации
Ниже представлен пример (образец) документа «Руководство пользователя«, разработанного на основании методических указаний РД 50-34.698-90.
Данный документ формируется IT-специалистом, или функциональным специалистом, или техническим писателем в ходе разработки рабочей документации на систему и её части на стадии «Рабочая документация».
Для формирования руководства пользователя в качестве примера был взят инструмент Oracle Discoverer информационно-аналитической системы «Корпоративное хранилище данных».
Ниже приведен состав руководства пользователя в соответствии с ГОСТ. Внутри каждого из разделов кратко приведены требования к содержанию и текст примера заполнения (выделен вертикальной чертой).
Разделы руководства пользователя:
- Введение.
- Назначение и условия применения.
- Подготовка к работе.
- Описание операций.
- Аварийные ситуации.
- Рекомендации по освоению.
1. Введение
В разделе «Введение» указывают:
- область применения;
- краткое описание возможностей;
- уровень подготовки пользователя;
- перечень эксплуатационной документации, с которой необходимо ознакомиться пользователю.
1.1. Область применения
Требования настоящего документа применяются при:
- предварительных комплексных испытаниях;
- опытной эксплуатации;
- приемочных испытаниях;
- промышленной эксплуатации.
1.2. Краткое описание возможностей
Информационно-аналитическая система Корпоративное Хранилище Данных (ИАС КХД) предназначена для оптимизации технологии принятия тактических и стратегических управленческих решений конечными бизнес-пользователями на основе информации о всех аспектах финансово-хозяйственной деятельности Компании.
ИАС КХД предоставляет возможность работы с регламентированной и нерегламентированной отчетностью.
При работе с отчетностью используется инструмент пользователя Oracle Discoverer Plus, который предоставляет следующие возможности:
- формирование табличных и кросс-табличных отчетов;
- построение различных диаграмм;
- экспорт и импорт результатов анализа;
- печать результатов анализа;
- распространение результатов анализа.
1.3. Уровень подготовки пользователя
Пользователь ИАС КХД должен иметь опыт работы с ОС MS Windows (95/98/NT/2000/XP), навык работы с ПО Internet Explorer, Oracle Discoverer, а также обладать следующими знаниями:
- знать соответствующую предметную область;
- знать основы многомерного анализа;
- понимать многомерную модель соответствующей предметной области;
- знать и иметь навыки работы с аналитическими приложениями.
Квалификация пользователя должна позволять:
- формировать отчеты в Oracle Discoverer Plus;
- осуществлять анализ данных.
1.4. Перечень эксплуатационной документации, с которой необходимо ознакомиться пользователю
- Информационно-аналитическая система «Корпоративное хранилище данных». ПАСПОРТ;
- Информационно-аналитическая система «Корпоративное хранилище данных». ОБЩЕЕ ОПИСАНИЕ СИСТЕМЫ.
2. Назначение и условия применения Oracle Discoverer Plus
В разделе «Назначение и условия применения» указывают:
- виды деятельности, функции, для автоматизации которых предназначено данное средство автоматизации;
- условия, при соблюдении (выполнении, наступлении) которых обеспечивается применение средства автоматизации в соответствии с назначением (например, вид ЭВМ и конфигурация технических средств, операционная среда и общесистемные программные средства, входная информация, носители данных, база данных, требования к подготовке специалистов и т. п.).
Oracle Discoverer Plus в составе ИАС КХД предназначен для автоматизации подготовки, настройки отчетных форм по показателям деятельности, а также для углубленного исследования данных на основе корпоративной информации хранилища данных.
Работа с Oracle Discoverer Plus в составе ИАС КХД возможна всегда, когда есть необходимость в получении информации для анализа, контроля, мониторинга и принятия решений на ее основе.
Работа с Oracle Discoverer Plus в составе ИАС КХД доступна всем пользователям с установленными правами доступа.
3. Подготовка к работе
В разделе «Подготовка к работе» указывают:
- состав и содержание дистрибутивного носителя данных;
- порядок загрузки данных и программ;
- порядок проверки работоспособности.
3.1. Состав и содержание дистрибутивного носителя данных
Для работы с ИАС КХД необходимо следующее программное обеспечение:
- Internet Explorer (входит в состав операционной системы Windows);
- Oracle JInitiator устанавливается автоматически при первом обращении пользователя к ИАС КХД.
3.2. Порядок загрузки данных и программ
Перед началом работы с ИАС КХД на рабочем месте пользователя необходимо выполнить следующие действия:
- Необходимо зайти на сайт ИАС КХД ias-dwh.ru.
- Во время загрузки в появившемся окне «Предупреждение о безопасности», которое будет содержать следующее: ‘Хотите установить и выполнить «Oracle JInitiator» …’ Нажимаем на кнопку «Да».
- После чего запуститься установка Oracle JInitiator на Ваш компьютер. Выбираем кнопку Next и затем OK.
3.3. Порядок проверки работоспособности
Для проверки доступности ИАС КХД с рабочего места пользователя необходимо выполнить следующие действия:
- Открыть Internet Explorer, для этого необходимо кликнуть по ярлыку «Internet Explorer» на рабочем столе или вызвать из меню «Пуск».
- Ввести в адресную строку Internet Explorer адрес: ias-dwh.ru и нажать «Переход».
- В форме аутентификации ввести пользовательский логин и пароль. Нажать кнопку «Далее».
- Убедиться, что в окне открылось приложение Oracle Discoverer Plus.
В случае если приложение Oracle Discoverer Plus не запускается, то следует обратиться в службу поддержки.
4. Описание операций
В разделе «Описание операций» указывают:
- описание всех выполняемых функций, задач, комплексов задач, процедур;
- описание операций технологического процесса обработки данных, необходимых для выполнения функций, комплексов задач (задач), процедур.
Для каждой операции обработки данных указывают:
- наименование;
- условия, при соблюдении которых возможно выполнение операции;
- подготовительные действия;
- основные действия в требуемой последовательности;
- заключительные действия;
- ресурсы, расходуемые на операцию.
В описании действий допускаются ссылки на файлы подсказок, размещенные на магнитных носителях.
4.1. Выполняемые функции и задачи
Oracle Discoverer Plus в составе ИАС КХД выполняет функции и задачи, приведенные в таблице ниже:
Функции | Задачи | Описание |
---|---|---|
Обеспечивает многомерный анализа в табличной и графической формах | Визуализация отчетности | В ходе выполнения данной задачи пользователю системы предоставляется возможность работы с выбранным отчетом из состава преднастроенных. |
Формирование табличных и графических форм отчетности | В ходе выполнения данной задачи пользователю системы предоставляется возможность формирования собственного отчета в табличном или графическом виде на базе преднастроенных компонентов. |
4.2. Описание операций технологического процесса обработки данных, необходимых для выполнения задач
Ниже приведено описание пользовательских операций для выполнения каждой из задач.
Задача: «Визуализация отчетности»
Операция 1: Регистрация на портале ИАС КХД
Условия, при соблюдении которых возможно выполнение операции:
- Компьютер пользователя подключен к корпоративной сети.
- Портал ИАС КХД доступен.
- ИАС КХД функционирует в штатном режиме.
Подготовительные действия:
На компьютере пользователя необходимо выполнить дополнительные настройки, приведенные в п. 3.2 настоящего документа.
Основные действия в требуемой последовательности:
- На иконке «ИАС КХД» рабочего стола произвести двойной щелчок левой кнопкой мышки.
- В открывшемся окне в поле «Логин» ввести имя пользователя, в поле «Пароль» ввести пароль пользователя. Нажать кнопку «Далее».
Заключительные действия:
Не требуются.
Ресурсы, расходуемые на операцию:
15-30 секунд.
Операция 2: Выбор отчета
Условия, при соблюдении которых возможно выполнение операции:
Успешная регистрация на Портале ИАС КХД.
Подготовительные действия:
Не требуются.
Основные действия в требуемой последовательности:
1. В появившемся окне «Мастер создания рабочих книг» поставить точку напротив пункта «Открыть существующую рабочую книгу».
2. Выбрать нужную рабочую книгу и нажать кнопку «Откр.»:
Заключительные действия:
После завершения работы с отчетом необходимо выбрать пункт меню «Файл», далее выбрать пункт «Закрыть».
Ресурсы, расходуемые на операцию:
15 секунд.
Задача: «Формирование табличных и графических форм отчетности»
Заполняется по аналогии.
5. Аварийные ситуации
В разделе «Аварийные ситуации» указывают: 1. действия в случае несоблюдения условий выполнения технологического процесса, в том числе при длительных отказах технических средств; 2. действия по восстановлению программ и/или данных при отказе магнитных носителей или обнаружении ошибок в данных; 3. действия в случаях обнаружении несанкционированного вмешательства в данные; 4. действия в других аварийных ситуациях.
В случае возникновения ошибок при работе ИАС КХД, не описанных ниже в данном разделе, необходимо обращаться к сотруднику подразделения технической поддержки ДИТ (HelpDesk) либо к ответственному Администратору ИАС КХД.
Класс ошибки | Ошибка | Описание ошибки | Требуемые действия пользователя при возникновении ошибки |
---|---|---|---|
Портал ИАС КХД | Сервер не найден. Невозможно отобразить страницу | Возможны проблемы с сетью или с доступом к порталу ИАС КХД. | Для устранения проблем с сетью обратиться к сотруднику подразделения технической поддержки (HelpDesk). В других случаях к администратору ИАС КХД. |
Ошибка: Требуется ввести действительное имя пользователя | При регистрации на портале ИАС КХД не введено имя пользователя. | Ввести имя пользователя. | |
Ошибка: Требуется ввести пароль для регистрации | При регистрации на портале ИАС КХД не введен пароль. | Ввести пароль. | |
Ошибка: Сбой аутентификации. Повторите попытку | Неверно введено имя пользователя или пароль, либо такая учетная запись не зарегистрирована. | Нужно повторить ввод имени пользователя и пароля, однако после третей неудачной попытки регистрации учетная запись блокируется. Если учетная запись заблокирована, нужно обратиться к администратору ИАС КХД. | |
Сбой в электропитании рабочей станции | Нет электропитания рабочей станции или произошел сбой в электропитании. | Рабочая станция выключилась или перезагрузилась. |
Перезагрузить рабочую станцию. Проверить доступность сервера ИАС КХД по порту 80, выполнив следующие команды: — нажать кнопку «Пуск» — выбрать пункт «Выполнить» — в строке ввода набрать команду telnet ias_dwh.ru 80 — если открылось окно Telnet, значит соединение возможно. Повторить попытку подключения (входа) в ИАС КХД |
Сбой локальной сети | Нет сетевого взаимодействия между рабочей станцией и сервером приложений ИАС КХД | Отсутствует возможность начала (продолжения) работы с ИАС КХД. Нет сетевого подключения к серверу ИАС КХД |
Перезагрузить рабочую станцию. Проверить доступность сервера ИАС КХД по порту 80, выполнив следующие команды: — нажать кнопку «Пуск» — выбрать пункт «Выполнить» — в строке ввода набрать команду telnet ias_dwh.ru 80 — если открылось окно Telnet, значит соединение возможно. После восстановления работы локальной сети повторить попытку подключения (входа) в ИАС КХД. |
6. Рекомендации по освоению
В разделе «Рекомендации по освоению» указывают рекомендации по освоению и эксплуатации, включая описание контрольного примера, правила его запуска и выполнения.
Рекомендуемая литература:
- Oracle® Business Intelligence Discoverer Viewer User’s Guide
- Oracle® Business Intelligence Discoverer Plus User’s Guide
Рекомендуемые курсы обучения:
- Discoverer 10g: Создание запросов и отчетов
В качестве контрольного примера рекомендуется выполнить операции задачи «Визуализация отчетности», описанные в п. 4.2. настоящего документа.
Как написать руководство пользователя программы или сайта — инструкции, советы, помощь, программное обеспечение
Журавлев Денис
Что такое руководство пользователя и для чего его создавать
Ежедневно создаются новые продукты, программы, сервисы и часто пользователям приходится несладко при освоении какой-нибудь сложной программы, поэтому каждому новому продукту желательно собственное руководство. Для чего?
Большинство людей не хочет разбираться с чем-то незнакомым без персонального, всегда доступного и понятного помощника. А именно им и является хорошее руководство пользователя.
Общие советы по созданию пользовательской документации
Перед тем как приступить к созданию руководства, нужно определиться с некоторыми важными моментами. Например, определить, для кого вы его пишете? Кто его будет читать — рядовые пользователи, для которых важны базовые функции продукта, или люди, которым нужны особые, нечасто используемые функции программы/сервиса.
После этого важно подумать о том:
- Где пользователь будет к нему обращаться: дома, на работе, в машине?
- Как часто он будет его просматривать?
- Насколько объективно сложен для понимания продукт?
Из этого можно сделать вывод, насколько интенсивно пользователь будет работать с документацией, а значит уже можно выбрать между сжатым «справочником» или объемным «путеводителем» Также важно, чтобы руководство писал профессионал, знающий продукт. Так что по возможности делегируйте написание техническому специалисту или аналитику, у которого есть полное представление о всех тонкостях продукта.
Определившись со всеми представленными пунктами, станет понятнее, какой нужно использовать стиль изложения, какого объема написать текст. Но помните, что излишне стилистически окрашенные слова мешают пользователю добраться до сути. Так что лучшим вариантом в большинстве случаев будет нейтрально-формальный стиль. Пишите так, чтобы пользователь вас понял. Постарайтесь по возможности избегать технических терминов, но проанализируйте — не сделает ли полное отсутствие терминов ваше руководство бесполезным?
Структура руководства пользователя
После того как вы ответили на предыдущие вопросы, создайте структуру руководства. У любого хорошего «путеводителя» хорошая и логичная структура. Начните с оглавления. Информативное содержание поможет читателю легко ориентироваться в документе.
В первом разделе желательно рассказать общую информацию о программе:
- Для чего создан продукт.
- Какие задачи он решает.
- Какие основные выгоды от использования для клиента.
В следующем разделе можно указать основные элементы пользовательского интерфейса. Пользователю будет трудно разобраться в софте, если он не поймёт для чего служат различные элементы интерфейса, или он не разберётся в основных режимах работы ПО. Опишите понятным языком предназначение экранов и окон.
Создайте раздел, где расскажете о наиболее эффективных способах применения продукта для решения типовых задач. Какие цели стоят перед клиентом, и как ваша программа/сервис помогает достичь их. Укажите информацию о том, как быстро и продуктивно пользоваться программой.
Ни одно руководство не обойдется без таких разделов как: «Частые вопросы» и «Устранение типовых проблем» В них разбираются вопросы и проблемы, с которыми часто сталкиваются пользователи. Для заполнения данного раздела вам скорее всего понадобятся уже готовые отзывы клиентов. Если у вас абсолютно новый продукт, вы можете предугадать проблемы ваших клиентов либо на первое время не включать данный пункт в ваше руководство.
Иногда технические писатели забывают о важном моменте в руководстве пользователя — контактная информация. Этот раздел поможет пользователям связаться с вами, даже если у них нет никаких вопросов и руководство полностью закрывает все их потребности. Клиент может дать совет, поделиться опытом или предложить выгодное вам сотрудничество.
Инструменты для быстрого создания руководства пользователя
Но как создать руководство пользователя, если пишешь его впервые? Или что делать, если руководство пользователя нужно постоянно обновлять и дорабатывать? Или нужны особые функции, которых нет в традиционных текстовых редакторах, например, в 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 — инструмент для создания мобильной версии пользовательской документации к программным продуктам
- Шаблоны файлов помощи, руководства пользователя программного обеспечения или сайта, шаблон базы знаний — бесплатные шаблоны и примеры пользовательской документации
Пояснительная записка составляется профессионалами в области разработки программного обеспечения и для специалистов того же уровня квалификации. Следовательно, в ней уместно использовать специальную терминологию, ссылаться на специальную литературу и т. п.
Как уже указывалось выше, в настоящее время часто используют еще один эксплуатационный документ, в который отчасти входит руководство системного программиста, программиста и оператора. Этот документ называют Руководством пользователя. Появление такого документа явилось следствием широкого распространения персональных компьютеров, работая на которых пользователи совмещают в своем лице трех указанных специалистов.
Составление документации для пользователей имеет свои особенности, связанные с тем, что пользователь, как правило, не является профессионалом в области разработки программного обеспечения. В книге С. Дж. Гримм [17] даны рекомендации по написанию подобной программной документации:
•учитывайте интересы пользователей – руководство должно содержать все инструкции, необходимые пользователю;
•излагайте ясно, используйте короткие предложения;
•избегайте технического жаргона и узко специальной терминологии, если все же необходимо использовать некоторые термины, то их следует пояснить;
•будьте точны и рациональны – длинные и запутанные руководства обычно никто не читает, например, лучше привести рисунок формы, чем долго ее описывать.
Руководство пользователя, как правило, содержит следующие разделы:
•общие сведения о программном продукте;
•описание установки;
•описание запуска;
•инструкции по работе (или описание пользовательского интерфейса);
•сообщения пользователю.
Раздел Общие сведения о программе обычно содержит наименование программного продукта, краткое описание его функций, реализованных методов и возможных областей применения.
Раздел Установка обычно содержит подробное описание действий по установке программного продукта и сообщений, которые при этом могут быть получены.
В разделе Запуск, как правило, описаны действия по запуску программного продукта и сообщений, которые при этом могут быть получены.
Раздел Инструкции по работе обычно содержит описание режимов работы, форматов ввода-вывода информации и возможных настроек.
303
Раздел Сообщения пользователю должен содержать перечень возможных сообщений, описание их содержания и действий, которые необходимо предпринять по этим сообщениям.
11.4. Руководство системного программиста
По ГОСТ 19.503–79 руководство системного программиста должно содержать всю информацию, необходимую для установки программного обеспечения, его настройки и проверки работоспособности. Кроме того, как указывалось выше, в него часто включают и описание необходимого обслуживания, которое раньше приводилось в руководстве оператора (ГОСТ 19.505–79) и/или руководстве по техническому обслуживанию (ГОСТ 19.508–79). В настоящее время данную схему используют для составления руководства системному администратору.
Руководство системного программиста должно содержать следующие разделы:
•общие сведения о программном продукте,
•структура,
•настройка,
•проверка,
•дополнительные возможности,
•сообщения системному программисту.
Раздел Общие сведения о программе должен включать описание назначения и функций программы, а также сведения о технических и программных средствах, обеспечивающих выполнение данной программы (например, объем оперативной памяти, требования к составу
ипараметрам внешних устройств, требования к программному обеспечению и т. п.).
Вразделе Структура программы должны быть приведены сведения о структуре программы, ее составных частях, о связях между составными частями и о связях с другими программами.
Вразделе Настройка программы должно быть приведено описание действий по настройке программы на условия практического применения.
Вразделе Проверка программы должно быть приведено описание способов проверки работоспособности программы, например контрольные примеры.
Вразделе Дополнительные возможности должно быть приведено описание дополнительных возможностей программы и способов доступа к ним.
Вразделе Сообщения системному программисту должны быть указаны тексты сообщений, выдаваемых в ходе выполнения настройки и проверки программы, а также в ходе ее выполнения, описание их содержания и действий, которые необходимо предпринять по этим сообщениям.
304
11.5. Основные правила оформления программной документации
При оформлении текстовых и графических материалов, входящих в программную документацию следует придерживаться действующих стандартов. Некоторые положения этих стандартов приведены ниже.
Оформление текстового и графического материала. Текстовые документы оформляют на листах формата А4, причем графический материал допускается представлять на листах формата A3. Поля на листе определяют в соответствии с общими требованиями: левое – не менее 30, правое – не менее 10, верхнее – не менее 15, а нижнее – не менее 20 мм. В текстовых редакторах для оформления записки параметры страницы заказывают в зависимости от устройства печати. При ручном оформлении документов параметры страницы выбирают из соображений удобства.
Нумерация всех страниц – сквозная. Номер проставляется сверху справа арабской цифрой. Страницами считают, как листы с текстами и рисунками, так и листы приложений. Первой страницей считается титульный лист. Номер страницы на титульном листе не проставляют.
Наименование разделов пишут прописными буквами в середине строки. Расстояние между заголовками и текстом, а также между заголовками раздела и подразделов должно быть равно:
•при выполнении документа машинописным способом – двум интервалам;
•при выполнении рукописным способом – 10 мм;
•при использовании текстовых редакторов – определяется возможностями редактора. Наименования подразделов и пунктов следует размещать с абзацного отступа и
печатать вразрядку с прописной буквы, не подчеркивая и без точки в конце. Расстояние между последней строкой текста предыдущего раздела и последующим заголовком при расположении их на одной странице должно быть равно:
•при выполнении документа машинописным способом – трем интервалам;
•при выполнении рукописным способом – не менее 15 мм;
•при использовании текстовых редакторов – определяется возможностями редактора. Разделы и подразделы нумеруются арабскими цифрами с точкой. Разделы должны
иметь порядковые номера 1, 2, и т. д. Номер подраздела включает номер раздела и порядковый номер подраздела, входящего в данный раздел, разделенные точкой. Например: 2.1, 3.5. Ссылки на пункты, разделы и подразделы указывают, используя порядковый номер раздела или пункта, например, «в разд. 4», «в п. 3.3.4».
305
Текст разделов печатают через 1,5-2 интервала. При использовании текстовых редакторов высота букв и цифр должна быть не менее 1,8 мм (шрифты № 11-12).
Перечисления следует нумеровать арабскими цифрами со скобкой, например: 2), 3) и т.д. – с абзацного отступа. Допускается выделять перечисление простановкой дефиса перед пунктом текста или символом, его заменяющим, в текстовых редакторах.
Оформление рисунков, схем алгоритмов, таблиц и формул. В соответствии с ГОСТ 2.105–79 «Общие требования к текстовым документам» иллюстрации (графики, схемы, диаграммы) могут быть приведены как в основном тексте, так и в приложении. Все иллюстрации именуют рисунками. Все рисунки, таблицы и формулы нумеруют арабскими цифрами последовательно (сквозная нумерация) или в пределах раздела (относительная нумерация). В приложении – в пределах приложения.
Каждый рисунок должен иметь подрисуночную подпись – название, помещаемую под рисунком, например:
Рис.12. Форма окна основного меню
На все рисунки, таблицы и формулы в записке должны быть ссылки в виде: «(рис. 12)» или «форма окна основного меню приведена на рис. 12».
Если позволяет место, рисунки и таблицы должны размещаться сразу после абзаца, в котором они упоминаются в первый раз, или как можно ближе к этому абзацу на следующих страницах.
Если рисунок занимает более одной страницы, на всех страницах, кроме первой, проставляется номер рисунка и слово «Продолжение». Например:
Рис. 12. Продолжение
Рисунки следует размещать так, чтобы их можно было рассматривать без поворота страницы. Если такое размещение невозможно, рисунки следует располагать так, чтобы для просмотра надо было повернуть страницу по часовой стрелке. В этом случае верхним краем является левый край страницы. Расположение и размеры полей сохраняются.
Схемы алгоритмов должны быть выполнены в соответствии со стандартом ЕСПД. Толщина сплошной линии при вычерчивании схем алгоритмов должна составлять от 0,6…1,5 мм. Надписи на схемах должны быть выполнены чертежным шрифтом, высота букв и цифр должна быть не менее 3,5 мм.
Номер таблицы размещают в правом верхнем углу или перед заголовком таблицы, если он есть. Заголовок, кроме первой буквы, выполняют строчными буквами.
Ссылки на таблицы в тексте пояснительной записки указывают в виде слова «табл.» и номера таблицы. Например:
306
Результаты тестов приведены в табл. 4.
Номер формулы ставится с правой стороны страницы в круглых скобках на уровне формулы. Например:
Ссылка на номер формулы дается в скобках. Например: «расчет значений проводится по формуле (12)».
Оформление приложений. Каждое приложение должно начинаться с новой страницы с указанием в правом углу слова «ПРИЛОЖЕНИЕ» прописными буквами и иметь тематический заголовок. При наличии более одного приложения все они нумеруются арабскими цифрами: ПРИЛОЖЕНИЕ 1, ПРИЛОЖЕНИЕ 2 и т. д. Например:
ПРИЛОЖЕНИЕ 2
Титульный лист расчетно–пояснительной записки
Рисунки и таблицы, помещаемые в приложении, нумеруют арабскими цифрами в пределах каждого приложения с добавлением буквы «П». Например:
Рис. П. 12 – 12-й рисунок приложения; Рис. П1.2 – 2-й рисунок 1-го приложения.
Если в приложении приводится текст программы, то каждый файл оформляют как рисунок с наименованием файла и его назначением, например:
Рис. П2.4. Файл menuran.pas – программа движения курсора основного меню.
Оформление списка литературы. Список литературы должен включать все использованные источники. Сведения о книгах (монографиях, учебниках, пособиях, справочниках и т. д.) должны содержать: фамилию и инициалы автора, заглавие книги, место издания, издательство, год издания. При наличии трех и более авторов допускается указывать фамилию и инициалы только первого из них со словами «и др.». Издательство надо приводить полностью в именительном падеже: допускается сокращение названия только двух городов: Москва (М.) и Санкт–Петербург (СПб.).
Сведения о статье из периодического издания должны включать: фамилию и инициалы автора, наименование статьи, издания (журнала), серии (ес-
307
Соседние файлы в предмете Программирование
- #
- #
- #
Руководство пользователя – это основной документ в составе эксплуатационной документации на автоматизированную систему (ГОСТ 34). Очевидно ли это?
Назначение руководства пользователя
Цель создания документа заключается в том, чтобы предоставить пользователю возможность самостоятельно решать свои прикладные задачи с помощью системы. Этой цели может служить и введение в предметную область, и ознакомление со всеми возможностями программы, и описание конкретных процедур решения задач, и приведение различных инструкций. Иногда Руководство пользователя больше похоже на справочник, к которому можно обращаться в процессе работы, а иногда – на учебник, который позволяет изучить принципы работы с программой и ее возможности, а затем применять их на практике.
Состав типового руководства пользователя
Конкретный подход к написанию определяется многими факторами:
– назначением программы и областью ее применения;
– сложностью программы;
– количеством разнообразных вариантов использования.
Принимая во внимание все различия и особенности, сложно привести структуру любого Руководства пользователя к одному виду. Тем не менее, РД 50-34.698 предлагает нам такой список разделов:
– Введение, где указывают область применения ПО, краткое описывают его возможности, требуемый уровень знаний пользователя и список документов, которые необходимо изучить помимо настоящего руководства;
– Назначение и условия применения, где описывают виды деятельности и функции, которые автоматизированы и условия, при соблюдении которых автоматизация используется;
– Подготовка к работе, где описывают комплектность дистрибутива, порядок установки и загрузки программы, а также способ проверки ее работоспособности;
– Описание операций, представляет собой основной раздел, где описывают функции программы, процессы работы с данными, выполнение конкретных задач пользователя;
– Аварийные ситуации, где описывают действия в нештатных ситуациях – сбоях в программе, ошибок в данных и т.д.;
– Рекомендации по освоению, где приводят методические рекомендации по изучению программы и примеры использования.
Данная структура может меняться и дополняться – например, основной раздел часто разбивают на несколько значимых разделов по группам функций или задач, также в современных системах нередко добавляют раздел Интерфейс пользователя, где описывают взаимодействие пользователя с программой с примерами и снимками экрана.
Стандарты для руководства пользователя
Наличие Руководства пользователя регламентируется ГОСТ 34.201, а структура и содержание – РД 50-34.698. Однако, в зависимости от сложности, назначения и области применения ПО, различные Руководства пользователя могут отличаться друг от друга по способу, методике и стилю изложения.
Стоимость разработки руководства пользователя
Наименование документа |
Наименование стандарта |
Стоимость разработки |
---|---|---|
РП на автоматизированную систему |
РД 50-34.698 |
70 тыс. р. |
Грамотно написанное Руководство пользователя может сэкономить значительное количество времени на обучение и адаптацию пользователя к программе, а также снизить количество ошибок в работе что, в свою очередь, повышает экономическую эффективность системы. Если вы не хотите вникать во все тонкости создания Руководства пользователя, но хотите иметь полный, качественный и полезный документ – обратитесь в компанию ТехРайтКонсалт, и мы применим весь наш опыт и знания для решения вашей задачи по доступной цене!
Возможно, вас также заинтересует:
– разработка руководства администратора;
– создание руководства программиста;
– разработка руководства оператора.
From Wikipedia, the free encyclopedia
For a full guide to an item owned by its operator, see Owner’s manual.
A user guide, also commonly known as a user manual, is intended to assist users in using a particular product, service or application. It’s usually written by a technician, product developer, or a company’s customer service staff.
Most user guides contain both a written guide and associated images. In the case of computer applications, it is usual to include screenshots of the human-machine interface(s), and hardware manuals often include clear, simplified diagrams. The language used is matched to the intended audience, with jargon kept to a minimum or explained thoroughly.
Contents of a user manual[edit]
The sections of a user manual often include:
- A cover page
- A title page and copyright page
- A preface, containing details of related documents and information on how to navigate the user guide
- A contents page
- A Purpose section. This should be an overview rather than detail the objective of the document
- An Audience section to explicitly state who is the intended audience who is required to read, including optionals
- A Scope section is crucial as it also serves as a disclaimer, stating what is out-of-scope as well as what is covered
- A guide on how to use at least the main function of the system
- A troubleshooting section detailing possible errors or problems that may occur, along with how to fix them
- A FAQ (Frequently Asked Questions)
- Where to find further help, and contact details
- A glossary and, for larger documents, an index
History[edit]
The user guide engraved into a model of the Antikythera Mechanism.
User guides have been found with ancient devices. One example is the Antikythera Mechanism,[1] a 2,000 year old Greek analogue computer that was found off the coast of the Greek island Antikythera in the year 1900. On the cover of this device are passages of text which describe the features and operation of the mechanism.
As the software industry was developing, the question of how to best document software programs was undecided. This was a unique problem for software developers, since users often became frustrated with current help documents.[2] Some considerations for writing a user guide that developed at this time include:
- the use of plain language[2]
- length and reading difficulty[2]
- the role of printed user guides for digital programs[3]
- user-centered design[3]
Computer software manuals and guides[edit]
User manuals and user guides for most non-trivial software applications are book-like documents with contents similar to the above list. They may be distributed either in print or electronically. Some documents have a more fluid structure with many internal links. The Google Earth User Guide[4] is an example of this format. The term guide is often applied to a document that addresses a specific aspect of a software product. Some usages are Installation Guide, Getting Started Guide, and various How to guides. An example is the Picasa Getting Started Guide.[5]
In some business software applications, where groups of users have access to only a sub-set of the application’s full functionality, a user guide may be prepared for each group. An example of this approach is the Autodesk Topobase 2010 Help[6] document, which contains separate Administrator Guides, User Guides, and a Developer’s Guide.
See also[edit]
- Owner’s manual
- Release notes
- Moe book
- Technical writer
- Manual page (Unix)
- Instruction manual (gaming)
- Reference card
- RTFM
- HOWTO
References[edit]
- ^ «Boffins decipher manual for 2,000-year-old Ancient Greek computer». Retrieved 2018-11-29.
- ^ a b c Chafin, Roy (January 1982). «User Manuals: What Does the User Really Need?». SIGDOC ’82 Proceedings of the 1st Annual International Conference on Systems Documentation: 36–39. doi:10.1145/800065.801307. S2CID 6435788.
- ^ a b McKee, John (August 1986). «Computer User Manuals in Print: Do They Have a Future?». ACM SIGDOC Asterisk Journal of Computer Documentation. 12 (2): 11–16. doi:10.1145/15505.15507. S2CID 35615987.
- ^ «Google Earth User Guide». 4 June 2009. Retrieved 13 August 2009.
- ^ «Getting Started with Picasa: Getting Started Guide». 15 June 2009. Retrieved 13 August 2009.
- ^ «Autodesk Topobase 2010 Help». Autodesk. Retrieved 13 August 2009.
ГОСТ 19.504-79
Группа Т55
МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ
Единая система программной документации
РУКОВОДСТВО ПРОГРАММИСТА
Требования к содержанию и оформлению
Unified system for program documentation. Programmer»s guide. Requirements for contents and form of presentation
МКС 35.080
Дата введения 1980-01-01
Постановлением Государственного комитета CCCР по стандартам от 12 января 1979 г. N 74 дата введения установлена 01.01.80
ИЗДАНИЕ (январь 2010 г.) с Изменением N 1, утвержденным в сентябре 1981 г. (ИУС 11-81).
Настоящий стандарт устанавливает требования к содержанию и оформлению программного документа «Руководство программиста», определенного ГОСТ 19.101-77 .
Стандарт полностью соответствует СТ СЭВ 2095-80*.
________________
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей . — Примечание изготовителя базы данных.
(Измененная редакция, Изм. N 1).
1. ОБЩИЕ ПОЛОЖЕНИЯ
1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Структура и оформление документа устанавливаются в соответствии с ГОСТ 19.105-78 .
Составление информационной части (аннотации и содержания) является обязательным.
1.2. Руководство программиста должно содержать следующие разделы:
назначение и условия применения программы;
характеристики программы;
обращение к программе;
входные и выходные данные;
сообщения.
В зависимости от особенностей документа допускается объединять отдельные разделы или вводить новые.
2.1. В разделе «Назначение и условия применения программы» должны быть указаны назначение и функции, выполняемые программой, условия, необходимые для выполнения программы (объем оперативной памяти, требования к составу и параметрам периферийных устройств, требования к программному обеспечению и т.п.).
2.2. В разделе «Характеристики программы» должно быть приведено описание основных характеристик и особенностей программы (временные характеристики, режим работы, средства контроля правильности выполнения и самовосстанавливаемости программы и т.п.).
2.3. В разделе «Обращение к программе» должно быть приведено описание процедур вызова программы (способы передачи управления и параметров данных и др.).
2.4. В разделе «Входные и выходные данные» должно быть приведено описание организации используемой входной и выходной информации и, при необходимости, ее кодирования.
2.5. В разделе «Сообщения» должны быть указаны тексты сообщений, выдаваемых программисту или оператору в ходе выполнения программы, описание их содержания и действия, которые необходимо предпринять по этим сообщениям.
2.6. В приложении к руководству программиста могут быть приведены дополнительные материалы (примеры, иллюстрации, таблицы, графики и т.п.).
Электронный текст документа
подготовлен АО «Кодекс» и сверен по:
официальное издание
Единая система программной документации:
Сборник национальных стандартов. —
М.: Стандартинформ, 2010
Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р
Единая система программной документации |
ГОСТ 19.504-79(СТ СЭВ 2095-80) |
РУКОВОДСТВО ПРОГРАММИСТА.
|
|
United system for program documentation. |
Постановлением Государственного комитета стандартов Совета Министров СССР от 12 января 1979 г. ¹ 74 срок введения установлен
с 01.01. 1980 г.
Настоящий стандарт устанавливает требования к содержанию и оформлению программного документа «Руководство программиста», определённого ГОСТ 19.101-77 .
Стандарт полностью соответствует СТ СЭВ 2095-80.
1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Структуру и оформление документа устанавливают в соответствии с ГОСТ 19.105-78 .
Составление информационной части (аннотации и содержания) является обязательным.
1.2. Руководство программиста должно содержать следующие разделы:
- назначение и условия применения программ;
- характеристика программы;
- обращение к программе;
- входные и выходные данные;
- сообщения.
В зависимости от особенностей документы допускается объединять отдельные разделы или вводить новые.
2.1. В разделе «Назначение и условия применения программ» должны быть указаны назначение и функции, выполняемые программой, условия, необходимые для выполнения программы (объем оперативной памяти, требования к составу и параметрам периферийных устройств, требования к программного обеспечению и т.п.).
2.2. В разделе «Характеристика программы» должно быть приведено описание основных характеристик и особенностей программы (временные характеристики, режим работы, средства контроля правильности выполнения и самовосстанавливаемости программы и т.п.).
2.3. В разделе «Обращение к программе» должно быть приведено описание процедур вызова программы (способы передачи управления и параметров данных и др.).
2.4. В разделе «Входные и выходные данные» должно быть приведено описание организации используемой входной и выходной информации и, при необходимости, ее кодирования.
2.5. В разделе «Сообщения» должны быть указаны тексты сообщений, выдаваемых программисту или оператору в ходе выполнения программы, описание их содержания и действий, которые необходимо предпринять по этим сообщениям.
2.6. В приложении к руководству программиста могут быть приведены дополнительные материалы (примеры, иллюстрации, таблицы, графики и т.п.).
* Переиздание (Ноябрь 1987 г.) с Изменением № 1, утвержденным в сентябре 1981 г (ИУС 11-81)
Ниже представлен пример (образец) документа «Руководство пользователя
«, разработанного на основании методических указаний РД 50-34.698-90 .
Данный документ формируется IT-специалистом, или функциональным специалистом, или техническим писателем в ходе разработки рабочей документации на систему и её части на стадии «Рабочая документация».
Для формирования руководства пользователя в качестве примера был взят инструмент Oracle Discoverer
информационно-аналитической системы «Корпоративное хранилище данных».
Ниже приведен состав руководства пользователя в соответствии с ГОСТ. Внутри каждого из разделов кратко приведены требования к содержанию и текст примера заполнения
(выделен вертикальной чертой).
Разделы руководства пользователя:
1. Введение
В разделе «Введение» указывают:
- область применения;
- краткое описание возможностей;
- уровень подготовки пользователя;
- перечень эксплуатационной документации, с которой необходимо ознакомиться пользователю.
1.1. Область применения
Требования настоящего документа применяются при:
- предварительных комплексных испытаниях;
- опытной эксплуатации;
- приемочных испытаниях;
- промышленной эксплуатации.
1.2. Краткое описание возможностей
Информационно-аналитическая система Корпоративное Хранилище Данных (ИАС КХД) предназначена для оптимизации технологии принятия тактических и стратегических управленческих решений конечными бизнес-пользователями на основе информации о всех аспектах финансово-хозяйственной деятельности Компании.
ИАС КХД предоставляет возможность работы с регламентированной и нерегламентированной отчетностью.
При работе с отчетностью используется инструмент пользователя Oracle Discoverer Plus, который предоставляет следующие возможности:
- формирование табличных и кросс-табличных отчетов;
- построение различных диаграмм;
- экспорт и импорт результатов анализа;
- печать результатов анализа;
- распространение результатов анализа.
1.3. Уровень подготовки пользователя
Пользователь ИАС КХД должен иметь опыт работы с ОС MS Windows (95/98/NT/2000/XP), навык работы с ПО Internet Explorer, Oracle Discoverer, а также обладать следующими знаниями:
- знать соответствующую предметную область;
- знать основы многомерного анализа;
- понимать многомерную модель соответствующей предметной области;
- знать и иметь навыки работы с аналитическими приложениями.
Квалификация пользователя должна позволять:
- формировать отчеты в Oracle Discoverer Plus;
- осуществлять анализ данных.
1.4. Перечень эксплуатационной документации, с которой необходимо ознакомиться пользователю
- Информационно-аналитическая система «Корпоративное хранилище данных». ПАСПОРТ;
- Информационно-аналитическая система «Корпоративное хранилище данных». ОБЩЕЕ ОПИСАНИЕ СИСТЕМЫ.
2. Назначение и условия применения Oracle Discoverer Plus
В разделе «Назначение и условия применения» указывают:
- виды деятельности, функции, для автоматизации которых предназначено данное средство автоматизации;
- условия, при соблюдении (выполнении, наступлении) которых обеспечивается применение средства автоматизации в соответствии с назначением (например, вид ЭВМ и конфигурация технических средств, операционная среда и общесистемные программные средства, входная информация, носители данных, база данных, требования к подготовке специалистов и т. п.).
Oracle Discoverer Plus в составе ИАС КХД предназначен для автоматизации подготовки, настройки отчетных форм по показателям деятельности, а также для углубленного исследования данных на основе корпоративной информации хранилища данных.
Работа с Oracle Discoverer Plus в составе ИАС КХД возможна всегда, когда есть необходимость в получении информации для анализа, контроля, мониторинга и принятия решений на ее основе.
Работа с Oracle Discoverer Plus в составе ИАС КХД доступна всем пользователям с установленными правами доступа.
3. Подготовка к работе
В разделе «Подготовка к работе» указывают:
- состав и содержание дистрибутивного носителя данных;
- порядок загрузки данных и программ;
- порядок проверки работоспособности.
3.1. Состав и содержание дистрибутивного носителя данных
Для работы с ИАС КХД необходимо следующее программное обеспечение:
- Internet Explorer (входит в состав операционной системы Windows);
- Oracle JInitiator устанавливается автоматически при первом обращении пользователя к ИАС КХД.
3.2. Порядок загрузки данных и программ
Перед началом работы с ИАС КХД на рабочем месте пользователя необходимо выполнить следующие действия:
- Необходимо зайти на сайт ИАС КХД ias-dwh.ru.
- Во время загрузки в появившемся окне «Предупреждение о безопасности», которое будет содержать следующее: «Хотите установить и выполнить «Oracle JInitiator» …» Нажимаем на кнопку «Да».
- После чего запуститься установка Oracle JInitiator на Ваш компьютер. Выбираем кнопку Next и затем OK.
3.3. Порядок проверки работоспособности
Для проверки доступности ИАС КХД с рабочего места пользователя необходимо выполнить следующие действия:
- Открыть Internet Explorer, для этого необходимо кликнуть по ярлыку «Internet Explorer» на рабочем столе или вызвать из меню «Пуск».
- Ввести в адресную строку Internet Explorer адрес: ias-dwh.ru и нажать «Переход».
- В форме аутентификации ввести пользовательский логин и пароль. Нажать кнопку «Далее».
- Убедиться, что в окне открылось приложение Oracle Discoverer Plus.
В случае если приложение Oracle Discoverer Plus не запускается, то следует обратиться в службу поддержки.
4. Описание операций
В разделе «Описание операций» указывают:
- описание всех выполняемых функций, задач, комплексов задач, процедур;
- описание операций технологического процесса обработки данных, необходимых для выполнения функций, комплексов задач (задач), процедур.
Для каждой операции обработки данных указывают:
- наименование;
- условия, при соблюдении которых возможно выполнение операции;
- подготовительные действия;
- основные действия в требуемой последовательности;
- заключительные действия;
- ресурсы, расходуемые на операцию.
4.1. Выполняемые функции и задачи
Oracle Discoverer Plus в составе ИАС КХД выполняет функции и задачи, приведенные в таблице ниже:
4.2. Описание операций технологического процесса обработки данных, необходимых для выполнения задач
Ниже приведено описание пользовательских операций для выполнения каждой из задач.
Задача: «Визуализация отчетности»
Операция 1: Регистрация на портале ИАС КХД
- Компьютер пользователя подключен к корпоративной сети.
- Портал ИАС КХД доступен.
- ИАС КХД функционирует в штатном режиме.
Подготовительные действия:
На компьютере пользователя необходимо выполнить дополнительные настройки, приведенные в п. 3.2 настоящего документа.
- На иконке «ИАС КХД» рабочего стола произвести двойной щелчок левой кнопкой мышки.
- В открывшемся окне в поле «Логин» ввести имя пользователя, в поле «Пароль» ввести пароль пользователя. Нажать кнопку «Далее».
Заключительные действия:
Не требуются.
15-30 секунд.
Операция 2: Выбор отчета
Условия, при соблюдении которых возможно выполнение операции:
Успешная регистрация на Портале ИАС КХД.
Подготовительные действия:
Не требуются.
Основные действия в требуемой последовательности:
1. В появившемся окне «Мастер создания рабочих книг» поставить точку напротив пункта «Открыть существующую рабочую книгу».
2. Выбрать нужную рабочую книгу и нажать кнопку «Откр.»:
Заключительные действия:
После завершения работы с отчетом необходимо выбрать пункт меню «Файл», далее выбрать пункт «Закрыть».
Ресурсы, расходуемые на операцию:
15 секунд.
Задача: «Формирование табличных и графических форм отчетности»
Заполняется по аналогии.
5. Аварийные ситуации
В разделе «Аварийные ситуации» указывают: 1. действия в случае несоблюдения условий выполнения технологического процесса, в том числе при длительных отказах технических средств; 2. действия по восстановлению программ и/или данных при отказе магнитных носителей или обнаружении ошибок в данных; 3. действия в случаях обнаружении несанкционированного вмешательства в данные; 4. действия в других аварийных ситуациях.
В случае возникновения ошибок при работе ИАС КХД, не описанных ниже в данном разделе, необходимо обращаться к сотруднику подразделения технической поддержки ДИТ (HelpDesk) либо к ответственному Администратору ИАС КХД.
Класс ошибки | Ошибка | Описание ошибки | Требуемые действия пользователя при возникновении ошибки |
---|---|---|---|
Портал ИАС КХД | Сервер не найден. Невозможно отобразить страницу | Возможны проблемы с сетью или с доступом к порталу ИАС КХД. | Для устранения проблем с сетью обратиться к сотруднику подразделения технической поддержки (HelpDesk). В других случаях к администратору ИАС КХД. |
Ошибка: Требуется ввести действительное имя пользователя | При регистрации на портале ИАС КХД не введено имя пользователя. | Ввести имя пользователя. | |
Ошибка: Требуется ввести пароль для регистрации | При регистрации на портале ИАС КХД не введен пароль. | Ввести пароль. | |
Ошибка: Сбой аутентификации. Повторите попытку | Неверно введено имя пользователя или пароль, либо такая учетная запись не зарегистрирована. | Нужно повторить ввод имени пользователя и пароля, однако после третей неудачной попытки регистрации учетная запись блокируется. Если учетная запись заблокирована, нужно обратиться к администратору ИАС КХД. | |
Сбой в электропитании рабочей станции | Нет электропитания рабочей станции или произошел сбой в электропитании. | Рабочая станция выключилась или перезагрузилась. |
— нажать кнопку «Пуск» Повторить попытку подключения (входа) в ИАС КХД |
Сбой локальной сети | Нет сетевого взаимодействия между рабочей станцией и сервером приложений ИАС КХД | Отсутствует возможность начала (продолжения) работы с ИАС КХД. Нет сетевого подключения к серверу ИАС КХД |
Перезагрузить рабочую станцию. Проверить доступность сервера ИАС КХД по порту 80, выполнив следующие команды: — нажать кнопку «Пуск» — выбрать пункт «Выполнить» — в строке ввода набрать команду telnet ias_dwh.ru 80 — если открылось окно Telnet, значит соединение возможно. После восстановления работы локальной сети повторить попытку подключения (входа) в ИАС КХД. |
Ковтун М.В. Январь 2012.
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Руководство программиста
- 1. Назначение и условия применения
- 2. Характеристика программы
- 3. Обращение к программе
- 4. Полный перечень модулей и компонентов
- 5. Сообщение пользователю
1
.
Назначение и условия применения
Данный программный продукт может быть использован непосредственно для осуществления деятельности в организации «Проф&Элит», которая занимается установкой пластиковых конструкций, в том числе окон. программный пластиковый оконо
Программный продукт «Проф&Элит» служит для сбора информации о клиентах, сотрудниках, данных замеров для изготовления и производства изделий. Обеспечивает централизованное хранение данных. Продукт обладает простым и понятным интерфейсом, поэтому у пользователя не будет проблем в его освоении.
Проектирование данного программного продукта поможет автоматизировать работу менеджера по работе с дилерами.
Требования к аппаратному обеспечению:
· процессор Intel Pentium
IV и выше;
· оперативная память 512 Мб и выше;
· видеокарта AGP/PCI Express 64 Мб и выше;
· свободное пространство на диске 12 Мб;
· видеомонитор с разрешением 1024×768;
· клавиатура;
· мышь;
· принтер для вывода на печать отчетов;
· операционная система Windows 98/2000/XP/Vista/7/8;
· Microsoft Access, Borland Delphi 7.
2
.
Характеристика программы
В тестовом режиме был произведен запрос к форме ввода/вывода и введены данные в главную таблицу, что позволило оценить наглядно загруженность центрального процессора (ЦП) и использование выделенной (виртуальной) памяти с помощью «Диспетчера задач», как изображено на рис.Б.1 и рис.Б.2.
Рис.Б.2- Выделенная память и время загрузки
3
.
Обращение к программе
Запуск приложения возможен по щелчку на иконке самой программы, находящейся в специальном каталоге. После запуска приложения на экране отображается главное окно, с помощью которого можно управлять всеми функциями приложения, описанными в разделе 4 данного руководства пользователя.
Запустить данную программу можно непосредственно через оболочку Delphi. Для этого требуется открыть файл проекта Project1.dbr, находящемся в каталоге с программой. Далее, нажав F9, скомпилировать и запустить приложение.
Возможен запуск программы через командную строку. Запустить командную строку «Пуск/Все программы/Стандартные/Командная строка» Далее в командной строке необходимо ввести полный путь к программе, далее написать название программы (Project1.exe) и нажать Enter. Программа запущена.
Еще один способ запуска программы: в меню «Пуск» выберите пункт «Выполнить». В результате на экране откроется окно «Выполнение программы». В поле «Открыть» окна «Выполнение программы» введите путь к файлу программы, которую требуется запустить.
Выход из приложения возможен при нажатии на кнопку «Закрыть» или с помощью пункта меню программы «Файл/Выход», а также можно воспользоваться сочетанием клавиш Alt+F4.
4
.
Полный перечень модулей и компонентов
Основная форма содержит перечень всех используемых в программе модулей и несколько исполняемых операторов, обеспечивающих создание нужных окон и связь программы с ОС Windows. Вся основная работа программы управляется кодом, содержащимся в модулях.
В состав данного программного продукта входят следующие модули:
Unit1.pas — главный модуль программы, где непосредственно происходит заполнение данных по заказам;
Unit2.pas — отправка заказа дилеру (дилерский терминал);
Unit3.pas — модуль программы, где происходит заполнение данных по замерам изделия (окна);
Unit4.pas — модуль программы, где происходит заполнение данных по установке изделия (окна);
Unit5.pas — поиск, фильтрация, сортировка по заказам;
Unit6.pas — модуль «О программе».
В главной форме имеются компоненты, изображенные на рис.Б.3. На рисунке также изображено «дерево» всех компонентов формы (рис. Б.4).
Рисунок Б.3 — Компоненты главной формы
Компоненты главной формы:
TADOConnection — используется для указания базы данных и работы транзакциями;
TADOTable — таблица доступная через ADO;
DataSource обеспечивает механизм для связи компонентов доступа к данным (Table) с визуальными компонентами, которые отображают данные (DBGrid, DBEdit, DBListBox и т. д.)
TADOQuery — выполняет запрос (выборку) к базе данных;
TMainMenu — создает главное меню программы;
TDBGrid — осуществляет отображение данных из базы данных в виде таблицы;
TEdit — поле для ввода текстовых сообщений;
TButton — кнопка;
TComboBox — выпадающий список;
TDBCtrlGrid — используется для отображения таблицы в виде «кирпичиков»;
TLabel — надписи;
TGroupBox — панель, как отельный элемент с другими компонентами;
TDBNavigator — компонент для управления навигацией и редактированием данных;
TDBEdit — поле редактирования записи базы данных;
TDateTimePicker — выбор даты;
TSpeedButton — быстрая кнопка;
TBitBtn — кнопка, передающая действие форме;
TBevel — предназначен в приложении для простого обведения чего-либо рамкой.
Компоненты главной формы необходимы для вывода таблиц из базы данных, для изменения, добавления, удаления, фильтрации, поиска, перехода к другим форм и для иных действий.
Рисунок Б.4 — Структура компонентов
5
.
Сообщение пользователю
Если пользователь ввёл неверные значения для фильтрации данных базы данных, то выводится сообщение, показанное на рис.Б.5.
Рис.Б.5 — Сообщение об ошибке
Если произошла ошибка при удалении данных, то выводиться сообщение об ошибке, показанное на рис.Б.6.
программный пластиковый окно
Рис.Б.6 — Сообщение об ошибке.
Пользователь забыл ввести номер накладной при сохранении заказа, то выводиться сообщение об ошибке, показанное на рис.Б.7.
Рис.Б.7 — Сообщение о ошибке
При попытке удаления выводится сообщение, показанное на рис.Б.8.
Рис.Б.8 — Диалог с пользователем
Если пользователь ввёл уже номер существующей накладной при сохранении заказа, выводится сообщение, показанное на рис.Б.9.
Рис.Б.9 — Диалог с пользователем
Размещено на Allbest.ru
…
Подобные документы
Создание классов, реализующих работу со списками и применение их к задаче построения графических моделей. Использование языка С++ для реализации списковой структуры. Назначение и условия применения программы. Руководство для программиста и оператора.
курсовая работа , добавлен 19.03.2010
Использование основных свойств объектно-ориентированного языка программирования C ++ при написании программы по реализации списка футболистов разных амплуа. Руководство пользователя и руководство программиста. Работа со списком, программный интерфейс.
курсовая работа , добавлен 20.07.2014
Описание входной и выходной информации. Требования к комплексу технических средств и к интерфейсу конечного пользователя. Разработка форм представления входных и выходных данных. Проектирование программных модулей. Руководство пользователя и программиста.
курсовая работа , добавлен 27.06.2015
Особенности алгоритмов, критерии качества. Создание и применение программного продукта на языке Delphi. Тип операционной системы. Внутренняя структура программного продукта. Руководство пользователя и программиста, расчет себестоимости и цены программы.
дипломная работа , добавлен 12.06.2009
Delphi как программный продукт с феноменальными характеристиками. Компилятор в машинный код. Объектно-ориентированная модель программных компонентов. Масштабируемые средства для построения баз данных. Программный код.
контрольная работа , добавлен 30.07.2007
Разработка структурной схемы и интерфейса программного комплекса управления сайтом. Выбор языка программирования. Принципы тестирования программы. Разработка руководства оператора и системного программиста. Расчет сметы затрат на программный продукт.
дипломная работа , добавлен 11.06.2012
Назначение и область применения промышленных роботов. Разработка программы «Кинематическое движение» в среде Delphi для определения основных параметров кинематического движения. Описание работы и листинг программы. Руководство программиста и оператора.
курсовая работа , добавлен 17.11.2014
Техническое задание. Планы работы: первоначальный, поэтапный. Технический проект. Таблицы базы данных программы. Схема обмена данными. Тестирование программного продукта. Эксплуатационная документация. Руководство программиста. Руководство пользователя.
курсовая работа , добавлен 07.12.2007
Создание программного продукта по теме «Назначение и основные свойства палитры компонентов «Standard»», тестирующего знания студентов, в среде языка программирования Delphi. Особенности методики осуществления контроля знаний и состав тестовых заданий.
курсовая работа , добавлен 17.04.2011
Разработка программы на языке Visual Basic. Спецификация на программный модуль. Ввод, изменение и удаление данных по определенным требованиям. Руководство системного программиста, программиста и оператора. Ведение базы данных в виде таблицы Excel.
Создан 02.02.2010 9:34:31
Назначение и условия применения программ
В разделе «Назначение и условия применения программ» должны быть указаны назначение и, условия, необходимые для выполнения программы (объем, к составу и параметрам, требования к и т.п.) [из п. 2.1 ГОСТ 19.504-79]
Характеристика программы
В разделе «Характеристика программы» должно быть приведено описание основных характеристик и особенностей программы (временные характеристики, режим работы, средства контроля выполнения и самовосстанавливаемости программы и т.п.) [из п. 2.2 ГОСТ 19.504-79]
Обращение к программе
В разделе «Обращение к программе» должно быть приведено описание процедур вызова программы (способы передачи управления и параметров данных и др.) [из п. 2.3 ГОСТ 19.504-79]
Входные и выходные данные
В разделе «Входные и выходные данные» должно быть приведено описание организации используемой входной и выходной информации и, при необходимости, ее [из п. 2.4 ГОСТ 19.504-79]
Сообщения
В разделе «Сообщения» должны быть указаны тексты сообщений, выдаваемых программисту или в ходе выполнения программы, описание их содержания и действий, которые необходимо предпринять по этим сообщениям [из п. 2.5 ГОСТ 19.504-79]
Приложения
В приложении к руководству программиста могут быть приведены дополнительные материалы (примеры, иллюстрации, таблицы, графики и т.п.) [из п. 2.6 ГОСТ 19.504-79]
Руководство программиста. Пример
Пример руководства программиста по одной из ранее сданных систем
СИСТЕМА УПРАВЛЕНИЯ ДЛЯ УЧАСТКА СБОРКИ И НАСТРОЙКИ ДВДТ
АННОТАЦИЯ
В данном руководстве содержится информация, описывающая прикладное программное обеспечение для участка сборки и настройки ДВДТ – участок ДВДТ (далее по тексту – участок). Документ содержит информацию о доступе к функциям системы управления MasterScada (далее по тексту – СУ), структуре программы, методики записи и просмотра произошедших событий.
СОДЕРЖАНИЕ
1 НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ ПРОГРАММЫ 5
1.1 Назначение программы 5
1.2 Аппаратные средства 6
2 ХАРАКТЕРИСТИКА ПРОГРАММЫ 7
2.1 Структура SQL базы данных 7
2.2 Программные секции 10
2.3 Структура программного обеспечения 14
3 ОБРАЩЕНИЕ К ПРОГРАММЕ 16
4 ВХОДНЫЕ И ВЫХОДНЫЕ ДАННЫЕ 16
5 СООБЩЕНИЯ 17
ПЕРЕЧЕНЬ ТЕРМИНОВ И ОПРЕДЕЛЕНИЙ 18
ПЕРЕЧЕНЬ СОКРАЩЕНИЙ 19
ПЕРЕЧЕНЬ РИСУНКОВ 20
ПЕРЕЧЕНЬ ТАБЛИЦ 21
ПЕРЕЧЕНЬ ССЫЛОЧНЫХ ДОКУМЕНТОВ 22
ЛИСТ РЕГИСТРАЦИИ ИЗМЕНЕНИЙ 23
1 НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ ПРОГРАММЫ
1.1 Назначение программы
Стенд предназначен для испытаний определённого вида оборудования на разных участках. ПО обеспечивает настройку на следующих участках:
— настройка температуры;
— настройки давления;
— настройки скорости ветра;
— настройки влажности;
— настройки ДВДТ;
— сдачи ПСИ.
ПО реализует следующие функции:
— получение и обработка сигналов ввода-вывода с корзины ввода-вывода;
— приём и фильтрация входных дискретных сигналов от вероятного «дребезга» контактов;
— приём и обработка входных аналоговых сигналов;
— контроль выхода сигнала за допустимые границы (недостоверность сигнала);
— масштабирование аналогового сигнала;
— генерация пороговых нарушений с функцией гистерезиса;
— выдача дискретных команд на оборудование (управляющие воздействия);
— реализация алгоритмов управления системой;
— реализация алгоритмов защит;
— обмен данными со смежными системами по протоколу Modbus TCP;
— диагностика модулей контроллера на наличие ошибок, и формирование сообщений для АРМ о состоянии оборудования контроллера;
— мониторинг аварийных ситуаций оборудования системы.
ПО реализует следующие функции:
— вывод на экран видеокадра текущего состояния участка;
— отображение состояний оборудования;
— управление механизмами установки;
— ведение архива собранных событий;
— отображение аварийных ситуаций;
— ведение хронологии аварийных событий.
1.2 Аппаратные средства
В состав технических средств системы входят следующие аппаратные и программные компоненты:
— Электронный модуль давления Метран-518 предназначен для точного измерения и непрерывного преобразования значений абсолютного и избыточного давления, разрежения, давления-разрежения при поверке и калибровке различных приборов давления;
— Камера ТБК-500;
— Контроллеры PACE5000 и РАСЕ1000;
— Мультиметр Метран-514МПП
Персональный компьютер ПЭВМ
— процессор не хуже Intel i7 2,7 ГГц
— слоты расширения на материнской плате, не менее: 5 слотов 1x PCI-E 2.0, 1 слот 16x PCI-E 3.0
— память не менее 16 Гб DDR4-2133/2400
— дисковая подсистема: корзина на 2 диска, 2,5” SSD не менее 240GB (для системы и программ), 3.5” HDD SATA не менее 1 Tb (для данных);
— оптический привод DVD±RW в комплекте;
— порты: 4 x USB 3.0; 6 x USB 2.0, VGA, DVI, 1x LAN (RJ-45, Ethernet 10/100/1000), 4x RS232, 4x CAN 2.0
— блок питания, не менее 600 Вт;
— рабочая температура от +5º до +40ºС (промышленное исполнение);
— поддержка работы с двумя мониторами одновременно.
Установлено лицензионное ПО: Microsoft Windows Server 2012,
В слоты расширения ПК установлены и подключены интерфейсные платы RS 232 CAN; соединители плат должны выведены на заднюю панель ПК
В состав ПК входит: системный блок, монитор 24-27” со входами DVI и VGA, клавиатура, манипулятор «мышь»
Дополнительно: коммутатор Ethernet.
2 ХАРАКТЕРИСТИКА ПРОГРАММЫ
2.1 Структура SQL базы данных
Потребность в СУРБД Microsoft SQL Server у пользователей ПО MasterScada может возникнуть только в тех случаях, когда предполагается использовать оперативные журналы или SQL базу данных телеметрии.
SQL база данных состоит из таблиц. Поля БД — это столбцы таблицы, а записи БД — это строки таблицы. Каждая БД изначально содержит таблицы:
— CONFORMS
— CORETABLE
— EQUIPMENT
— HISTORY
— MAGS
— NEXTNUMS
— PERSONS
— REFS
— SQLTOKENS
— USERFORMS.
Таблица CORETABLE состоит из наиболее распространенных полей, которые характерны почти для любого оперативного журнала:
— RECID — уникальный идентификатор записи;
— FULLPATH — принадлежность записи конкретному журналу (путь в дереве журналов);
— DATACREATE — дата/время создания записи;
— DATE1, DATE2 — вспомогательные даты/времени общего назначения (например, обнаружения и устранения дефекта);
— OBJECT — оборудование, к которому относится запись;
— COMMENT — произвольный комментарий (например, описание дефекта);
— STATE — состояние записи (например, обнаружен/устранен).
Каждая запись имеет свой жизненный цикл, который ведется в таблице HISTORY. Там фиксируются факты создания записи (кто, когда создал, редактировал, подписывал или отзывал подпись).
На рисунке 1 представлена схема структуры базы данных, состоящей из минимального набора таблиц.
Рисунок 1 – Модель данных БД. Связи по внешнему ключу
На предприятии, как правило, ведется несколько оперативных журналов, каждый из которых может содержать подразделы (поджурналы), которые, в свою очередь, также могут содержать подразделы и т.д.
Таким образом, можно создать иерархию журналов любого уровня вложенности, что упрощает навигацию и поиск нужной информации.
Каждый журнал может обладать своей спецификой. Это означает что, кроме рассмотренных выше основных полей, в журнале могут присутствовать поля, характерные только для данного журнала.
В ПО MasterScada используется механизм таблиц расширения, т.е. таких таблиц, которые содержат дополнительные поля, характерные для определенного журнала. Такая таблица может быть создана только для журнала первого уровня главной ветви дерева журналов. Таблица расширения привязывается к журналу и ко всем его поджурналам. В таблицу расширения можно поместить поля произвольных типов и использовать ее так, как будто это одна запись данного журнала.
Часто при вводе/редактировании записей бывает удобно использовать справочники. Это такие таблицы, где размещают часто используемую однотипную информацию. Например, справочник персонала можно заполнить фамилиями сотрудников, можно создать справочники улиц, потребителей и т.д.
Любое поле журнала, относящееся к целому типу, может быть привязано к справочнику, т.е. таблице, в которой числу сопоставлена его текстовая расшифровка. В каждой записи БД присутствует поле STATE, к которому обязательно должен быть привязан справочник состояния записи.
Кроме обычных справочников, предусмотрен специальный вид справочника — справочник оборудования. Этот справочник представляет собой иерархическую структуру и отображается в виде дерева. Такой подход связан с тем, что одинаковое оборудование может располагаться на разных объектах. В данном справочнике предусмотрено хранение кодов оборудования согласно требованиям ОДУ. Справочник оборудования может быть привязан только к полю строкового типа.
Для каждого журнала могут быть созданы формы просмотра списком нескольких записей, просмотра/редактирования одной записи и печатных документов (отчет). Форма редактирования должна представлять собою максимально детализированное представление записи, именно с ее помощью (и только через нее) осуществляется редактирование записи. В случае если на данном уровне дерева какая-либо из форм не задана, берется форма из вышестоящего уровня. Все указанные формы обязательно должны быть созданы для всех журналов первого уровня! Формы и отчеты создаются в конфигураторе БД при помощи дизайнера форм и дизайнера отчетов.
2.2 Программные секции
Приложение содержит:
— конфигурацию аппаратных и программных средств;
— набор функциональных модулей, каждый из которых реализуется секциями, написанными на языке ST (структурированного текста);
— набор функциональных блоков, разработанных в рамках проекта KPC;
— базу данных переменных контроллера;
— анимационные таблицы.
В состав приложения входят следующие функциональные модули, каждый из которых содержит один или несколько программных модулей, отраженных в таблице 2.1.
Таблица 2.1 – Программные секции
Внутри секций используются следующие подпрограммы (функциональные блоки), которые приведены в таблице 2.2.
Таблица 2.2 – Функциональные блоки
Параметры сигналов блоков приведены в таблице 2.3.
Таблица 2.3 – Параметры сигналов блока
Разъём Контакт Наименование Параметры
X1 1 I вх. Токовый вход датчика температуры. I вх. не более 400 мкА.
2 Пустой вывод. Не использовать.
3 Пустой вывод. Не использовать.
4 +12В Выход напряжения питания датчика температуры 12±0,25 В относительно «Общ.12В» Ток нагрузки не более 400 мкА.
X3 1 +12В Выход напряжения питания +12±0,25 В относительно «Общ.12В» Ток нагрузки не более 400 мкА.
2 +7В Выход напряжения питания +7±0,25 В относительно «Общ.» Ток нагрузки не более 300 мА.
3 -7В Выход напряжения питания -7±0,25 В относительно «Общ.» Ток нагрузки не более 50 мА.
4 Общ. Нулевой потенциал блока.
5 Общ. Нулевой потенциал блока.
6 Общ. Нулевой потенциал блока.
7 CAN_L Линия цифровой сети передачи данных CAN-L. Параметры согласно ISO11898
8 CAN_H Линия цифровой сети передачи данных CAN-Н. Параметры согласно ISO11898
X2 1 GND Нулевой потенциал блока.
2 RESET Сигнал интерфейса JTAG.
3 TMS Сигнал интерфейса JTAG.
4 TCK Сигнал интерфейса JTAG.
5 TDI Сигнал интерфейса JTAG.
6 TRST Сигнал интерфейса JTAG.
7
8 3,3В Напряжение питания 3,3В. Ток нагрузки не более 10 мА.
2.3 Структура программного обеспечения
Структура ПО представлена на рисунке 2.
Рисунок 2 – Структура ПО
Приложение содержит:
— таблицы настроечных параметров системных функций панели;
— набор скриптов, для реализации программных функций, написанными на языке JAVA;
— перечень видеокадров системы;
— перечень всплывающих окон в системе
— базу данных переменных тэгов панели.
В состав приложения входят следующие скрипты, каждый из которых содержит один или несколько программных модулей, отраженных в таблице 2.4.
Таблица 2.4 – Перечень скриптов
3 ОБРАЩЕНИЕ К ПРОГРАММЕ
Программа при работе на объекте сконфигурирована на автоматический запуск при включении стенда. Состояние программного обеспечения отображается на экране монитора и светодиодных индикаторах приборов стенда.
Настройка параметров прикладного программного обеспечения операторской панели настраивается с ПК.
При этом настраиваются:
— таймеры нарушений работы стенда;
— уставки времени дискретных выходных сигналов;
— шкала входного аналогового сигнала температуры;
— шкала входного аналогового сигнала давления;
— шкала входного аналогового сигнала влажности;
— шкала входного аналогового сигнала скорости ветра;
— время цикла приложения;
— IP и Modbus адреса приборов стенда.
4 ВХОДНЫЕ И ВЫХОДНЫЕ ДАННЫЕ
Входными данными системы является информация, поступающая от объекта управления в систему через устройства связи с объектом (распределённой периферии), а также команды, вводимые оператором.
Выходными данными системы является информация, передаваемая на объект управления (стенд) из ПК через устройство связи с объектом. Информация выводится в АРМ оператора в виде экранных форм.
5 СООБЩЕНИЯ
Сообщения, передаваемые по интерфейсу АРМ-стенд, приведены в таблице 5.1.
Таблица 5.1 – Перечень событий, выводимых в журнале событий
№ п/п Наименования события
1 Выбрана вкладка блока №1
2 Выбрана вкладка блока №2
3 Выбрана вкладка блока №3
4 Выбрана вкладка блока №4
5 Индикатор питание +7 В
6 Индикатор питание -7 В
7 Индикатор питание +12 В
8 ПК подключен к стенду
9 Нажата кнопка включения блока №1
10 Нажата кнопка включения блока №2
11 Нажата кнопка включения блока №3
12 Нажата кнопка включения блока №4
13 Индикатор включения блока №1
14 Индикатор включения блока №2
15 Индикатор включения блока №3
16 Индикатор включения блока №4
17 Нажата кнопка включения камеры
18 Индикатор включения камеры
19 Резерв
20 Повышенное напряжение между фазами
21 Индикатор отключения камеры
22 Команда на включение камеры
23 Команда на задание скорости ветра
24 Команда на отключение блока №1
25 Команда на отключение блока №2
26 Команда на отключение блока №3
27 Команда на отключение блока №4
ПЕРЕЧЕНЬ ТЕРМИНОВ И ОПРЕДЕЛЕНИЙ
Автоматизированная система (АС) – система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.
База данных (БД) – представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ).
Система управления базами данных (СУБД) – совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием БД.
Программное обеспечение АС – совокупность программ на носителях данных и программных документов, предназначенная для отладки, функционирования и проверки работоспособности системы.
Прикладная программа – Программа, предназначенная для решения задачи или класса задач в определенной области применения системы обработки информации.
MasterScada – программный пакет для проектирования систем диспетчерского управления и сбора данных (Scada).
SQL – язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей системой управления базами данных,
ПЕРЕЧЕНЬ СОКРАЩЕНИЙ
SCADA (Supervisory Control and Data Acquisition System) – система диспетчерского управления и сбора данных
АС – автоматизированная система;
БД – база данных;
ПК – персональный компьютер;
ПО – программное обеспечение;
СУ – система управления;
СУБД – система управления базами данных.
ПЕРЕЧЕНЬ РИСУНКОВ
Рисунок 1 – Модель данных БД. Связи по внешнему ключу 8
Рисунок 2 – Структура ПО 13
ПЕРЕЧЕНЬ ТАБЛИЦ
Таблица 2.1 – Программные секции 10
Таблица 2.2 – Функциональные блоки 12
Таблица 2.3 – Параметры сигналов блока 12
Таблица 2.4 – Перечень скриптов 15
Таблица 5.1 – Перечень событий, выводимых в журнале событий 17
ПЕРЕЧЕНЬ ССЫЛОЧНЫХ ДОКУМЕНТОВ
№ п/п Нормативный документ
1 ГОСТ 19781-90 ЕСПД. Термины и определения.
2 ГОСТ 19.105-78. ЕСПД. Общие требования к программным документам.
3 ГОСТ 19.402-78. ЕСПД. Описание программы.
4 ГОСТ 19.504-79. ЕСПД. Руководство программиста. Требования к содержанию и оформлению.
5 ГОСТ 19.701-90. ЕСПД. Схемы алгоритмов, программ, данных и систем. Обозначения условные и правила выполнения
ЛИСТ РЕГИСТРАЦИИ ИЗМЕНЕНИЙ
#Руководствопрограммиста, #описание, #ПЛК, #ПТС, #интерфейс
Руководство
программиста должно содержать разделы:
-
Назначение и
условия применения программы. -
Характеристики
программы. -
Обращение к
программе. -
Входные и выходные
данные. -
Сообщения.
При описании
назначения
и условий применения программы необходимо
указать назначение и функции, выполняемые
программой; условия, необходимые для
выполнения программы: объем оперативной
памяти, требования к составу и параметрам
периферийных устройств; требования к
ПО и т.д.
В
разделе Характеристики
программы необходимо
привести описание
основных характеристик и особенностей
программы: временных
характеристик, режима работы, средств
контроля правильности
выполнения и самовосстанавливаемости
программы и т.д.
Раздел
Обращение
к программе представляет
собой описание процедур
вызова программы (способов передачи
управления и параметров данных и др.).
Раздел
Входные
и выходные данные должен
содержать описание
организации используемой входной и
выходной информации и при необходимости
ее кодирования.
При описании
сообщений
необходимо
привести тексты сообщений, выдаваемых
программисту или оператору в ходе
выполнения программы, описание их
содержания и действия, которые необходимо
предпринять по этим сообщениям.
Гост 19.505-79 еспд. Руководство оператора. Требования к содержанию и оформлению
Руководство
оператора должно включать:
-
Назначение
программы. -
Условия выполнения
программы. -
Выполнение
программы. -
Сообщения оператору.
При
описании назначений
программы необходимо
указать сведения
о назначении программы и информацию,
достаточную для понимания функций
программы и ее эксплуатации.
Условия выполнения
программы должны
содержать условия, необходимые для
выполнения программы: минимальный и/или
максимальный состав аппаратурных и
программных средств.
В
разделе
Выполнение
программы необходимо
указать последовательность
действий оператора, обеспечивающих
загрузку, запуск, выполнение и завершение
программы; привести описание функций,
формата и возможных вариантов команд,
с помощью которых оператор осуществляет
загрузку и управляет выполнением
программы, а также ответы программы на
эти команды.
При описании
сообщений
оператору приводят
тексты сообщений, выдаваемых в ходе
выполнения программы, описание их
содержания и соответствующие действия
оператора: действия в случае сбоя,
возможности повторного запуска программы
и т.д.
Гост 19.506-79 еспд. Описание языка. Требования к содержанию и оформлению
При описании языка
необходимо указать:
-
Общие сведения.
-
Элементы языка.
Кроме того,
допускается вводить дополнительные
разделы.
-
Способы
структурирования программы. -
Средства обмена
данными. -
Встроенные
элементы. -
Средства отладки
программы.
Общие сведения
должны
содержать назначение и описание общих
характеристик языка, его возможностей,
основных областей применения и др.
В разделе Элементы
языка приводят
описание синтаксиса и семантики базовых
и составных элементов языка.
Раздел
Способы
структурирования программы должен
описывать способы вызова процедур
передачи управления и другие элементы
структурирования программы.
Раздел
Средства
обмена данными должен
содержать описание языковых
средств обмена данными (например, средств
ввода-вывода,
средств внутреннего обмена данными и
т.д.).
В разделе Встроенные
элементы описываются
встроенные в
язык элементы: функции, классы и т.д. и
правила их использования.
При
описании средств
отладки необходимо
привести
описание имеющихся в языке средств
отладки программ, семантики этих средств,
дать рекомендации по их применению.
ГОСТ
Р ИСО/МЭК 9294-93. Информационная технология.
Руководство
по управлению документированием
программного обеспечения.
Стандарт
полностью соответствует международному
стандарту ИСО/МЭК 9294:1990 и устанавливает
рекомендации по эффективному управлению
документированием ПС для руководителей,
отвечающих за их создание. Целью стандарта
является оказание помощи в определении
стратегии документирования ПС; выборе
стандартов по документированию; выборе
процедур документирования; определении
необходимых ресурсов; составлении
планов документирования.
ГОСТ
Р ИСО/МЭК 9126-93. Информационная технология.
Оценка
программной продукции. Характеристики
качества и руководства
по их применению. Стандарт
полностью соответствует международному
стандарту ИСО/МЭК 9126:1991. В его контексте
под характеристикой качества понимается
«набор свойств (атрибутов) программной
продукции, по которым ее качество
описывается и оценивается». Стандарт
определяет шесть комплексных
характеристик, которые с минимальным
дублированием описывают
качество ПС (ПО, программной продукции):
-
функциональные
возможности; -
надежность;
-
практичность;
-
эффективность;
-
сопровождаемость;
-
мобильность.
Эти характеристики
образуют основу для дальнейшего уточнения
и описания качества ПС.
ГОСТ
Р ИСО 9127-94. Системы обработки информации.
Документация
пользователя и информация на упаковке
для потребительских
программных пакетов. Стандарт
полностью соответствует
международному стандарту ИСО 9127:1989. В
контексте настоящего стандарта под
потребительским программным пакетом
(ПП) понимается «программная продукция,
спроектированная и продаваемая для
выполнения определенных функций;
программа и соответствующая ей
документация, упакованные для продажи
как единое целое». Под документацией
пользователя понимается документация,
которая обеспечивает конечного
пользователя информацией по установке
и эксплуатации ПП. Под информацией на
упаковке понимают информацию,
воспроизводимую на внешней
упаковке ПП. Ее целью является
предоставление потенциальным
покупателям первичных сведений о ПП.
ГОСТ
Р ИСО/МЭК 8631-94. Информационная технология.
Программные
конструктивы и условные обозначения
для их представления.
Описывает
представление процедурных алгоритмов.
Как
уже говорилось, пока нет лучшего, можно
извлекать пользу и
из тех стандартов ЕСПД, которые приняты
еще около 20 лет назад. Но всем ясно, что
ориентироваться надо на современные
стандарты.
Практики используют
еще один путь: сами переводят и используют
в своих проектах современные стандарты
на организацию ЖЦ ПС и их документирование.
Но этот путь страдает как минимум
тем недостатком, что разные переводы и
адаптации стандартов,
сделанные разными разработчиками и
заказчиками, будут отличаться массой
деталей. Эти отличия неизбежно касаются
не только наименований, но и их
содержательных определений, вводимых
и используемых в стандартах. Таким
образом, на этом пути неизбежно постоянное
возникновение путаницы, а это прямо
противоположно целям не только стандартов,
но и любых грамотных методических
документов [59].
ГОСТ
Р ИСО/МЭК 12119:1994. Информационная технология.
Пакеты
программных средств. Требования к
качеству
и испытания. В
этом стандарте установлены требования
к качеству пакетов программ и инструкции
по их испытаниям
на соответствие заданным требованиям.
Понятие «пакет программных средств»
фактически отождествляется
с более общим понятием «программный
продукт», рассматриваемым
как совокупность программ, процедур и
правил, поставляемых
нескольким пользователям для общего
применения или
функционирования. Каждый пакет программ
должен иметь описание
продукта и пользовательскую документацию.
Рассмотрим более
подробно содержание данного стандарта.
Стандарт определяет
требования к описанию
продукта, к
пользовательской
документации, программам и данным,
входящим
в пакет
программ, и испытаниям пакетов программ.
Предполагается,
что документ «Описание продукта» должен
помочь пользователю или потенциальному
покупателю в оценке того, подходит ли
для них данный продукт, а пользовательская
документация
должна содержать всю информацию,
необходимую для
применения продукта.
В контексте данного
стандарта требования к качеству продукта
рассматриваются с точки зрения описания
реальных свойств продукта
в «Описании продукта» и пользовательской
документации. Требования к программам
и данным в основном сводятся к утверждению
необходимости соответствия реальных
свойств продукта
свойствам, объявленным в документации.
В связи с этим документ
формально не может рассматриваться как
стандарт требований. Несмотря на эту
ограниченность, стандарт может оказаться
весьма полезным при определении исходных
требований к продукту:
-
требования,
согласно которому каждый пакет программ
должен содержать
описание продукта и документацию
пользователя; -
требования
к описанию продукта. В частности,
требования, согласно
которому описание продукта должно
содержать конкретную информацию, а все
приводимые в нем формулировки должны
быть проверяемыми (контролируемыми) и
корректными; -
требования к
документации пользователя; -
требования к любым
программам и данным, входящим в состав
пакета программ.
Описание
продукта. Описание
продукта (product
description):
документ,
определяющий свойства пакета программ,
основным назначением которого является
оказание помощи потенциальным покупателям
в оценке пригодности для них данного
продукта до его приобретения.
Каждый
пакет
программ должен содержать описание
продукта.
Оно должно являться частью документации
пакета для данного
продукта и содержать информацию по
документации пользователя,
программам и соответствующим данным.
Основным назначением
описания продукта является помощь
пользователю и потенциальному покупателю
при оценке ими пригодности продукта
для их нужд. Для обеспечения этого
описание продукта также должно содержать
соответствующую торговую информацию.
Описывая любой
программный продукт, необходимо
придерживаться
установленных требований к содержанию.
В связи с этим можно
выстроить определенную иерархию
материала, подлежащего описанию:
-
Общие требования
к содержанию. -
Обозначения и
указания. -
Функциональные
возможности. -
Надежность.
-
Практичность.
-
Эффективность.
-
Сопровождаемость
и мобильность.
Описание продукта
должно быть доступным для человека,
заинтересованного в данном продукте,
и удовлетворять общим
требованиям к содержанию:
-
быть достаточно
понятным, полным и простым при изучении,
чтобы обеспечить помощь потенциальным
покупателям при оценке ими пригодности
данного продукта для их нужд до его
покупки; -
быть внутренне
непротиворечивым. Каждый термин должен
иметь один и тот же смысл по всему
документу; -
формулировки
должны быть проверяемыми и корректными.
При описании
продукта необходимо приводить следующие
указания
и
обозначения:
-
При обозначении
одного или нескольких продуктов в
рамках одного пакета необходимо хотя
бы включать наименование продукта и
обозначение его версии или даты выпуска.
-
Должны быть
включены наименование и адрес поставщика.
-
Должны быть
определены целевые рабочие задачи,
которые могут быть выполнены данным
продуктом. -
Из описания
продукта могут быть даны ссылки на
нормативные документы, которым
удовлетворяет данный продукт, в этом
случае должны быть указаны соответствующие
редакции данных документов.
5. Должна
быть определена система (технические
и программные
средства и их конфигурация), необходимая
для ввода продукта
в эксплуатацию, включая наименования
изготовителейи обозначения типов всех
ее частей, например:
-
процессоры, включая
сопроцессоры; -
объем основной
(оперативной) памяти; -
типы и объемы
(памяти) периферийных запоминающих
устройств; -
расширяющие платы;
-
оборудование
ввода и вывода; -
сетевое оборудование;
-
системные и прочие
программные средства.
-
Должны
быть определены соответствующие
интерфейсы или продукты,
если в описании продукта имеются ссылки
на интерфейсы с другими продуктами. -
Должен быть
определен каждый физический компонент
поставляемого продукта, в частности,
все печатные документы и все носители
данных. -
Должен
быть установлен вид поставляемых
программ, например
исходные программы, объектные (рабочие)
модули или загрузочные модули. -
Должно быть
указано, будет ли инсталляция продукта
проводиться пользователем или нет. -
Должно быть
указано, будет или не будет предлагаться
поддержка при эксплуатации продукта. -
Должно быть
указано, будет или не будет предлагаться
сопровождение продукта. Если сопровождение
предусматривается, то должно быть
установлено, что оно подразумевает.
При описании
функциональных
возможностей необходимо
отразить:
1.
Обзор
функций.
В описании продукта
должен быть приведен обзор функций
продукта,
вызываемых пользователем, необходимых
для них данных
и предоставляемых средств. Для каждой
функции (особенно для ее опции или
варианта) должно быть четко установлено,
является ли она частью:
• продукта;
-
расширения
продукта, полностью приведенного в
описании продукта; -
расширения
продукта, на которое дана ссылка в
описании продукта; -
негарантируемого
(необязательного) приложения.
2. Граничные
значения.
Если использование
продукта ограничено конкретными
граничными значениями для продукта,
они должны быть указаны в описании
продукта. Например:
-
минимальные или
максимальные значения; -
длины ключей;
-
максимальное
число записей в файле; -
максимальное
число критериев поиска; -
минимальный объем
выборки.
В случае, когда
невозможно определить фиксированные
граничные значения (например, когда они
зависят от типа приложения или от
исходных данных), на них должны быть
наложены соответствующие ограничения.
Могут быть приведены допустимые
комбинации значений и даны ссылки на
более конкретную информацию из
документации пользователя.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
Подборка по базе: организация как управляемая система.docx, Бюджетная система РФ Контрольная работа.doc, ЛПР МДК 05. 01 Проектирование и дизайн информационных систем.doc, «Внедрение цифровой информационной системы ФГИС «Моя школа» как , Сигнальные системы Павлова..docx, Реферат_уровневая система образования в РФ.docx, Теория информационных процессов и систем копия.pdf, Практическая работа № 2 (Часть 1) Раздел программы_ 2.1.4. Объек, Оценка системы материальной и нематериальной мотивации туристиче, Россия в системе международных отношений.docx
8. РАБОЧАЯ ДОКУМЕНТАЦИЯ
В состав рабочей, или иначе эксплуатационной, документации входят руководство пользователя, руководство оператора, руководство администратора, руководство системного администратора, руководство программиста, руководство системного программиста.
8.1. Руководство пользователя
Основной целью руководства пользователя является обеспечение пользователя необходимой информацией для самостоятельной работы с программой или автоматизированной системой. Поэтому руководство пользователя должно отвечать на вопросы:
что это за программа (система)?
что может программа (система)?
что необходимо для обеспечения корректного функционирования программы (системы)?
что делать в случае отказа системы?
При составлении наиболее подробного руководства пользователя можно придерживаться следующей структуры:
1. Введение
Данный раздел должен предоставлять пользователю общую информацию о программе (системе). В нем указывают:
область применения;
краткое описание возможностей;
уровень подготовки пользователя.
51
2. Перечень эксплуатационной документации
В данном разделе перечисляется документация, которая позволит пользователю избежать определенного рода ошибок.
3. Назначение и условия применения
Раздел подразделяет основную задачу программы (системы) на подзадачи и описывает каждую из них. В нем указывают:
виды деятельности, функции, для автоматизации которых предназначено данное средство автоматизации;
условия, при соблюдении (выполнении, наступлении) которых обеспечивается применение средства автоматизации в соответствии с назначением (например, вид ЭВМ и конфигурация технических средств, операционная среда и общесистемные программные средства, входная информация, носители данных, база данных, требования к подготовке специалистов и т. п.).
4. Подготовка к работе
Данный раздел должен содержать пошаговую инструкцию для запуска программы (системы). К этапу подготовки системы к работе можно отнести установку дополнительных приложений, идентификацию, аутентификацию. В данном разделе указывают:
состав и содержание дистрибутивного носителя данных;
порядок загрузки данных и программ.
5. Проверка работоспособности
В разделе описываются показатели, по которым можно определить, что программное обеспечение работает нестабильно.
6. Описание операций
Это основной раздел, который содержит пошаговую инструкцию для выполнения того или иного действия пользователем. Если работа
52 автоматизированной системы затрагивает целый бизнес-процесс, то в руководстве пользователя перед описанием операций целесообразно предоставить информацию о данном процессе, его назначении и участниках. Подобное решение позволяет человеку четко представить свою роль в данном процессе и те функции, которые реализованы для него в системе. Далее в руководстве пользователя следует представить описание функций, разбитых на отдельные операции.
Необходимо выделить подразделы, описывающие функции данного процесса, и действия, которые необходимо совершить для их выполнения:
описание всех выполняемых функций, задач, комплексов задач, процедур;
описание операций технологического процесса обработки данных, необходимых для выполнения функций, задач, процедур.
7. Аварийные ситуации
В разделе описываются действия в случае длительных отказов технических средств, обнаружении несанкционированного вмешательства в данные, действия по восстановлению программ или данных.
8.2. Руководство оператора
Нормативной базой для составления данного документа может являться ГОСТ 19.505-79 «ЕСПД. Руководство оператора. Требования к содержанию и оформлению», в котором выделяются следующие разделы:
назначение программы (сведения о назначении программы и информация, достаточная для понимания функций программы и ее эксплуатации);
53
условия выполнения программы (минимальный и/или максимальный состав аппаратурных и программных средств и т. д.);
выполнение программы
(последовательность действий оператора, обеспечивающих загрузку, запуск, выполнение и завершение программы, описание функций, формата и возможных вариантов команд, с помощью которых оператор осуществляет загрузку и управляет выполнением программы, а также ответы программы на эти команды);
сообщения оператору (тексты сообщений, выдаваемых в ходе выполнения программы, описание их содержания и соответствующие действия оператора в случае сбоя, возможности повторного запуска программы и т. п.).
В зависимости от особенностей документа допускается объединять отдельные разделы или вводить новые. Допускается содержание разделов иллюстрировать поясняющими примерами, таблицами, схемами, графиками.
В общем случае руководство оператора отличается от руководства пользователя. В руководстве оператора все процессы, выполняемые программным обеспечением, рассматриваются с технической точки зрения. Исходя из этого, можно представить альтернативную структуру данного руководства:
1. Установка на сервер
В разделе описывается процесс установки программного обеспечения на сервер. Пошаговая инструкция дает точные указания, каким образом необходимо выполнить установку, в зависимости от технического состояния сервера.
54
2. Установка локальная
В разделе описывается процесс настройки компьютеров, использующих программное приложение, также даются рекомендации по оптимизации настройки рабочих станций, чтобы улучшить процесс взаимодействия сервера и компьютеров пользователей.
3. Администрирование пользователей
В разделе подробно описывается процесс администрирования учетных записей пользователей программного обеспечения.
Подробная инструкция описывает все ситуации, которые могут возникнуть при управлении пользователями. Например, можно централизованно завершать все активные соединения с информационной базой и устанавливать блокировку новых соединений на определенный период времени. Такая возможность полезна при выполнении различных административных действий с информационной базой.
4. Информационная база
В разделе рассматриваются вопросы администрирования, сохранения, переноса базы данных. Описаны рекомендации по настройке базы данных. Например, рассматривается ситуация резервного копирования. Резервное копирование может выполняться как в автоматическом режиме, так и в ручном. Для автоматического режима предварительно необходимо выполнить настройки. В любой момент можно восстановить данные информационной базы из созданной ранее резервной копии.
5. Технические неполадки
Этот раздел содержит информацию о возможных технических проблемах, которые могут возникнуть в процессе эксплуатации программного обеспечения.
Рассматриваются проблемы, возникающие в результате некорректной работы оборудования, а
55 также ситуации, возникающие в результате некорректного использования функций программного обеспечения.
6. Программный код
В разделе подробно описывается структура программного кода.
Если в процессе использования программного обеспечения возникают ошибки или потребуется доработка, то для этого необходимо знать программный код. Указываются особенности программного кода, создающие затруднения в процессе доработки. Раздел является очень важным, так как может потребоваться добавить, удалить или изменить определенные функции программного обеспечения.
8.3. Руководство администратора
Обычно администратор считается пользователем системы, при этом он наделен как особыми обязанностями, так и необходимыми для их выполнения привилегиями. По методике и стилю изложения руководство администратора похоже на руководство пользователя.
При этом, как правило, описание в нем строится от задач, а не от функций.
Работа администратора многопользовательской системы, как правило, заключается в управлении учетными записями других пользователей, предоставлении им полномочий на доступ к данным и выполнение операций, а также в исправлении сделанных ими ошибок.
Например, бывают автоматизированные системы, в которых вводить и редактировать данные может любой пользователь, а удалять – только администратор. Кроме того, администратор может заниматься ведением нормативно-справочной информации, загрузкой и выгрузкой данных, открытием и закрытием расчетных периодов и т. п. С этой точки зрения руководство администратора является системным документом и приобретает смысл только в условиях конкретной системы с живыми пользователями.
56
Системы часто создаются на основе тиражируемых программных продуктов или аппаратно-программных комплексов. В составе таких решений нередко поставляется программный компонент под названием «Администратор», предназначенный для управления системой после ее развертывания.
Структура руководства администратора существенным образом зависит от того, как устроена система, и какого обслуживания она требует.
Типичная структура руководства администратора системы следующая:
1. Назначение системы
2. Принципы функционирования системы
3. Обязанности и задачи администратора
4. Обслуживание системы
настройка параметров работы системы;
ведение нормативно-справочной информации;
учетные записи пользователей и управление ими;
назначение пользователям прав доступа;
загрузка и выгрузка данных.
5. Проблемы в работе системы и способы их решения
Руководство по административному модулю программного или программно-аппаратного комплекса содержит примерно те же сведения, но в более общем виде. Например, в нем должно быть объяснено, как создать учетную запись пользователя, но не может быть указано, когда это следует делать. Такая конкретика возникает только при внедрении продукта в некотором конкретном месте и отражается в технологических инструкциях или регламентах.
57
Структура руководства по административному модулю программного или аппаратно-программного комплекса может иметь следующий вид:
1. Общие сведения о комплексе
2. Функционирование комплекса в рамках системы
(рассматриваются несколько наиболее типичных случаев применения комплекса и перечисляются основные обязанности администратора в каждом из них)
3. Интерфейс пользователя административного модуля
4. Задачи по обслуживанию
настройка параметров работы системы;
ведение нормативно-справочной информации;
учетные записи пользователей и управление ими;
назначение пользователям прав доступа;
загрузка и выгрузка данных.
5. Типичные проблемы в работе и способы их решения
Руководство администратора не следует путать с руководством системного администратора. Первый документ говорит о том, как организовать и поддерживать целевое применение системы, второй – как обеспечить ее техническую работоспособность.
8.4. Руководство системного администратора
Руководство системного администратора – вспомогательный документ для прикладных программных продуктов и основной для серверных и системных, не имеющих непосредственных пользователей.
В случае небольших «монолитных» программ руководство системного администратора может оказаться документом небольшим
58 по объему и простым по структуре. Руководство системного администратора на программный или аппаратно-программный комплекс, как правило, ощутимо сложнее, поскольку в нем приходится описывать каждый компонент по отдельности и способы их интеграции как друг с другом, так и со сторонним программным обеспечением: серверами баз данных, почтовыми серверами, антивирусами, средствами шифрования и пр.
В руководстве системного администратора должны быть изложены:
назначение и область применения программы (или комплекса);
состав программы, основные принципы ее функционирования;
комплект поставки (если он не указан в отдельном документе);
системные требования для программы или ее компонентов;
предпочтительная очередность установки компонентов;
процедура установки программы или каждого ее компонента;
порядок обязательной первоначальной настройки программы;
способы интеграции установленных копий компонентов между собой;
интеграция программы со сторонним ПО, например, с сервером базы данных;
способы и периодичность контроля правильности работы программы;
порядок текущего обслуживания работающих копий программы;
59
порядок решения всевозможных вспомогательных задач;
аварийные ситуации и способы их устранения.
Кроме того, в руководстве системного администратора могут быть описаны:
пользовательский интерфейс административной консоли;
утилиты командной строки и синтаксис их запуска;
конфигурационные файлы и правила их написания;
язык для составления управляющих скриптов.
Все зависит от того, какие средства для установки и настройки программы реализовали ее разработчики, какие именно инструменты есть у системного администратора.
Методика изложения материала в руководстве системного администратора сильно зависит от того, каким образом программой можно управлять. Если большинство задач решается через административную консоль с графическим интерфейсом, то документ будет больше похож на руководство пользователя или руководство администратора. Если системному администратору придется составлять конфигурационные файлы и писать скрипты, документ будет ближе к руководству программиста.
Приблизительная структура руководства системного администратора следующая:
1. Общие сведения о программе (комплексе)
2. Архитектура и принципы функционирования
3. Системные требования
4. Установка программы (комплекса)
5. Административная консоль и работа с ней
60
6. Файл конфигурации. Составление и правка
7. Обязательная
начальная
настройка
программы
(комплекса)
8. Проверка правильности функционирования программы
(комплекса)
9. Мероприятия по текущему обслуживанию программы
(комплекса)
10. Оптимизация работы программы (комплекса)
11. Аварийные ситуации и способы их устранения
Объем и особенности изложения информации в руководстве системного администратора зависят от используемых технических средств (ПК, серверных комплексов, планшетов, периферийных устройств и т. д.), применяемого программного обеспечения и решаемых с его помощью конкретных задач.
8.5. Руководство программиста
Программист – это специалист, который занимается разработкой алгоритмов и компьютерных программ на основе специальных математических моделей. Прикладные программисты занимаются в основном разработкой программного обеспечения прикладного характера, а также в их обязанности входит адаптация уже существующих программ под нужды отдельно взятой организации или пользователя.
Нормативной базой для составления данного документа может являться ГОСТ 19.504-79 «ЕСПД. Руководство программиста.
Требования к содержанию и оформлению», в котором выделяются следующие разделы:
61
назначение и условия применения программы (назначение и функции, выполняемые программой, объем оперативной памяти, требования к составу и параметрам периферийных устройств, требования к программному обеспечению и т. п.);
характеристики программы (временные характеристики, режим работы, средства контроля правильности выполнения и самовосстанавливаемости программы и т. п.);
обращение к программе (описание процедур вызова программы, способы передачи управления и параметров данных и др.);
входные и выходные данные (описание организации используемой входной и выходной информации и, при необходимости, ее кодирования);
сообщения (тексты сообщений, выдаваемых программисту или оператору в ходе выполнения программы, описание их содержания и действия, которые необходимо предпринять по этим сообщениям).
В зависимости от особенностей документа допускается объединять отдельные разделы или вводить новые. В приложении к руководству программиста могут быть приведены дополнительные материалы (примеры, иллюстрации, таблицы, графики и т. п.).
8.6. Руководство системного программиста
Системный программист – это разработчик операционных систем, программных комплексов, обеспечивающих слаженную работу компонентов компьютера, который практически не занимается прикладными программами. Системный программист выстраивает многоуровневую структуру, которая объединяет отдельные компоненты
(работу процессора, сетевого оборудования,
62 оперативную память, выполнение прикладных программ и пр.) в модули, а модули – в компьютерную сеть.
Нормативной базой для составления данного документа может являться ГОСТ 19.503-79 «ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению», в котором выделяются следующие разделы:
общие сведения о программе (назначение и функции программы и сведения о технических и программных средствах, обеспечивающих выполнение данной программы);
структура программы (сведения о структуре программы, ее составных частях, о связях между составными частями и о связях с другими программами);
настройка программы (описание действий по настройке программы на состав технических средств, выбор функций и др.);
проверка программы
(описание способов проверки, позволяющих дать общее заключение о работоспособности программы: контрольные примеры, методы прогона, результаты);
дополнительные возможности (описание дополнительных разделов функциональных возможностей программы и способов их выбора);
сообщения системному программисту (тексты сообщений, выдаваемых в ходе выполнения настройки, проверки программы, а также в ходе выполнения программы, описание их содержания и действий, которые необходимо предпринять по этим сообщениям).
63
В зависимости от особенностей документа допускается объединять отдельные разделы или вводить новые. В приложении к руководству системного программиста могут быть приведены дополнительные материалы (примеры, иллюстрации, таблицы, графики и т. п.).
Вопросы для самоконтроля:
1. Для чего необходимо руководство пользователя?
2. Чем руководство оператора отличается от руководства пользователя?
3. Что включает в себя руководство программиста?
Аннотация. В данной статье рассмотрены особенности разработки руководства пользователя для программного обеспечения «Зарплата и кадры». Автором изучены назначение и структура руководства пользователя.
В современном мире программное обеспечение отличается высоким уровнем функциональности и гибкости. Таким образом, чтобы успешно эксплуатировать программное обеспечение, пользователь должен иметь исчерпывающее описание возможностей используемого программного продукта. Функцию необходимого источника знаний, о программном обеспечении, выполняет документ «Руководство пользователя».
После разработки программы разработчик обязан написать документ «Руководство пользователя», который относится к пакету эксплуатационной документации. Часто у разработчиков возникают проблемы с его разработкой. В статье предлагается структура «Руководства пользователя» и описывается детально содержание данного документа.
Основная цель документа «Руководство пользователя» заключается в обеспечении пользователя необходимой информацией для самостоятельной работы с программой или автоматизированной системой. Документ должен отвечать на следующие вопросы: назначение программы, её возможности; что необходимо для обеспечения ее корректного функционирования и, что делать в случае отказа системы [1].
В статье приводится пример структуры «Руководства пользователя» для программного обеспечения «Зарплата и кадры», используемого в Инновационном Евразийском университете (ИнЕУ).
«Руководство пользователя» должно состоять из двух частей:
- руководство пользователя;
- руководство оператора.
Структура руководства пользователя содержит:
- Введение. Данный раздел должен предоставлять пользователю общую информацию о приложении. Введение должно состоять из следующих подразделов:
- Область применения. В подразделе описывается список задач, для которых предназначается программное обеспечение. Программное обеспечение «Зарплата и кадры» предназначено для учета кадров и расчета заработной платы сотрудникам ИнЕУ.
- Описание возможностей. В подразделе описываются основные возможности, которые предоставляет программное обеспечение. Программное обеспечение «Зарплата и кадры» включает в себя такие функции как прием сотрудника, оформление отпуска сотрудника, начисление заработной платы, удержание налогов и многие другие.
- Уровень подготовки пользователя. Подраздел содержит в себе информацию о знаниях и навыках, которыми должен обладать пользователь, чтобы работать с приложением, используя весь его потенциал. Например, сотрудники, работающие с программным обеспечением «Зарплата и кадры», обязаны обладать знаниями необходимыми для бухгалтерского расчета заработной платы, а также иметь навыки работы на компьютере.
- Перечень эксплуатационной документации. В подразделе перечислена документация, которая позволит пользователю избежать определенного рода ошибок. Пользователям программного обеспечения «Зарплата и кадры» предоставлен список литературы, которая позволит им повысить свои навыки работы на компьютере.
- Назначение и условия применения. Раздел подразделяет основную задачу приложения на подзадачи и описывает каждую из них.
- Виды деятельности и функции. В этом подразделе описываются функции, для автоматизации которых предназначена программа.
- Условия применения. В подразделе описываются условия, при которых обеспечивается полноценное применение программного обеспечения. В качестве таких условий могут выступать требования к аппаратному обеспечению, на котором будет использоваться программное обеспечение, и квалификация сотрудников, которые будут работать с описываемым программным продуктом. Например, для корректной работы программного обеспечения «Зарплата и кадры» рекомендовано не выполнять на компьютере параллельно других ресурсоемких задач [2].
- Подготовка к работе. Данный раздел должен содержать пошаговую инструкцию для запуска приложения. К этапу подготовки системы к работе можно отнести установку дополнительных приложений, идентификацию, аутентификацию. Программное обеспечение «Зарплата и кадры» является многопользовательским, следовательно, каждый пользователь несет ответственность за обрабатываемые и хранимые данные.
- Состав и содержание дистрибутивного носителя данных. В подразделе описываются все файлы, входящие в дистрибутив программного обеспечения.
- Порядок загрузки данных и программ. Подраздел описывает корректный порядок запуска программного обеспечения, чтобы предотвратить нестабильность в работе приложения, и, как следствие, избежать потери данных.
- Проверка работоспособности. В подразделе описываются показатели, по которым можно определить, что программное обеспечение работает нестабильно. Процесс проверки программного обеспечения «Зарплата и кадры» требует определенного промежутка времени, так как необходимо протестировать большое количество различных функций при различных условиях.
- Описание операций. Это основной раздел, который содержит пошаговую инструкцию для выполнения того или иного действия пользователем. Если работа автоматизированной системы затрагивает целый бизнес-процесс, то в руководстве пользователя перед описанием операций целесообразно предоставить информацию о данном процессе, его назначении и участниках. Подобное решение позволяет человеку четко представить свою роль в данном процессе и те функции, которые реализованы для него в системе. Далее в руководстве пользователя следует представить описание функций, разбитых на отдельные операции. Необходимо выделить подразделы, описывающие функции данного процесса, и действия, которые необходимо совершить для их выполнения.
- Описание всех выполняемых функций, задач, комплексов задач, процедур. В подразделе производится подробное описание каждого процесса, выполняемого программным обеспечением.
- Описание операций технологического процесса обработки данных, необходимых для выполнения функций, задач, процедур. В подразделе описываются технологические процессы, которые состоят из нескольких процедур.
- Аварийные ситуации. В разделе описываются действия в случае длительных отказов технических средств, обнаружении несанкционированного вмешательства в данные, действия по восстановлению программ или данных.
Руководство оператора отличается от руководства пользователя. В этом руководстве все процессы, выполняемые программным обеспечением, рассматриваются с технической точки зрения.
Структура руководства оператора содержит:
- Установка а сервер. Программное обеспечение «Зарплата и кадры» является многопользовательским, следовательно, оно имеет централизованную базу данных. В разделе описывается процесс установки программного обеспечения на сервер. Пошаговая инструкция дает точные указания, каким образом необходимо выполнить установку, в зависимости от технического состояния сервера. Настройка сервера для обеспечения работоспособности программного приложения «Зарплата и кадры» является основным моментом администрирования, так как сервер хранит большие объемы различной информации.
- Установка локальная. В разделе описывается процесс настройки компьютеров, использующих программное приложение, также даются рекомендации по оптимизации настройки рабочих станций, чтобы улучшить процесс взаимодействия сервера и компьютеров пользователей.
- Администрирование пользователей. В разделе подробно описывается процесс администрирования учетных записей пользователей программного обеспечения «Зарплата и кадры». Подробная инструкция описывает все ситуации, которые могут возникнуть при управлении пользователями. Например, с помощью данной подсистемы можно централизованно завершать все активные соединения с информационной базой и устанавливать блокировку новых соединений на определенный период времени. Такая возможность полезна при выполнении различных административных действий с информационной базой.
- Информационная база. В разделе рассматриваются вопросы администрирования, сохранения, переноса базы данных. Описаны рекомендации по настройке базы данных. Например, рассматривается ситуация резервного копирования. Программное обеспечение «Зарплата и кадры» позволяет создавать резервные копии информационной базы. Резервное копирование может выполняться как в автоматическом режиме, так и в ручном. Для автоматического режима предварительно необходимо выполнить настройки. В любой момент можно восстановить данные информационной базы из созданной ранее резервной копии.
- Технические неполадки. Этот раздел содержит информацию о возможных технических проблемах, которые могут возникнуть в процессе эксплуатации программного обеспечения. Рассматриваются проблемы, возникающие в результате некорректной работы оборудования, а также ситуации, возникающие в результате некорректного использования функций программного обеспечения «Зарплата и кадры».
- Программный код. В разделе подробно описывается структура программного кода. Если в процессе использования программного обеспечения возникают ошибки или потребуется доработка, то для этого необходимо знать программный код. Указываются особенности программного кода, создающие затруднения в процессе доработки. Раздел является очень важным, так как может потребоваться добавить, удалить или изменить определенные функции программного обеспечения «Зарплата и кадры».
Документ «Руководство пользователя» является неотъемлемой частью программного обеспечения, следовательно и чем лучше, он будет составлен, тем меньше проблем будет возникать в процессе эксплуатации разработанной программы.
СПИСОК ЛИТЕРАТУРЫ
- Радченко М.Г. 1С: Предприятие 0. Практическое пособие разработчика. Примеры и типовые приемы . – 1С – Паблишинг, 2004. – 656 с.
- Тимофеев Г., Шумейко Д. Конфигурирование и администрирование 1С: Предприятия. – Ростов н/Д: Феникс, 2003. – 320 с.
Туториал для туториалов. Как написать пользовательскую документацию
Время на прочтение
12 мин
Количество просмотров 14K
Есть устоявшеёся мнение, что для хороших продуктов руководство пользователя не нужно. Очередной холивар на эту тему разгорелся в нашем рабочем чате. Я не до конца согласен с этим утверждением.
Хороший интерфейс действительно должен помогать пользователю быстро понять продукт и научиться им пользоваться. Как всегда есть пара НО.
-
Пользователи бывают разные. То есть они могут отличаться как по возрасту, отрасли и опыту, так и по количеству мотивации. Мотивация особенно касается b2b сервисов. Многие пользователи попадают в продукты, потому что «Начальник сказал».
-
Продукты бывают сложные. Быстро разобраться и понять все их фишки без документации сложно или невозможно.
Документация помогает пользователю решить проблему или помочь разобраться с особенностями и фишками продукта. В любой документации люблю раздел Tips&Tricks.
Что входит в пользовательскую документацию
Пользовательская документация — это не юридические документы. У них другие цели.
Пользовательская документация — это материалы, которые помогают пользователю использовать продукт на максималках.
Что еще можно отнести к пользовательской документации
Документация для разработчиков и администрированию: доки по API, инструкции по установке и администрированию. Но сейчас их касаться не буду.
В пользовательскую документацию я включаю:
-
Ответы на часто задаваемые вопросы (FAQ).
-
Руководство пользователя. Это самый жирный кусок из всей пользовательской документации. Здесь описывается весь интерфейс, только текстом.
-
Краткое руководство пользователя. Короткая презентация или документ для быстрого начала. Описывает базовые функции, возможности и советы для начала. Главное отличие от полного руководства — быстрее читаются, дают базовое представление о продукте и особенно помогают при внедрении b2b продуктов.
-
Описание отдельных фишек (Tips&Tricks). Чаще всего их делают в формате видеоуроков, но можно наткнуться и на текстовые.
-
Релизноуты. Считаю их важной частью пользовательской документации. И, говоря релизноуты, я имею ввиду не разовые, которые выкладываются в магазины приложений или к себе на сайт. А написанные раз в какой-то период. Можно раз в месяц. При работе над прошлым продуктом мы писали всё, что исправили или добавили за месяц. Хорошим тоном, на мой взгляд, будет писать самое важное.
-
Видеоуроки. Считаю их частью пользовательской документации, но это скорее вкусовщина, чем правило.
Почему это важно?
Хорошо написанная пользовательская документация помогает разгрузить поддержку. Особенно если первый контакт у вас происходит через бота. Боты берут ответы на типовые вопросы из документации. А если большая часть ваших запросов типовые, несложно подсчитать насколько это разгружает поддержку.
Если в вашей поддержке сидят операторы, то документация поможет им найти ответ на вопрос, если они не знают и быстро скопировать нужный текст для отправки. Или вообще отправить ссылку на кусок документации, который решает проблему пользователя.
Документация помогает пользователям разобраться в продукте или узнать какие-то неявные фишки. Я, например, часто ползаю в гайды разных продуктов, чтобы посмотреть как какую-то штуку сделать и можно ли её вообще сделать.
Документация помогает вам работать с корпоративными заказчиками, но об этом дальше.
Красоты B2B рынка
Прошлый продукт, над которым мы с командой работали, умел и в облако, и в on-premise.
С облаком все понятно. Динамическая документация на сайте или в другом сервисе. Документация для корпоративных заказчиков имеет определенные особенности.
Особенность #1: Корпорации любят печатную документацию. Очень сильно.
Мой знакомый сейлз любит рассказывать истории про это.
Резюме его историй:
Если вдруг что, отчитываться о покупке, установке и эксплуатации корпорации будут большими стопками документации.
Поэтому чем толще кипа бумаги — тем лучше.
Особенность #2: Нужно отдавать дополнительные пакеты документов.
В дополнительные пакеты документов входит: документация по установке вашего ПО и документацию по его администрированию, а может ещё что-то, если попросят.
Особенность #3: Документацию, которую вы отдаете корпоративному заказчику, нужно будет поддерживать отдельно.
Реальность работы с большими корпоративными заказчиками в том, что ваш продукт требует доработки для решения их задач. Всегда есть какие-то нюансы и дополнения. Поэтому отдавать им облачную документацию, чаще всего, не получится.
Особенность #4: Встречается реже, но тоже требует внимания. Если ваш продукт визуально кастомизируется (меняются цвета, меняется расположение кнопок), то для каждого заказчика с нестандартным интерфейсом нужно будет делать свою документацию. Это не правило, а скорее хороший тон и забота.
Где делать?
Много думал, долго смотрел. Переделывал наш гайд раз пять.
Когда искал, ставил для себя следующие задачи:
-
Документацию можно сделать динамической. То есть возможность грузить видео, гифки, делать кросс-ссылки.
-
Поддерживается базовое форматирование: заголовки, жирный, курсив, code, code block.
-
Возможность экспортировать в .pdf.
Небольшой совет
Касается не только пользовательской документации, а вообще любой документации. Если это документ не на согласование, а уже передается, отдавайте всегда в .pdf. Вы избежите много проблем, а самое главное, он будет выглядеть так, как вы задумали и ничего не поедет.
-
Есть возможность выложить документацию на свой домен.
-
Есть возможность кастомизации для заказчиков. Поменять цвета, добавить логотипы и прочее.
Какие вариант рассматривал:
-
Самописные.
Стоимость: может быть любой и измеряться в человеко-часах.
Плюсы: можно накрутить и наворотить, что по кайфу.
Минусы: долго, дорого, больно, потому что полноценный отдельный продукт, но для компаний больше 100 человек, может быть хорошим решением. -
Google Docs.
Стоимость: Free
Плюсы: очень удобно работать с вёрсткой документа; привычный, при этом более простой интерфейс, относительно MS Docs; есть синхронизация с облаком; есть экспорт в .pdf.
Минусы: очень тяжело работать с визуальной частью — скринами; отношу в категорию не динамичных, так как выложить ссылочку на сайт на Google Doc конечно можно, особенно учитывая их последние апдейты, но это выглядит как-то не серьезно. -
Notion.
Стоимость: можно Free, если работает один человек, а так от 8-10$ за человека.
Плюсы: очень удобно делать динамическую документацию, которую не стыдно выложить на сайт, по моим ощущениям; удобно работать в паре, есть все необходимое; можно вставить любое медиа, хоть ссылку, хоть видео, хоть схему из miro.
Минусы: не самый широкий спектр инструментов для работы с версткой; если неправильно сверстать, скопировать кусочек текста в другое место бывает накладно; не для всех пользователей привычная навигация по страницам. -
Другие инструменты для wiki. Я смотрел на несколько вариантов wiki.js, Stonly 2, Dropbox Paper, Outline.
Смотрел давно, поэтому ничего вразумительно сказать не смогу. Помню, только что из всего выше, зацепил Dropbox и Wiki.js. В процессе написания этой статьи наткнулся ещё на один интересный сервис — GitBook. Он удовлетворяет всем моим запросам к подобным инструментам, но прошел мимо меня когда выбирал.
-
Figma.
Не пробовал, но хочу попробовать для ускорения работы именно с корпоративной документацией, есть у меня одна идея, как будет время попробую и расскажу.
С чего начать?
Не скажу ничего нового.
Начинать нужно с ответа на вопрос «Зачем мы это будем делать?». Мы начинали писать первую версию как раз для корпоративного заказчика. Но эта итерация была небольшой. Писали краткий гайд.
Потом я понял, что мне уже тяжко писать в поддержке одно и то же. Полный гайд сел писать, когда хотел немного разгрузить именно поддержку.
После того, как поняли зачем, накидайте план, а точнеё оглавление. План подразумевает последовательность, а оглавление позволяет вам писать не последовательно. Я писал непоследовательно. Сначала писал то, что помнил на память, потом все остальное.
Написали итерацию, дайте ей отлежаться немного. Вторым заходом я всегда добавлял медиа и проверял текст на логику, ошибки и соответствие реальности. Медиа делал второй итерацией, чтобы не отвлекаться от текста, так проще структурировать работу.
Я постарался написать о самых важных вещах, с которым я столкнулся, начав работу над этой задачей. Теперь хочу удариться в детали и рассказать о важных нюансах.
Основные правила
Понятный и простой язык
Я не буду писать о важности соблюдения правил русского языка: орфографии, пунктуации. И не буду рассказывать «Как писать хорошо?». Я сам далеко не эксперт в этом вопросе, поэтому когда мне нужно написать хороший текст я всегда обращаюсь к заветам Ильяхова и сервисам Главред, Яндекс.Спеллер и LanguageTools.
Любой текст должен быть простым и понятным.
Самое главное всегда это помнить.
Из рекомендаций, которые могу дать я лично — отказываться от привычных определений и писать ещё проще.
Например, вместо «Кликнуть» писать «Нажмите», вместо «Свайпнуть» — «Провести». Так нужно делать, потому что среди пользователей могут быть люди, которые не знают даже базовых терминов.
Понятное и аккуратное форматирование
Я люблю типографику и когда все аккуратно. Поэтому случаются приступы гнева, когда документы плохо сверстаны. Считаю это важным, так как эти правила придумали не просто так, а чтобы было удобно для читателя.
Правил много. Расскажу про самые бесячие и самые важные, на мой взгляд:
-
Кавычки.
Все то ли ленятся, то ли не знают где на клавиатуре находятся наши кавычки. У меня есть предположение, что эта привычка пошла со школ, потому что руками мы пишем другие кавычки.Основные кавычки оформляются елочкой «», внутренние кавычки оформляются лапками „“. Например, «Нажмите на вкладку „Контакты“ в левом верхнем углу», забугорные кавычки выглядят так «_».
Рекомендации по оформлению текста от Риановости P.S. Иностранные названия в русском тексте кавычками не выделяются.
-
Тире и дефис.
Все знают про тире и дефис. Оказалось, что многие не знают про среднее тире.Дефис (-) используется для присоединения частиц (что-то), для присоединения префиксов (по-братски), в словосочетаниях и сложносоставных словах (бизнес-ланч).
Среднее тире (–) применяется в числовом обозначении диапазонов и интервалов: 2011–2022, 11–12 ноября.
Длинное тире (—) используется для выделения прямой речи, указания маршрутов (Москва — Санкт-Петербург), между подлежащим и сказуемым.
-
Оформление списков.
Существуют два вида списков: нумерованный и маркированный.Маркированные списки выделятся буллитами, длинным тире или выключкой (реже всего встречается, сдвиг вправо, без символа), нумерованные списки выделяются числами.
Традиционный символ маркированного списка в русской типографике — тире, а не буллит. Говорят, что буллиты пришли к нам в месте с софтом от Microsoft. Мне нравятся буллиты и я чаще пользуюсь ими. Но они яркие и привлекают внимание. С одной стороны, это хорошо, с другой — с ними стоит быть осторожней. Если буллитов много, они могут перетянуть на себя внимание читателя.
Нумерованный список используется когда есть четкая последовательность пунктов. Когда последовательности нет — всегда маркированный.
Ещё один важный момент.
-
Если пункт списка начинается с большой буквы, на конце всегда точка.
-
Если пункт списка один или два слова и начинается с маленькой буквы, на конце запятая, в конце списка точка.
-
Если пункт списка длинный и внутри пункта есть запятые, на конце ставим точку с запятой.
-
-
Оформление дат и чисел.
Если в тексте присутствуют даты, то лучше писать 15 мая 2021, а не 15.05.2021. Помогите пользователю думать только о важном.Если есть числа, то их нужно тоже оформить правильно. Не 2221, а 2 221. Отделяйте тысячные, это очень сильно упрощает восприятие.
-
Вы или вы.
Мое стойкое мнение — если это не коммуникация с кем-то из государственной организации в переписке, всегда писать вы и ваш с маленькой буквы. Иначе выглядит, что вы кричите на пользователя, а на пользователя нельзя кричать.В случае с гос. организациями все очень просто, я считаю, что если они узнают, что можно писать с маленькой, их мир рухнет.
-
Буква Ё.
С этой буквой у меня особые отношения. Исторически моя фамилия пишется через Ё, но из-за передергивания правил русского языка в советском союзе моя фамилия теперь пишется через Е. Поэтому я долгое время принципиально везде писал Е. Годы идут. Мозгов прибавилось. Теперь стараюсь писать Ё везде, где ей место. Так действительно проще воспринимать текст. -
Эмодзи в тексте 🦄
По этому поводу много споров как у нас в команде, так и в кругах пишущих. Я придерживаюсь мнения, что эмодзи в тексте допустимы, но очень дозировано.Я использовал эмодзи для визуального подчеркивания каких-то кнопок в интерфейсе.
Например: Нажмите на символ ⚙️ в правом верхнем углу.Для поиска символов пользуюсь Glyphy.
Ещё есть классный сервис Типограф, он поможет поставить нормальные кавычки, убрать лишние пробелы, в нужных местах заменить дефисы на тире и поправить другую экранную типографику.
Если ваш продукт международный
Правила выше применяются к русскому языку. Если ваш продукт международный, то нужно оформлять по международным правила. В некоторых местах правила могут сильно отличаться от наших стандартов.
Удобная навигация
Нет единого мнения — как правильно. Если самопис, я рекомендую делать вертикальную навигацию слева. Такая часто встречается в технических документациях.
По структуре, на мой взгляд, можно выделить такие блоки:
-
Блок общего и важного.
-
Описание вашего решения. Вдруг пользователь попал сначала на ваш гайд, а не на сайт.
-
FAQ.
-
Какие есть приложения, со ссылками на скачивания или как пользоваться, если это например веб-версия.
-
Наши обновления.
-
-
Блок «Как начать». Сюда писать общие вещи, которые касаются всего сервиса. Особенно важный блок, если у вас мультиплатформенное решение.
-
Блок с руководством пользователя. Если у вас мультиплатформенное решение, то на каждую платформу лучше писать свое руководство. Можно объединять мобильные приложения и ПК версию. Так можно делать если нет глобальной разницы.
У нас, например, исторически разницы не было. Поэтому iOS и Android лежат на странице «Мобильные приложения». Но сейчас мы начали разделять, поэтому в будущем будет разделение на ОС.
Связность
Продукт — это всегда комплекс фич. И они часто между собой связаны. Если в одном месте упоминается другая фича, давайте ссылку на страницу или пункт.
Если хочется сделать по красоте, то можно внимательно изучить методологию Zettelkasten, например.
Удобный поиск
Тут много писать не буду. Если пользователь попал в документацию с конкретным запросом, у него должна быть возможность быстро найти то, что ему надо. Пользователь — не Индиана Джонс и охотиться за минотавром в вашей навигации не планирует.
Вот как мы это в Notion решили.
Логичность
Всё, что вы пишите должно быть логичным.
Порядок элементов в тексте и интерфейсе должен быть одинаковым. Пользователь ломается, когда написано: «Нажмите на вторую вкладку „Контакты“», а вторая вкладка — «Чаты».
Или когда в интерфейсе элемент называется «Назначить админом», а написано «Назначить администратором».
Понятная визуалка
Этот пункт я бы хотел разбить на два блока: работа с медиа и работа с Step-by-Step.
Работа с медиа
Я сторонник динамичных гайдов. Когда есть .gif или видео презентация. Это помогает увидеть наглядно. Если есть возможность, наполняйте вашу документацию .gif.
С видео все сложнее. Оно требует дополнительного действия от пользователя — включить, плюс весит больше чем .gif. Поэтому видео использую редко. Чаще для каких-то больших блоков или полноценных видеоуроков.
Иногда нет возможности сделать документацию динамической, особенно если вы работаете с корпоративными клиентами. Тогда делайте скриншоты реального интерфейса. Для этого лучше завести демо-стенд с близким к реальности наполнением. И там делать скриншоты.
Можно нарисовать демо-стенд в Figma и из этого собирать медиа для гайда. У меня такой подход не прижился, сложнеё управляться.
На скриншотах обязательно нужно выделять шаги, которые описаны в ваших Step-by-Step. Все выделения делать одним и тем же цветом, за исключением ситуаций когда явно нужно разделение.
Очень не люблю стрелочки. Считаю, что лучше выделить место геометрической фигурой и поставить номер шага. Но иногда стрелочки приемлемы, тут вкусовщина.
Из хороших приемов — блюрить лишнюю часть интерфейса или делать выделение лупой важной части.
Для работы со скриншотами я использую стандартный маковский редактор картинок, иногда Figma.
Step-by-step
Step-by-Step — это пошаговое описание всех действий, которые нужно выполнить пользователю, чтобы получить результат.
Искал хоть какую-то информацию про то, как пишутся такие штуки и ничего хорошего не нашел. Поэтому основываясь на здравом смысле, вывел для себя ряд правил:
-
Делать нумерованные списки. Если есть подпункты, то нумеровать их соответственно и делать сдвиг вправо 1.1, 1.2, 1.2.1 и тд.
-
Писать сначала «Что нажать», потом «Где нажать». Исхожу из простой логики — сначала нужно понять «Что искать» и только потом «Где искать».
Например: «Нажмите на кнопку „Включить“ в правом верхнем углу», а не «В правом верхнем углу нажмите на кнопку „Включить“».
-
Вставлять визуальные элементы для кнопок, особенно если они без подписи. Для этой истории приходится немного костылить, если делать это в том же Notion, но в Google Docs это делать проще. Использую стандартные эмодзи и сервис Glyphy.
Например: Нажмите на символ ⚙️ в правом верхнем углу.
Не люблю слово иконка, поэтому пишу символ, чтобы была однозначность. Тоже вкусовщина.
-
Если одно действие можно сделать из разных мест, описывать все места и каждое по пунктам.
-
Если два действия отличаются между собой одним пунктом и кажется бредом писать их два раза, перекреститься и написать два раза. Например, удаление и редактирование часто похожи.
-
Все названия кнопок, сущностей, элементов — должны иметь такое же название как в интерфейсе.
-
Все названия кнопок, вкладок и элементов интерфейса всегда выделяю кавычками. Для того, чтобы выделить и, потому что в какой-то степени это имя собственное.
Поддержка и послесловие
Поддерживать эту историю важно и нужно. В какой-то момент пользователи привыкнут ей пользоваться. Не сами. Вам тоже нужно приложить усилие для того, чтобы люди читали вашу документацию.
Пользователи будут рассчитывать, что найдут там ответ на свой вопрос. Поэтому там всегда должна быть актуальная информация.
Описывать фичу нужно до релиза и вместе с релизом добавлять в гайд. Почему нужно описывать до релиза, думаю, объяснять не нужно.
Раз в 3-6 месяцев заходить и перечитывать, лучше если это каждый раз будет делать новый человек. Это нужно делать по трем причинам:
1. Когда пишешь большие текстовые документы, глаз замыливается. Можно написать бред и после его не заметить.
2. Всегда найдутся ошибки. Даже в книгах, которые вычитывают и проверяют специально обученные люди, есть ошибки. Старайтесь на всех страницах оставлять кнопочку обратной связи, чтобы пользователи могли помочь с поиском ошибок.
3. Всегда есть что улучшить. Текст это такой же продукт.
Хочется верить, что эта статья сэкономит кому-то время, а кому-то поможет стать немного лучше.
Я не претендую на истину в последней инстанции. Описал свой опыт и мнение.
p.s. Пользовательская документация с которой все началось. Скажу сразу, там очень много чего можно и нужно улучшить. Бэклог по апдейту документации уже перевалил за 30 задач. Постепенно обновляем.
p.s.s. буду благодарен за конструктивный фидбек в комментариях и ещё больше, если поделитесь вашим опытом.
Документация на программное обеспечение — это документы, сопровождающие некоторое программное обеспечение (ПО) — программу или программный продукт. Эти документы описывают то, как работает программа и/или то, как её использовать.
Документирование — это важная часть в разработке программного обеспечения, но часто ей уделяется недостаточно внимания.
Типы документации
Существует четыре основных типа документации на ПО:
- архитектурная/проектная — обзор программного обеспечения, включающий описание рабочей среды и принципов, которые должны быть использованы при создании ПО
- техническая — документация на код, алгоритмы, интерфейсы, API
- пользовательская — руководства для конечных пользователей, администраторов системы и другого персонала
- маркетинговая
Архитектурная/проектная документация
Проектная документация обычно описывает продукт в общих чертах. Не описывая того, как что-либо будет использоваться, она скорее отвечает на вопрос «почему именно так?» Например, в проектном документе программист может описать обоснование того, почему структуры данных организованы именно таким образом. Описываются причины, почему какой-либо класс сконструирован определённым образом, выделяются паттерны, в некоторых случаях даже даются идеи, как можно будет выполнить улучшения в дальнейшем. Ничего из этого не входит в техническую или пользовательскую документацию, но всё это действительно важно для проекта.
Техническая документация
Это именно то, что подразумевают под термином документация большинство программистов. При создании программы, одного лишь кода, как правило, недостаточно. Должен быть предоставлен некоторый текст, описывающий различные аспекты того, что именно делает код. Такая документация часто включается непосредственно в исходный код или предоставляется вместе с ним.
Подобная документация имеет сильно выраженный технических характер и в основном используется для определения и описания API, структур данных и алгоритмов.
Часто при составлении технической документации используются автоматизированные средства — генераторы документации, такие как Doxygen, javadoc, NDoc и другие. Они получают информацию из специальным образом оформленных комментариев в исходном коде, и создают справочные руководства в каком-либо формате, например, в виде текста или HTML. Использование генераторов документации и документирующих комментариев многими программистами признаётся удобным средством, по различным причинам. В частности, при таком подходе документация является частью исходного кода, и одни и те же инструменты могут использоваться для сборки программы и одновременной сборки документации к ней. Это также упрощает поддержку документации в актуальном состоянии.
Пользовательская документация
В отличие от технической документации, сфокусированной на коде и том, как он работает, пользовательская документация описывает лишь то, как использовать программу.
В случае если продуктом является программная библиотека, пользовательская документация и документация на код становятся очень близкими, почти эквивалентными понятиями. Но в общем случае, это не так.
Обычно, пользовательская документация представляет собой руководство пользователя, которое описывает каждую функцию программы, а также шаги, которые нужно выполнить для использования этой функции. Хорошая пользовательская документация идёт ещё дальше и предоставляет инструкции о том, что делать в случае возникновения проблем. Очень важно, чтобы документация не вводила в заблуждение и была актуальной. Руководство должно иметь чёткую структуру; очень полезно, если имеется сквозной предметный указатель. Логическая связность и простота также имеют большое значение.
Существует три подхода к организации пользовательской документации. Вводное руководство (англ. tutorial), наиболее полезное для новых пользователей, последовательно проводит по ряду шагов, служащих для выполнения каких-либо типичных задач. Тематический подход, при котором каждая глава руководства посвящена какой-то отдельной теме, больше подходит для совершенствующихся пользователей. В последнем, третьем подходе, команды или задачи организованы в виде алфавитного справочника — часто это хорошо воспринимается продвинутыми пользователями, хорошо знающими, что они ищут. Жалобы пользователей обычно относятся к тому, что документация охватывает только один из этих подходов, и поэтому хорошо подходит лишь для одного класса пользователей.
Во многих случаях разработчики программного продукта ограничивают набор пользовательской документации лишь встроенной системой помощи (англ. online help), содержащей справочную информацию о командах или пунктах меню. Работа по обучению новых пользователей и поддержке совершенствующихся пользователей перекладывается на частных издателей, часто оказывающих значительную помощь разработчикам.
Маркетинговая документация
Для многих приложений необходимо располагать рядом рекламных материалов, с тем чтобы заинтересовать людей, обратив их внимание на продукт. Такая форма документации имеет целью:
- подогреть интерес к продукту у потенциальных пользователей
- информировать их о том, что именно делает продукт, с тем чтобы их ожидания совпадали с тем что они получат
- объяснить положение продукта по сравнению с конкурирующими решениями
Одна из хороших маркетинговых практик — предоставление слогана — простой запоминающейся фразы, иллюстрирующей то что мы хотим донести до пользователя, а также характеризующей ощущение, которое создаёт продукт.
Часто бывает так, что коробка продукта и другие маркетинговые материалы дают более ясную картину о возможностях и способах использования программы, чем всё остальное.
Документирование программного обеспечения
Когда программист-разработчик получает в той или иной форме задание на программирование, перед ним, перед руководителем проекта и перед всей проектной группой встают вопросы: что должно быть сделано, кроме собственно программы? что и как должно быть оформлено в виде документации? что передавать пользователям, а что — службе сопровождения? как управлять всем этим процессом? Кроме упомянутых вопросов есть и другие, например, что должно входить в само задание на программирование? Прошло много лет, программирование происходит в среде совершенно новых технологий, многие программисты, работая в стиле drag-and-drop, могут годами не видеть текст своих программ. Это не значит, что исчезла необходимость в их документировании. Более того, вопросы о наличии хоть какой-то системы, регламентирующей эту сторону создания программных средств, продолжают задавать постоянно. Спрашивают и о том, есть ли обязательные для применения стандарты (особенно остро стоит этот вопрос, когда разработка выполняется по заказу государственной организации или предприятия). Интересуются и тем, где можно купить имеющиеся стандарты.
Качество программного обеспечения, наряду с другими факторами, определяется полнотой и качеством пакета документов, сопровождающих ПО. К программным документам относятся документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения программ и эксплуатации.
Техническое задание
Техническое задание. Требование к содержанию и оформлению. Напомним, что техническое задание (ТЗ) содержит совокупность требований к ПС и может использоваться как критерий проверки и приемки разработанной программы.
Поэтому достаточно полно составленное (с учетом возможности внесения дополнительных разделов) и принятое заказчиком и разработчиком, ТЗ является одним из основополагающих документов проекта программного средства.
- Техническое задание на разработку ПО должно включать следующие разделы: введение; основания для разработки;
- назначение разработки;
- требования к программе;
- требования к программной документации;
- технико-экономические показатели;
- стадии и этапы разработки;
- порядок контроля и приемки;
- приложения.
В зависимости от особенностей разрабатываемого ПО стандарт допускает уточнение содержания разделов, введение новых разделов или их объединение.
Руководство пользователя
Под документацией пользователя понимается документация, которая обеспечивает конечного пользователя информацией по установке и эксплуатации программного пакета. Под информацией на упаковке понимают информацию, воспроизводимую на внешней упаковке программного пакета. Ее целью является предоставление потенциальным покупателям первичных сведений о программном пакете.
Пользовательская документация программного средства объясняет пользователям, как они должны действовать, чтобы применить данную программу. Она необходима, если программа предполагает какое-либо взаимодействие с пользователями. К такой документации относятся документы, которыми руководствуется пользователь при установке программы с соответствующей настройкой на среду применения, при применении программы для решения своих задач и при управлении программой (например, когда данное программное средство взаимодействует с другими системами). Эти документы частично затрагивают вопросы сопровождения программного средства, но не касаются вопросов, связанных с модификацией программ.
В связи с этим следует различать две категории пользователей: ординарных пользователей программы и администраторов. Ординарный пользователь программы (end-user) использует программу для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью данной программы. Он может и не знать многих деталей работы компьютера или принципов программирования. Администратор программы (system administrator) управляет использованием программы ординарными пользователями и осуществляет сопровождение программного средства, не связанное с модификацией программ. Например, он может регулировать права доступа к программе между ординарными пользователями, поддерживать связь с поставщиками программы или выполнять определенные действия, чтобы поддерживать программу в рабочем состоянии, если оно включено как часть в другую систему.
Состав пользовательской документации зависит от аудиторий пользователей, на которые оно ориентировано, и от режима использования документов. Под аудиторией здесь понимается контингент пользователей, у которого есть необходимость в определенной пользовательской документации. Удачный пользовательский документ существенно зависит от точного определения аудитории, для которой он предназначен. Пользовательская документация должна содержать информацию, необходимую для каждой аудитории. Под режимом использования документа понимается способ, определяющий, каким образом используется этот документ. Обычно пользователю достаточно больших программных систем требуются либо документы для изучения программного средства (использование в виде инструкции), либо для уточнения некоторой информации (использование в виде справочника).
Можно считать типичным следующий состав пользовательской документации для достаточно больших программных средств:
- Общее функциональное описание программного средства. Дает краткую характеристику функциональных возможностей программного средства.
- Предназначено для пользователей, которые должны решить, насколько необходимо им данное программного средства.
Руководство по инсталляции программного средства
Предназначено для системных администраторов. Он должен детально предписывать, как устанавливать системы в конкретной среде. Он должен содержать описание машинно-считываемого носителя, на котором поставляется программное средство, файлы, представляющие программное средство, и требования к минимальной конфигурации аппаратуры.
Инструкция по применению программного средства
Предназначена для ординарных пользователей. Содержит необходимую информацию по применению программного средства, организованную в форме удобной для ее изучения.
Справочник по применению программного средства
Предназначен для ординарных пользователей. Содержит необходимую информацию по применению программного средства, организованную в форме удобной для избирательного поиска отдельных деталей.
Руководство по управлению программным средством
Предназначено для системных администраторов. Оно должно описывать сообщения, генерируемые, когда программные средства взаимодействует с другими системами, и как реагировать на эти сообщения. Кроме того, если программное средство использует системную аппаратуру, этот документ может объяснять, как сопровождать эту аппаратуру.
Разработка пользовательской документации начинается сразу после создания внешнего описания. Качество этой документации может существенно определять успех программы. Она должна быть достаточно проста и удобна для пользователя (в противном случае это программное средство, вообще, не стоило создавать). Поэтому, хотя черновые варианты (наброски) пользовательских документов создаются основными разработчиками программного средства, к созданию их окончательных вариантов часто привлекаются профессиональные технические писатели. Кроме того, для обеспечения качества пользовательской документации разработан ряд стандартов, в которых предписывается порядок разработки этой документации, формулируются требования к каждому виду пользовательских документов и определяются их структура и содержание.
Руководство программиста
Документация по сопровождению программного средства (system documentation) описывает программное средство с точки зрения ее разработки.
Эта документация необходима, если программное средство предполагает изучение того, как оно устроена (сконструирована), и модернизацию его программ. Как уже отмечалось, сопровождение — это продолжающаяся разработка. Поэтому в случае необходимости модернизации программного средства к этой работе привлекается специальная команда разработчиков- сопроводителей. Этой команде придется иметь дело с такой же документацией, которая определяла деятельность команды первоначальных (основных) разработчиков программного средства, — с той лишь разницей, что эта документация для команды разработчиков-сопроводителей будет, как правило, чужой (она создавалась другой командой). Команда разработчиков- сопроводителей должна будет изучать эту документацию, чтобы понять строение и процесс разработки модернизируемого программного средства, и внести в эту документацию необходимые изменения, повторяя в значительной степени технологические процессы, с помощью которых создавалось первоначальное программное средство.
Документация по сопровождению программного средства можно разбить на две группы:
1. документация, определяющая строение программ и структур данных ПС и технологию их разработки;
2. документацию, помогающую вносить изменения в программное средство.
Документация первой группы содержит итоговые документы каждого технологического этапа разработки программного средства. Она включает следующие документы:
- Внешнее описание программного средства (Requirements document).
- Описание архитектуры программного средства (description of the system architecture), включая внешнюю спецификацию каждой ее программы.
- Для каждой программы программного средства — описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля.
- Для каждого модуля — его спецификация и описание его строения (design description).
- Тексты модулей на выбранном языке программирования (program source code listings).
- Документы установления достоверности программного средства (validation documents), описывающие, как устанавливалась достоверность каждой программы программного средства и как информация об установлении достоверности связывалась с требованиями к программному средству.
Документы установления достоверности включают, прежде всего, документацию по тестированию (схема тестирования и описание комплекта тестов), но могут включать и результаты других видов проверки программного средства, например, доказательства свойств программ.
Документация второй группы содержит
- Руководство по сопровождению программного средства (system maintenance guide), которое описывает известные проблемы вместе с программным средством, описывает, какие части системы являются аппаратно- и программно- зависимыми, и как развитие программного средства принято в расчет в его строении (конструкции).
- Общая проблема сопровождения программного средства — обеспечить, чтобы все его представления шли в ногу (оставались согласованными), когда программное средство изменяется. Чтобы этому помочь, связи и зависимости между документами и их частями должны быть зафиксированы в базе данных управления конфигурацией.
Процесс управления конфигурацией
Процесс управления конфигурацией является процессом применения административных и технических процедур на всем протяжении ЖЦ ПС для определения состояния (базовой линии) программных объектов в системе, управления их изменениями и выпуском.
Данный процесс состоит из шести работ. Общее число задач по данным работам равно 6.
- Подготовка процесса управления конфигурацией — разработка плана управления конфигурацией. Тип выходного результата задачи — план.
- Определение конфигурации — Определение схемы обозначения программных объектов и их версий (объектов программной конфигурации) и документации, в которой фиксируется состояние их конфигурации. Тип выходного результата задачи — описание.
- Контроль конфигурации — Регистрация заявок на внесение изменений; анализ и оценка изменений; принятие или непринятие заявки; реализация, верификация и выпуск измененного программного объекта; обеспечение аудиторских проверок изменений.
- Учет состояний конфигурации — Подготовка протоколов управления конфигурацией и отчетов о состоянии контролируемых программных объектов. Тип выходного результата задачи — протокол, отчет.
- Оценка конфигурации — Определение и обеспечение функциональной законченности и физической завершенности программных объектов. Тип выходного результата задачи — протокол, отчет.
- Управление выпуском и поставка — Контроль выпуска и поставки программных продуктов и документации.
Источник:
Как написать руководство пользователя программы или сайта — инструкции, советы, помощь, программное обеспечение
Журавлев Денис
Что такое руководство пользователя и для чего его создавать
Ежедневно создаются новые продукты, программы, сервисы и часто пользователям приходится несладко при освоении какой-нибудь сложной программы, поэтому каждому новому продукту желательно собственное руководство. Для чего?
Большинство людей не хочет разбираться с чем-то незнакомым без персонального, всегда доступного и понятного помощника. А именно им и является хорошее руководство пользователя.
Общие советы по созданию пользовательской документации
Перед тем как приступить к созданию руководства, нужно определиться с некоторыми важными моментами. Например, определить, для кого вы его пишете? Кто его будет читать — рядовые пользователи, для которых важны базовые функции продукта, или люди, которым нужны особые, нечасто используемые функции программы/сервиса.
После этого важно подумать о том:
- Где пользователь будет к нему обращаться: дома, на работе, в машине?
- Как часто он будет его просматривать?
- Насколько объективно сложен для понимания продукт?
Из этого можно сделать вывод, насколько интенсивно пользователь будет работать с документацией, а значит уже можно выбрать между сжатым «справочником» или объемным «путеводителем» Также важно, чтобы руководство писал профессионал, знающий продукт. Так что по возможности делегируйте написание техническому специалисту или аналитику, у которого есть полное представление о всех тонкостях продукта.
Определившись со всеми представленными пунктами, станет понятнее, какой нужно использовать стиль изложения, какого объема написать текст. Но помните, что излишне стилистически окрашенные слова мешают пользователю добраться до сути. Так что лучшим вариантом в большинстве случаев будет нейтрально-формальный стиль. Пишите так, чтобы пользователь вас понял. Постарайтесь по возможности избегать технических терминов, но проанализируйте — не сделает ли полное отсутствие терминов ваше руководство бесполезным?
Структура руководства пользователя
После того как вы ответили на предыдущие вопросы, создайте структуру руководства. У любого хорошего «путеводителя» хорошая и логичная структура. Начните с оглавления. Информативное содержание поможет читателю легко ориентироваться в документе.
В первом разделе желательно рассказать общую информацию о программе:
- Для чего создан продукт.
- Какие задачи он решает.
- Какие основные выгоды от использования для клиента.
В следующем разделе можно указать основные элементы пользовательского интерфейса. Пользователю будет трудно разобраться в софте, если он не поймёт для чего служат различные элементы интерфейса, или он не разберётся в основных режимах работы ПО. Опишите понятным языком предназначение экранов и окон.
Создайте раздел, где расскажете о наиболее эффективных способах применения продукта для решения типовых задач. Какие цели стоят перед клиентом, и как ваша программа/сервис помогает достичь их. Укажите информацию о том, как быстро и продуктивно пользоваться программой.
Ни одно руководство не обойдется без таких разделов как: «Частые вопросы» и «Устранение типовых проблем» В них разбираются вопросы и проблемы, с которыми часто сталкиваются пользователи. Для заполнения данного раздела вам скорее всего понадобятся уже готовые отзывы клиентов. Если у вас абсолютно новый продукт, вы можете предугадать проблемы ваших клиентов либо на первое время не включать данный пункт в ваше руководство.
Иногда технические писатели забывают о важном моменте в руководстве пользователя — контактная информация. Этот раздел поможет пользователям связаться с вами, даже если у них нет никаких вопросов и руководство полностью закрывает все их потребности. Клиент может дать совет, поделиться опытом или предложить выгодное вам сотрудничество.
Инструменты для быстрого создания руководства пользователя
Но как создать руководство пользователя, если пишешь его впервые? Или что делать, если руководство пользователя нужно постоянно обновлять и дорабатывать? Или нужны особые функции, которых нет в традиционных текстовых редакторах, например, в MS Word.
Одним из популярных инструментов для создания качественного руководства является программа Dr. Explain (https://www.drexplain.ru), в которой уже есть готовые шаблоны руководств пользователя с готовой структурой разделов и в которой удобно обновлять документацию, как бы часто эти обновления не происходили.
Видео-обзор основных возможностей программы Dr.Explain
Удобной особенностью инструмента является возможность экспортировать один и тот же документ в форматы: HTML, CHM, PDF. Простой и понятный интерфейс сам подскажет, как быстро просмотреть документ в различных форматах и настроить его под вывод в эти форматы.
Любой проект в Dr.Explain вы можете создать с нуля или импортировать уже существующую документацию, например из формата MS Word, HTML или CHM-файла, и буквально за несколько минут создать из нее онлайн-помощь, файл справки в формате CHM, или документ в формате PDF.
При создании руководства важно опираться на заранее составленный план. Дерево проекта в Dr.Explain поможет структурировать документ по вашему усмотрению. Вы можете добавлять, удалять перемещать разделы и переименовывать их. Для каждого раздела вы можете определить, в какой формат он будет экспортироваться. Также в работе удобно использовать статусы готовности разделов.
У программы свой собственный редактор, оптимизированный под работу со сложной документацией. Основные функции редактора вынесены в компактный тулбар. Это — управление стилем текста, форматирование абзацев, вставка ссылок, изображений, видео, таблиц и списков, а также вставка специальных объектов. Dr. Explain экономит время и силы своих пользователей. Разработчики документации часто сталкиваются с проблемой многократного использования одного и того же фрагмента текста и прибегают к очевидным решениям — «Ctrl+c», Ctrl+v». Dr.Explain предлагает решение по повторному использованию контента — текстовые переменные. Это решение экономит время, когда нужно много раз использовать один и тот же текст, особенно, который может периодически изменяться — например, версия документируемой системы.
Многие российские компании сталкиваются с тем, что руководство пользователя нужно писать согласно ГОСТ 19 и ГОСТ 34. Dr.Explain активирует поддержку требований ГОСТ фактически одним кликом. Программа автоматически сформирует структуру обязательных разделов и установит требуемые параметры страницы, стили абзацев, списков и заголовков.
Часто техническим писателям при документировании пользовательского интерфейса приходится снабжать изображения пояснительными выносками. Для таких случаев программа поддерживает специальные графические объекты — аннотированные экраны. Чаще всего аннотируются скриншоты программ и страниц веб-сайтов. Уникальной особенностью Dr.Explain является автоматическая аннотация изображений, получаемых при захвате экранов с окнами программ или сайтов. Программа анализирует структуру окон и добавляет пояснительные выноски ко всем значимым элементам.
Кроме того, Dr.Explain позволяет нескольким авторам одновременно работать над проектом с использованием сервиса www.tiwri.com, учетную запись на котором можно создать бесплатно за пару минут. При внесении правок одним автором сервис блокирует редактируемые разделы проекта для изменения другими авторами. По окончании редактирования изменения отправляются на сервер, и блокировка снимается. Так несколько человек могут одновременно работать над различными разделами проекта без риска помешать друг другу.
Попробовать режим многопользовательской работы в Dr.Explain можно даже с бесплатной лицензией. Вы можете создать общий проект и полноценно работать с ним в многопользовательском режиме до семи дней.
Почему компании выбирают Dr.Explain для создания руководств пользователя
Павел Свиридов, профессиональный военный, полковник, создатель астрологической системы «Вега Матрица»
«Только программа Dr.Explain обладала всеми необходимыми возможностями. А главное — она давала простор для творчества. Можно было выбрать цветовую гамму, вид и форму служебных элементов, настраиваемые шаблоны. Это позволило мне сохранить стилевое единство документации и самой программы. Ну, и конечно, полуавтоматическая обработка материала существенно облегчает и ускоряет работу по созданию хелпа.
Обучение работе в Dr.Explain было наглядным и сделано возможностями самой программы, что безусловно повлияло на мой выбор в ее пользу».
Прочитать полный кейс компании «Вега Матрица вы можете перейдя по ссылке
Наталья Обухова, бизнес-аналитик компании CRM Expert
«По классике жанра был пилотный проект на двух фаворитах (Dr.Explain и HelpNDoc) и муки выбора.
Через неделю справка была полностью готова. Конечно, если мы набивали ее «с нуля», за это время мы бы не успели. Мы просто конвертировали все бумажные инструкции во внутренний формат программ, изменили каталогизацию и организовали систему гиперссылок.
Сначала фаворитом выбора была другая система, но решающим фактором в пользу Dr.Explain стал возглас человека, выполняющего основную часть работы по переносу текста: «Вжух! И вся структура документа перенеслась в файл справки». Функция импорта в Dr.Explain отработала на ура и сэкономила кучу времени.
Также очень подкупил дизайн веб-справки, который формируется Dr.Explain, и красивый способ организации подписей к окнам нашей системы. В Dr.Explain это называется «Аннотирование экрана».
Возможность установки статуса раздела тоже оказалась очень удобной, особенно, после импорта старой версии справки легко отслеживать, какие разделы требуют обновления, в каких еще ведутся изменения, а какие уже обновлены и актуальны».
Прочитать полный кейс компании CRM Expert
Николай Вальковец, разработчик компании 2V
«Мы значительно сократили время работы техподдержки с новыми клиентами на этапе подключения. Раньше требовалось проводить онлайн презентации и видео конференции для новых клиентов, объясняя особенности программы. Сейчас же, один раз постаравшись максимально подробно всё описать, мы избавили себя и нашу техподдержку от этой работы. Нам импонирует простота программы и скорость работы. Можно быстро редактировать, добавить новые пункты в документацию, сохранить в формате HTML и выложить на сайт».
Прочитать кейс компании V2
Подытожим
Создание и написание хорошей пользовательской документации — это труд, который требует много времени и усилий. Но если успешно справиться с задачей, можно навсегда получить лояльных и довольных клиентов. Не забывайте о том, что недовольство от некачественного руководства может быть спроецировано пользователем на сам продукт и повлиять на дальнейшие решения о его выборе. Пользовательская документация должна стать персональным и незаменимым помощником. Используя Dr. Explain, вы сможете быстро создать качественное руководство пользователя, которое будет помогать пользователям разбираться в продукте, а вам позволит сосредоточить свои силы на более важных задачах — разработке и продвижении программного продукта.
Скачать Dr.Explain с неограниченной по срокам возможностью бесплатной работы можно по адресу: https://www.drexplain.ru/download/
Успешных вам разработок!
Смотрите также
- Dr.Explain — инструмент для создания мобильной версии пользовательской документации к программным продуктам
- Шаблоны файлов помощи, руководства пользователя программного обеспечения или сайта, шаблон базы знаний — бесплатные шаблоны и примеры пользовательской документации
Писать руководство пользователя по шаблону. Удобно? Удобно
Время на прочтение
4 мин
Количество просмотров 4.7K
Команда, разрабатывающая софт для создания пользовательской документации, делится лайфхаками на тему написания идеальной пользовательской документации для тех, кто далёк от написания руководств к программе.
Для чего мы сами конструируем некоммерческие образцы документации и инструкций для пользователей
Наш проект существует и развивается уже долгое время, практически шестнадцать лет, если быть точнее. За этот срок была сформирована определенная база, где собраны самые актуальные и насущные вопросы, которые возникают перед людьми, создающими справочные элементы к своему проекту.
Ведя диалог с нашими клиентами, мы смогли выделить их потребности и понять основную «боль». Если обобщить, основная проблема заключалась в том, что ни одна программа для создания файл-справок и инструкций не могла выполнить самую нудную, энергозатратную часть проекта — само разрабатывание и оформление этой пользовательской документации
Даже имея осознание того, что файл-справка — неотъемлемый и действительно полезный элемент для пользователя, очень редко возникает мотивация оформить его грамотно и качественно. Еще реже желание возникает, когда в написании пользовательской документации нет опыта или специалистов, которые бы этот опыт имели. Обычно, эта обязанность с легкой руки падает на плечи самих создателей программы, людей, занимающихся тестированием, аналитикой, специалистам поддержки или даже руководителей компании, которые тоже не совсем понимают, как грамотно создать что-то подобное.
Отсюда вытекает еще одна загвоздка. Люди, у которых нет опыта и в принципе понимания, как начать и что туда вносить, просто не знают, как создать качественное руководство для пользователей. В таких случаях большинство следует привычному пути: загуглить определение и найти готовый шаблон.
И с какой-то стороны, это разумно. Мы достаточно часто сталкиваемся с такими запросами, пользователи просят у нас пошаговое руководство или хотя бы костяк готовой инструкции.
Так вышло, что потребности наших клиентов практически на сто процентов входят в нашу экспертную сферу. И мы приняли решение по возможности помочь всем, кто хочет (или вынужден) заниматься созданием файл-справок и инструкций к своему продукту и предоставить возможность получить образцы, которые могут послужить базой и легко быть адаптированными под конкретный запрос.
В связи с этим, мы сами создали готовые образцы и костяки шаблонных проектов в программе. Что входит в нашу базу:
-
Руководство пользователя программного обеспечения.
-
Руководство пользователя web-сервиса.
-
Корпоративная база знаний компании.
В чем удобство создания руководства пользователя по образцу
Вы бережете своё время.
Адаптируя уже созданный образец под свой продукт, вы не тратите время на создание основы с нуля, вам не нужно тратить время, чтобы найти мастер-класс о том, как правильно это сделать. Используя готовый шаблон документации, вы значительно экономите время на создание структуры проекта с нуля и на поиск и изучение информации о том, как это делается.
Вы сосредотачиваете внимание на вашей программе, а не на создании файл-справки
В шаблоне уже есть текстовые и графические вставки, вы можете сами добавлять нужный контент в предложенные места и не продумывать вариант оформления.
Наглядность.
Все образцы и костяки инструкций для пользователя изначально настроенные с динамическими стилями оформления, которые помогут вам быстрее освоиться и разобраться, как можно использовать это для быстрого выполнения своей цели.
Адаптация шаблонов и образцов под ваш проект.
Всё, что находится в шаблонах, можно назвать нашим советом, который был создан на основе многолетнего опыта в данной сфере и выработанной экспертностью. Абсолютно всё в этих шаблонах может быть подвержено адаптации, так как для пользовательской документации нет жестких стандартов, она должна быть выстроена персонально под ваш продукт.
О шаблонах
За 15 лет мы смогли подвергнуть аналитике более сотни разных файл-справок, инструкций и технических документаций, что дало нам возможность сделать вывод и определить шаблонные разделы, которые могут быть применены к огромному количеству программ, после чего мы интегрировали их в наши образцы. Давайте немного подробнее поговорим о структуре.
Обзор возможностей программ. Здесь идет краткое содержание сути вашего продукта. Где вы рассказываете о том, для чего нужна ваша программа. Какие боли и потребности она удовлетворяет, на что способна.
Пользовательский интерфейс. Здесь вы можете наглядно показать вашему клиенту интерфейс, ознакомить его со всеми режимами, дополнительными кнопками и.т.д. Если пользователь может персонализировать интерфейс под себя, об этом тоже лучше указать именно в этом разделе.
Типовые задачи. Здесь нужно максимально подробно познакомить пользователя со всеми основными возможностями программы и детально описать ряд задач и вопросов, которые клиент сможет решить с её помощью. В нашем образце этот блок сформирован из двух подразделов. В подразделе «Примеры использования» лучше всего рассказать пользователю, как ваш продукт будет решать его вопросы и задачи. Если обобщить, то в этом подразделе вы рассказываете про клишированные проблемы, с которыми сталкивается большинство пользователей. В подразделе «Лучшие практики» лучше разместить максимально полезную информацию о том, как упростить свою работу в программе и как пользоваться ей максимально эффективно.
Особые случаи. Здесь нужно рассказать пользователю про то, какие трудности могут возникнуть и как их решить, выделить часто задаваемые вопросы и дать на них самый доступный ответ. Подразделы: «FAQ» и «Устранение типовых проблем»
Вспомогательная и юридическая информация. Здесь вы размещаете информацию о компании, размещаете контактные данные тех.поддержки, информацию о сотрудничестве, сайт, а также лицензионные соглашения.
Названия проекта публиковать не будем, Хабр ругается.
P.S. Мы будем рады, если наши образцы помогут вам закрыть вопрос и успешно реализовать документацию в своем проекте.
Документ «Руководство пользователя»
Документ «Руководство пользователя»
РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов: <…>.
УКАЗАНИЯ ГОСТ:
Настоящие методические указания распространяются на автоматизированные системы (АС), используемые в различных сферах деятельности (управление, исследование, проектирование и т. п.), включая их сочетание, и устанавливают требования к содержанию документов, разрабатываемых при создании АС.
Руководство пользователя
- Структура документа:
- 1. Введение
- 1.1 Область применения
- 1.2 Краткое описание возможностей
- 1.3 Уровень подготовки пользователя
- 1.4 Перечень эксплуатационной документации
- 2 НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ
- 2.1 Виды деятельности, функции
- 2.2 Программные и аппаратные требования к системе
- 3 ПОДГОТОВКА К РАБОТЕ
- 3.1 Состав дистрибутива
- 3.2 Запуск системы
- 3.3 Проверка работоспособности системы
- 4 ОПИСАНИЕ ОПЕРАЦИЙ
- 4.1 Наименование операции
- 4.2 Условия выполнения операции
- 4.3 Подготовительные действия
- 4.4 Основные действия
- 4.5 Заключительные действия
- 4.6 Ресурсы, расходуемые на операцию
- 5 АВАРИЙНЫЕ СИТУАЦИИ. ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ
- 6 РЕКОМЕНДАЦИИ ПО ОСВОЕНИЮ
УКАЗАНИЯ ГОСТ:
Документ содержит разделы:
1) введение;
2) назначение и условия применения;
3) подготовка к работе;
4) описание операций;
5) аварийные ситуации;
6) рекомендации по освоению.
1. Введение
1.1 Область применения
ПРИМЕР СОДЕРЖАНИЯ:
Наполнение данного раздела можно взять из документа «Техническое задание, п.п.2.1».
1.2 Краткое описание возможностей
ПРИМЕР СОДЕРЖАНИЯ:
Наполнение данного раздела можно взять из документа «Описание автоматизируемых функций, п.п.2.».
1.3 Уровень подготовки пользователя
ПРИМЕР СОДЕРЖАНИЯ:
Наполнение данного раздела можно взять из документа «Техническое задание, п.п.4.1.2 Требования к численности и квалификации персонала системы»
1.4 Перечень эксплуатационной документации
ПРИМЕР СОДЕРЖАНИЯ:
Перечень эксплуатационных документов, с которым необходимо ознакомиться:
— АС Кадры. «Руководство администратора»;
— АС Кадры. «Руководство пользователя»;
— т.д.
— пр.;
2 НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ
УКАЗАНИЯ ГОСТ:
В разделе «Назначение и условия применения» указывают:
1) виды деятельности, функции, для автоматизации которых предназначено данное средство автоматизации;
2) условия, при соблюдении (выполнении, наступлении) которых обеспечивается применение средства автоматизации в соответствии с назначением (например, вид ЭВМ и конфигурация технических средств, операционная среда и общесистемные программные средства, входная информация, носители данных, база данных, требования к подготовке специалистов и т. п.).
ПРИМЕР СОДЕРЖАНИЯ:
2.1 Виды деятельности, функции
ПРИМЕР СОДЕРЖАНИЯ:
АС Кадры предназначена для автоматизации следующих видов деятельности:
Наполнение раздела можно взять в документе «Описание автоматизируемых функций, раздел ЦЕЛИ АС И АВТОМАТИЗИРУЕМЫЕ ФУНКЦИИ».
2.2 Программные и аппаратные требования к системе
ПРИМЕР СОДЕРЖАНИЯ:
Пример требований к программному обеспечению приведен в документе «Пояснительная записка, п.п.3.10».
Пример требований к аппаратному обеспечению приведен в документе «Техническое задание, п.п.4.3.5».
3 ПОДГОТОВКА К РАБОТЕ
УКАЗАНИЯ ГОСТ:
В разделе «Подготовка к работе» указывают:
1) состав и содержание дистрибутивного носителя данных;
2) порядок загрузки данных и программ;
3) порядок проверки работоспособности.
3.1 Состав дистрибутива
ПРИМЕР СОДЕРЖАНИЯ:
В состав дистрибутива АС Кадры входит:
— СУБД Oracle 10.2g;
— Приложение установки базы данных;
— Серверная часть Windows приложения АС Кадры;
— Клиентская часть Windows приложения;
— т.д.;
— пр.
3.2 Запуск системы
ПРИМЕР СОДЕРЖАНИЯ:
Предварительно необходимо выполнить установку системы. Информацию об установке системы можно получить в документе РД И3(А) АС Кадры, который входит в состав проектной документации.
1. Для того, чтобы запустить АС Кадры, откройте папку, в которую была установлена программа, и запустите файл kadry.exe.
2. В открывшемся окне заполните следующие поля в области окна Общие параметры:
— Логин — логин (логическое имя) пользователя;
— Пароль — пароль для входа в систему;
3. т.д.
пр.
3.3 Проверка работоспособности системы
ПРИМЕР СОДЕРЖАНИЯ:
Программное обеспечение работоспособно, если в результате действий пользователя, изложенных в п.п.3.2, на экране монитора отобразилось главное окно клиентского приложения без выдачи пользователю сообщений о сбое в работе.
4 ОПИСАНИЕ ОПЕРАЦИЙ
УКАЗАНИЯ ГОСТ:
В разделе «Описание операций» указывают:
1) описание всех выполняемых функций, задач, комплексов задач, процедур;
2) описание операций технологического процесса обработки данных, необходимых для выполнения функций, комплексов задач (задач), процедур.
Для каждой операции обработки данных указывают:
1) наименование;
2) условия, при соблюдении которых возможно выполнение операции;
3) подготовительные действия;
4) основные действия в требуемой последовательности;
5) заключительные действия;
6) ресурсы, расходуемые на операцию.
В принципе, допускается в пределах разумного описывать операции без перечисления всех приведенных выше пунктов.
4.1 Наименование операции
ПРИМЕР СОДЕРЖАНИЯ:
Просмотр справочной информации.
4.2 Условия выполнения операции
ПРИМЕР СОДЕРЖАНИЯ:
Приложение запущено, успешно функционирует, не выполняет никакх операций, блокирущих доступ к пунктам меню.
4.3 Подготовительные действия
ПРИМЕР СОДЕРЖАНИЯ:
Отсутствуют.
4.4 Основные действия
ПРИМЕР СОДЕРЖАНИЯ:
Открыть пункт меню «Помощь», выбрать раздел «Справка». Появится всплывающее окно, содержащее разделы со справкой.
4.5 Заключительные действия
ПРИМЕР СОДЕРЖАНИЯ:
После завершения работы со справочной информацией, закрыть вплывающее окно со справкой.
4.6 Ресурсы, расходуемые на операцию
ПРИМЕР СОДЕРЖАНИЯ:
Отсутствуют.
5 АВАРИЙНЫЕ СИТУАЦИИ. ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ
УКАЗАНИЯ ГОСТ:
В разделе «Аварийные ситуации» указывают:
1) действия в случае несоблюдения условий выполнения технологического процесса, в том числе при длительных отказах технических средств;
2) действия по восстановлению программ и/или данных при отказе магнитных носителей или обнаружении ошибок в данных;
3) действия в случаях обнаружении несанкционированного вмешательства в данные;
4) действия в других аварийных ситуациях
ПРИМЕР СОДЕРЖАНИЯ:
При сбое в работе аппаратуры восстановление нормальной работы системы должно производиться после:
— перезагрузки операционной системы;
— запуска исполняемого файла системы;
При ошибках в работе аппаратных средств (кроме носителей данных и программ) восстановление функции системы возлагается на ОС.
При ошибках, связанных с программным обеспечением (ОС и драйверы устройств), восстановление работоспособности возлагается на ОС.
При неверных действиях пользователей, неверных форматах или недопустимых значениях входных данных, система выдает пользователю соответствующие сообщения, после чего возвращается в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных.
6 РЕКОМЕНДАЦИИ ПО ОСВОЕНИЮ
УКАЗАНИЯ ГОСТ:
В разделе «Рекомендации по освоению» указывают рекомендации по освоению и эксплуатации, включая описание контрольного примера, правила его запуска и выполнения.
ПРИМЕР СОДЕРЖАНИЯ:
Для успешного освоения приложения АС Кадры необходимо иметь навыки работы с ПК и изучить следующее:
— Нормативно-правовую базу по вопросам управления государсвенными кадрами;
— Раздел «Описание процесса деятельности» документа «Пояснительная записка (Технический проект)»;
— Раздел «Описание автоматизируемых функций» документа «Пояснительная записка (Технический проект)»;
— Настоящее «Руководство пользователя».
Контрольный пример работы с системой
Ниже рассмотрен пример работы с системой, начиная с ее запуска и заканчивая оформлением документов:
1. Запустите систему.
2. т.д.
3. пр.
Подборка по базе: организация как управляемая система.docx, Бюджетная система РФ Контрольная работа.doc, ЛПР МДК 05. 01 Проектирование и дизайн информационных систем.doc, «Внедрение цифровой информационной системы ФГИС «Моя школа» как , Сигнальные системы Павлова..docx, Реферат_уровневая система образования в РФ.docx, Теория информационных процессов и систем копия.pdf, Практическая работа № 2 (Часть 1) Раздел программы_ 2.1.4. Объек, Оценка системы материальной и нематериальной мотивации туристиче, Россия в системе международных отношений.docx
8. РАБОЧАЯ ДОКУМЕНТАЦИЯ
В состав рабочей, или иначе эксплуатационной, документации входят руководство пользователя, руководство оператора, руководство администратора, руководство системного администратора, руководство программиста, руководство системного программиста.
8.1. Руководство пользователя
Основной целью руководства пользователя является обеспечение пользователя необходимой информацией для самостоятельной работы с программой или автоматизированной системой. Поэтому руководство пользователя должно отвечать на вопросы:
что это за программа (система)?
что может программа (система)?
что необходимо для обеспечения корректного функционирования программы (системы)?
что делать в случае отказа системы?
При составлении наиболее подробного руководства пользователя можно придерживаться следующей структуры:
1. Введение
Данный раздел должен предоставлять пользователю общую информацию о программе (системе). В нем указывают:
область применения;
краткое описание возможностей;
уровень подготовки пользователя.
51
2. Перечень эксплуатационной документации
В данном разделе перечисляется документация, которая позволит пользователю избежать определенного рода ошибок.
3. Назначение и условия применения
Раздел подразделяет основную задачу программы (системы) на подзадачи и описывает каждую из них. В нем указывают:
виды деятельности, функции, для автоматизации которых предназначено данное средство автоматизации;
условия, при соблюдении (выполнении, наступлении) которых обеспечивается применение средства автоматизации в соответствии с назначением (например, вид ЭВМ и конфигурация технических средств, операционная среда и общесистемные программные средства, входная информация, носители данных, база данных, требования к подготовке специалистов и т. п.).
4. Подготовка к работе
Данный раздел должен содержать пошаговую инструкцию для запуска программы (системы). К этапу подготовки системы к работе можно отнести установку дополнительных приложений, идентификацию, аутентификацию. В данном разделе указывают:
состав и содержание дистрибутивного носителя данных;
порядок загрузки данных и программ.
5. Проверка работоспособности
В разделе описываются показатели, по которым можно определить, что программное обеспечение работает нестабильно.
6. Описание операций
Это основной раздел, который содержит пошаговую инструкцию для выполнения того или иного действия пользователем. Если работа
52 автоматизированной системы затрагивает целый бизнес-процесс, то в руководстве пользователя перед описанием операций целесообразно предоставить информацию о данном процессе, его назначении и участниках. Подобное решение позволяет человеку четко представить свою роль в данном процессе и те функции, которые реализованы для него в системе. Далее в руководстве пользователя следует представить описание функций, разбитых на отдельные операции.
Необходимо выделить подразделы, описывающие функции данного процесса, и действия, которые необходимо совершить для их выполнения:
описание всех выполняемых функций, задач, комплексов задач, процедур;
описание операций технологического процесса обработки данных, необходимых для выполнения функций, задач, процедур.
7. Аварийные ситуации
В разделе описываются действия в случае длительных отказов технических средств, обнаружении несанкционированного вмешательства в данные, действия по восстановлению программ или данных.
8.2. Руководство оператора
Нормативной базой для составления данного документа может являться ГОСТ 19.505-79 «ЕСПД. Руководство оператора. Требования к содержанию и оформлению», в котором выделяются следующие разделы:
назначение программы (сведения о назначении программы и информация, достаточная для понимания функций программы и ее эксплуатации);
53
условия выполнения программы (минимальный и/или максимальный состав аппаратурных и программных средств и т. д.);
выполнение программы
(последовательность действий оператора, обеспечивающих загрузку, запуск, выполнение и завершение программы, описание функций, формата и возможных вариантов команд, с помощью которых оператор осуществляет загрузку и управляет выполнением программы, а также ответы программы на эти команды);
сообщения оператору (тексты сообщений, выдаваемых в ходе выполнения программы, описание их содержания и соответствующие действия оператора в случае сбоя, возможности повторного запуска программы и т. п.).
В зависимости от особенностей документа допускается объединять отдельные разделы или вводить новые. Допускается содержание разделов иллюстрировать поясняющими примерами, таблицами, схемами, графиками.
В общем случае руководство оператора отличается от руководства пользователя. В руководстве оператора все процессы, выполняемые программным обеспечением, рассматриваются с технической точки зрения. Исходя из этого, можно представить альтернативную структуру данного руководства:
1. Установка на сервер
В разделе описывается процесс установки программного обеспечения на сервер. Пошаговая инструкция дает точные указания, каким образом необходимо выполнить установку, в зависимости от технического состояния сервера.
54
2. Установка локальная
В разделе описывается процесс настройки компьютеров, использующих программное приложение, также даются рекомендации по оптимизации настройки рабочих станций, чтобы улучшить процесс взаимодействия сервера и компьютеров пользователей.
3. Администрирование пользователей
В разделе подробно описывается процесс администрирования учетных записей пользователей программного обеспечения.
Подробная инструкция описывает все ситуации, которые могут возникнуть при управлении пользователями. Например, можно централизованно завершать все активные соединения с информационной базой и устанавливать блокировку новых соединений на определенный период времени. Такая возможность полезна при выполнении различных административных действий с информационной базой.
4. Информационная база
В разделе рассматриваются вопросы администрирования, сохранения, переноса базы данных. Описаны рекомендации по настройке базы данных. Например, рассматривается ситуация резервного копирования. Резервное копирование может выполняться как в автоматическом режиме, так и в ручном. Для автоматического режима предварительно необходимо выполнить настройки. В любой момент можно восстановить данные информационной базы из созданной ранее резервной копии.
5. Технические неполадки
Этот раздел содержит информацию о возможных технических проблемах, которые могут возникнуть в процессе эксплуатации программного обеспечения.
Рассматриваются проблемы, возникающие в результате некорректной работы оборудования, а
55 также ситуации, возникающие в результате некорректного использования функций программного обеспечения.
6. Программный код
В разделе подробно описывается структура программного кода.
Если в процессе использования программного обеспечения возникают ошибки или потребуется доработка, то для этого необходимо знать программный код. Указываются особенности программного кода, создающие затруднения в процессе доработки. Раздел является очень важным, так как может потребоваться добавить, удалить или изменить определенные функции программного обеспечения.
8.3. Руководство администратора
Обычно администратор считается пользователем системы, при этом он наделен как особыми обязанностями, так и необходимыми для их выполнения привилегиями. По методике и стилю изложения руководство администратора похоже на руководство пользователя.
При этом, как правило, описание в нем строится от задач, а не от функций.
Работа администратора многопользовательской системы, как правило, заключается в управлении учетными записями других пользователей, предоставлении им полномочий на доступ к данным и выполнение операций, а также в исправлении сделанных ими ошибок.
Например, бывают автоматизированные системы, в которых вводить и редактировать данные может любой пользователь, а удалять – только администратор. Кроме того, администратор может заниматься ведением нормативно-справочной информации, загрузкой и выгрузкой данных, открытием и закрытием расчетных периодов и т. п. С этой точки зрения руководство администратора является системным документом и приобретает смысл только в условиях конкретной системы с живыми пользователями.
56
Системы часто создаются на основе тиражируемых программных продуктов или аппаратно-программных комплексов. В составе таких решений нередко поставляется программный компонент под названием «Администратор», предназначенный для управления системой после ее развертывания.
Структура руководства администратора существенным образом зависит от того, как устроена система, и какого обслуживания она требует.
Типичная структура руководства администратора системы следующая:
1. Назначение системы
2. Принципы функционирования системы
3. Обязанности и задачи администратора
4. Обслуживание системы
настройка параметров работы системы;
ведение нормативно-справочной информации;
учетные записи пользователей и управление ими;
назначение пользователям прав доступа;
загрузка и выгрузка данных.
5. Проблемы в работе системы и способы их решения
Руководство по административному модулю программного или программно-аппаратного комплекса содержит примерно те же сведения, но в более общем виде. Например, в нем должно быть объяснено, как создать учетную запись пользователя, но не может быть указано, когда это следует делать. Такая конкретика возникает только при внедрении продукта в некотором конкретном месте и отражается в технологических инструкциях или регламентах.
57
Структура руководства по административному модулю программного или аппаратно-программного комплекса может иметь следующий вид:
1. Общие сведения о комплексе
2. Функционирование комплекса в рамках системы
(рассматриваются несколько наиболее типичных случаев применения комплекса и перечисляются основные обязанности администратора в каждом из них)
3. Интерфейс пользователя административного модуля
4. Задачи по обслуживанию
настройка параметров работы системы;
ведение нормативно-справочной информации;
учетные записи пользователей и управление ими;
назначение пользователям прав доступа;
загрузка и выгрузка данных.
5. Типичные проблемы в работе и способы их решения
Руководство администратора не следует путать с руководством системного администратора. Первый документ говорит о том, как организовать и поддерживать целевое применение системы, второй – как обеспечить ее техническую работоспособность.
8.4. Руководство системного администратора
Руководство системного администратора – вспомогательный документ для прикладных программных продуктов и основной для серверных и системных, не имеющих непосредственных пользователей.
В случае небольших «монолитных» программ руководство системного администратора может оказаться документом небольшим
58 по объему и простым по структуре. Руководство системного администратора на программный или аппаратно-программный комплекс, как правило, ощутимо сложнее, поскольку в нем приходится описывать каждый компонент по отдельности и способы их интеграции как друг с другом, так и со сторонним программным обеспечением: серверами баз данных, почтовыми серверами, антивирусами, средствами шифрования и пр.
В руководстве системного администратора должны быть изложены:
назначение и область применения программы (или комплекса);
состав программы, основные принципы ее функционирования;
комплект поставки (если он не указан в отдельном документе);
системные требования для программы или ее компонентов;
предпочтительная очередность установки компонентов;
процедура установки программы или каждого ее компонента;
порядок обязательной первоначальной настройки программы;
способы интеграции установленных копий компонентов между собой;
интеграция программы со сторонним ПО, например, с сервером базы данных;
способы и периодичность контроля правильности работы программы;
порядок текущего обслуживания работающих копий программы;
59
порядок решения всевозможных вспомогательных задач;
аварийные ситуации и способы их устранения.
Кроме того, в руководстве системного администратора могут быть описаны:
пользовательский интерфейс административной консоли;
утилиты командной строки и синтаксис их запуска;
конфигурационные файлы и правила их написания;
язык для составления управляющих скриптов.
Все зависит от того, какие средства для установки и настройки программы реализовали ее разработчики, какие именно инструменты есть у системного администратора.
Методика изложения материала в руководстве системного администратора сильно зависит от того, каким образом программой можно управлять. Если большинство задач решается через административную консоль с графическим интерфейсом, то документ будет больше похож на руководство пользователя или руководство администратора. Если системному администратору придется составлять конфигурационные файлы и писать скрипты, документ будет ближе к руководству программиста.
Приблизительная структура руководства системного администратора следующая:
1. Общие сведения о программе (комплексе)
2. Архитектура и принципы функционирования
3. Системные требования
4. Установка программы (комплекса)
5. Административная консоль и работа с ней
60
6. Файл конфигурации. Составление и правка
7. Обязательная
начальная
настройка
программы
(комплекса)
8. Проверка правильности функционирования программы
(комплекса)
9. Мероприятия по текущему обслуживанию программы
(комплекса)
10. Оптимизация работы программы (комплекса)
11. Аварийные ситуации и способы их устранения
Объем и особенности изложения информации в руководстве системного администратора зависят от используемых технических средств (ПК, серверных комплексов, планшетов, периферийных устройств и т. д.), применяемого программного обеспечения и решаемых с его помощью конкретных задач.
8.5. Руководство программиста
Программист – это специалист, который занимается разработкой алгоритмов и компьютерных программ на основе специальных математических моделей. Прикладные программисты занимаются в основном разработкой программного обеспечения прикладного характера, а также в их обязанности входит адаптация уже существующих программ под нужды отдельно взятой организации или пользователя.
Нормативной базой для составления данного документа может являться ГОСТ 19.504-79 «ЕСПД. Руководство программиста.
Требования к содержанию и оформлению», в котором выделяются следующие разделы:
61
назначение и условия применения программы (назначение и функции, выполняемые программой, объем оперативной памяти, требования к составу и параметрам периферийных устройств, требования к программному обеспечению и т. п.);
характеристики программы (временные характеристики, режим работы, средства контроля правильности выполнения и самовосстанавливаемости программы и т. п.);
обращение к программе (описание процедур вызова программы, способы передачи управления и параметров данных и др.);
входные и выходные данные (описание организации используемой входной и выходной информации и, при необходимости, ее кодирования);
сообщения (тексты сообщений, выдаваемых программисту или оператору в ходе выполнения программы, описание их содержания и действия, которые необходимо предпринять по этим сообщениям).
В зависимости от особенностей документа допускается объединять отдельные разделы или вводить новые. В приложении к руководству программиста могут быть приведены дополнительные материалы (примеры, иллюстрации, таблицы, графики и т. п.).
8.6. Руководство системного программиста
Системный программист – это разработчик операционных систем, программных комплексов, обеспечивающих слаженную работу компонентов компьютера, который практически не занимается прикладными программами. Системный программист выстраивает многоуровневую структуру, которая объединяет отдельные компоненты
(работу процессора, сетевого оборудования,
62 оперативную память, выполнение прикладных программ и пр.) в модули, а модули – в компьютерную сеть.
Нормативной базой для составления данного документа может являться ГОСТ 19.503-79 «ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению», в котором выделяются следующие разделы:
общие сведения о программе (назначение и функции программы и сведения о технических и программных средствах, обеспечивающих выполнение данной программы);
структура программы (сведения о структуре программы, ее составных частях, о связях между составными частями и о связях с другими программами);
настройка программы (описание действий по настройке программы на состав технических средств, выбор функций и др.);
проверка программы
(описание способов проверки, позволяющих дать общее заключение о работоспособности программы: контрольные примеры, методы прогона, результаты);
дополнительные возможности (описание дополнительных разделов функциональных возможностей программы и способов их выбора);
сообщения системному программисту (тексты сообщений, выдаваемых в ходе выполнения настройки, проверки программы, а также в ходе выполнения программы, описание их содержания и действий, которые необходимо предпринять по этим сообщениям).
63
В зависимости от особенностей документа допускается объединять отдельные разделы или вводить новые. В приложении к руководству системного программиста могут быть приведены дополнительные материалы (примеры, иллюстрации, таблицы, графики и т. п.).
Вопросы для самоконтроля:
1. Для чего необходимо руководство пользователя?
2. Чем руководство оператора отличается от руководства пользователя?
3. Что включает в себя руководство программиста?
РД
50-34.698-90 Руководство пользователя (пример
оформления)
Ниже
представлен пример (образец) документа
«Руководство
пользователя«,
разработанного на основании методических
указаний РД
50-34.698-90.
Данный
документ формируется IT-специалистом,
или функциональным специалистом, или
техническим писателем в ходе разработки
рабочей документации на систему и её
части на стадии «Рабочая документация».
Для
формирования руководства пользователя
в качестве примера был взят инструмент
Oracle
Discoverer
информационно-аналитической системы
«Корпоративное хранилище данных».
Ниже
приведен состав руководства пользователя
в соответствии с ГОСТ. Внутри каждого
из разделов кратко приведены
требования к содержанию и текст примера
заполнения
(выделен вертикальной чертой).
Разделы
руководства пользователя:
-
Введение.
-
Назначение
и условия применения. -
Подготовка
к работе. -
Описание
операций. -
Аварийные
ситуации. -
Рекомендации
по освоению.
В
разделе «Введение» указывают:
-
область
применения; -
краткое
описание возможностей; -
уровень
подготовки пользователя; -
перечень
эксплуатационной документации, с
которой необходимо ознакомиться
пользователю.
1.1. Область применения
Требования
настоящего документа применяются при:
-
предварительных
комплексных испытаниях; -
опытной
эксплуатации; -
приемочных
испытаниях; -
промышленной
эксплуатации.
1.2. Краткое описание возможностей
Информационно-аналитическая
система Корпоративное Хранилище Данных
(ИАС КХД) предназначена для оптимизации
технологии принятия тактических и
стратегических управленческих решений
конечными бизнес-пользователями на
основе информации о всех аспектах
финансово-хозяйственной деятельности
Компании.
ИАС
КХД предоставляет возможность работы
с регламентированной и нерегламентированной
отчетностью.
При
работе с отчетностью используется
инструмент пользователя Oracle Discoverer Plus,
который предоставляет следующие
возможности:
-
формирование
табличных и кросс-табличных отчетов; -
построение
различных диаграмм; -
экспорт
и импорт результатов анализа; -
печать
результатов анализа; -
распространение
результатов анализа.
1.3. Уровень подготовки пользователя
Пользователь
ИАС КХД должен иметь опыт работы с ОС
MS Windows (95/98/NT/2000/XP), навык работы с ПО
Internet Explorer, Oracle Discoverer, а также обладать
следующими знаниями:
-
знать
соответствующую предметную область; -
знать
основы многомерного анализа; -
понимать
многомерную модель соответствующей
предметной области; -
знать
и иметь навыки работы с аналитическими
приложениями.
Квалификация
пользователя должна позволять:
-
формировать
отчеты в Oracle Discoverer Plus; -
осуществлять
анализ данных.
1.4. Перечень эксплуатационной документации, с которой необходимо ознакомиться пользователю
-
Информационно-аналитическая
система «Корпоративное хранилище
данных». ПАСПОРТ; -
Информационно-аналитическая
система «Корпоративное хранилище
данных». ОБЩЕЕ ОПИСАНИЕ СИСТЕМЫ.
2. Назначение и условия применения Oracle Discoverer Plus
В
разделе «Назначение и условия
применения» указывают:
-
виды
деятельности, функции, для автоматизации
которых предназначено данное средство
автоматизации; -
условия,
при соблюдении (выполнении, наступлении)
которых обеспечивается применение
средства автоматизации в соответствии
с назначением (например, вид ЭВМ и
конфигурация технических средств,
операционная среда и общесистемные
программные средства, входная информация,
носители данных, база данных, требования
к подготовке специалистов и т. п.).
Oracle
Discoverer Plus в составе ИАС КХД предназначен
для автоматизации подготовки, настройки
отчетных форм по показателям деятельности,
а также для углубленного исследования
данных на основе корпоративной информации
хранилища данных.
Работа
с Oracle Discoverer Plus в составе ИАС КХД возможна
всегда, когда есть необходимость в
получении информации для анализа,
контроля, мониторинга и принятия решений
на ее основе.
Работа
с Oracle Discoverer Plus в составе ИАС КХД доступна
всем пользователям с установленными
правами доступа.
Соседние файлы в папке TZ
- #
- #
- #
- #
- #
- #
- #
Всем доброго времени суток, кто решил прочитать статью, посвященную документации. Здесь вы найдёте как общие, так и довольно специфические советы по созданию руководства пользователя. Надеюсь, они будут вам полезны.
Приятного чтения.
Если перед вами стоит вопрос – нужно ли вашему продукту пользовательское руководство, то отвечу сразу – да, нужно. Почему? На это есть две причины:
1. Качественная документация повышает лояльность клиента и ценность продукта в целом.
Как это не странно, но люди до сих пор читают пользовательскую документацию. Конечно, не просто так, а когда сталкиваются с проблемой. И если с руководством все хорошо, то пользователь быстро найдет ответ на свой вопрос – это будет ещё один балл в копилку вашего проекта!
2. Руководство пользователя экономит время и силы техподдержки.
Данный факт напрямую зависит от первого. Если документация качественная, то пользователи будут редко обращаться в техподдержку, и ваша команда будет работать с действительно нестандартными ситуациями. Ну а если руководство «так себе», то поддержка будет завалена однотипными вопросами. Из-за этого пользователям придется дольше ждать ответа, поддержке больше работать, а это в свою очередь будет злить как пользователя, так и команду.
А теперь к советам!
Общие советы по созданию руководства пользователя
Прежде чем начинать писать руководство пользователя нужно ответить на несколько вопросов. — Для кого вы пишите? Кто будет пользоваться файлом справки? (ваша целевая аудитория)
— Где скорее всего пользователи будут прибегать к документации? (дома, на работе, в машине)
— Насколько объективно сложен для понимания продукт и как часто пользователь будет обращаться к документации?
И так, вы ответили на эти вопросы и теперь можете сделать вывод какого размера документация вам нужна, какой стиль изложения в ней использовать, и как часто пользователь будет читать документ.
(Для изложения лучше всего выбрать нейтрально-формальный стиль)
Структура руководства пользователя
У любого качественной документации продуманная и логичная структура. Представьте, что вы сами работаете в программе и сталкиваетесь с проблемой. Открываете файл справки – а там просто сплошной текст. Такая документация вам не поможет.
Создайте оглавление, которое будет началом вашего руководства. Оно поможет вам в дальнейшем написании документации, а также поможет пользователю ориентироваться в тексте.
В первом разделе расскажите общую информацию о продукте. Для чего создан проект и какие задачи он решает.
Во второй «главе» укажите основные элементы интерфейса. Клиент вряд ли сможет достичь своей цели в программе, если не будет знать для чего служат различные детали интерфейса. Объясните предназначение всех окон, кнопок и так далее.
Дальше расскажите, как эффективно пользоваться программой. Какие задачи стоят перед пользователем и как продукт быстро их решает.
В любом руководстве желательны разделы «Частые вопросы» и «Устранение типовых проблем». Расскажите о проблемах, с которыми часто сталкиваются клиенты и о путях их решения.
Информацию для этого раздела лучше брать у техподдержки. Проанализируйте, какие вопросы задаются чаще всего и ответьте на них один раз максимально информативно.
И последний «обязательный» раздел, которой точно должен быть в любой документации – «контактная информация». Данный раздел даст пользователю возможность связаться с разработчиком. Если руководство вдруг не закрывает потребность читателя, то он может обратиться в поддержку. Кроме того, клиент может дать совет, поделиться опытом или предложить выгодное вам сотрудничество.
Профессиональный совет: если вы хотите максимально облегчить ношу клиента при чтении документации создайте контекстно-зависимую справку. Что это такое?
Представьте, что вы работаете в программе для создания пользовательской документации. Открываете меню основных настроек и видите раздел «аннотирование экрана» Заходите в него, там показаны разные стили аннотации, тени, фон и так далее. Но что такое аннотация? Допустим вы не знаете — нажимаете кнопку F1 и перед вами открывается руководство именно на той странице, где рассказано об «аннотировании экрана»
Как ее сделать? Смотрите ниже.
Контент
И так, мы создали «каркас» нашей документации, но чтобы руководство стало полезным нужно наполнить её компетентной информацией.
Конкретного совета дать невозможно, так как все продукты разные. Поэтому расскажу про общие положения, которые делают документацию лучше.
1. Понятность.
Помните, что руководство будут читать люди, которые не сильно знакомы с вашим продуктом. Пишите простым языком, избегайте профессиональных терминов. Руководство пользователя должно быть написано на языке этого самого пользователя, а не на языке писателя.
2. Наглядность.
Добавляйте в руководство побольше графики и скриншотов с аннотациями. Читателю будет проще и приятнее решать проблему, если будет наглядно показано как это делать.
3. Видео.
Лучше один раз увидеть, чем сто раз услышать. Продемонстрируйте пользователю последовательность действий для достижения конкретной цели. Документация, содержащая видео вставки будет пользоваться большей популярностью, чем обычный текстовый документ.
Но как добавить в документацию видео? Смотрите ниже.
Больше советов!
Когда документация будет готова, чтобы она стала «полноценной» её нужно опубликовать. Иначе какой от неё толк, если клиент не может её прочитать. У «юзера» всегда должен быть доступ к документации, и не важно где он. Такую потребность легко закрывают три формата: HTML, PDF и CHM.
Создайте файл справки и загрузите его прямо в вашу программу в формате CHM. Таким образом, у пользователя будет возможность открыть документ, не выходя из программы. Не забудьте добавить элемент вызывающий руководство в меню программы.
Выложите руководство на сайт в формате HTML, чтобы клиент мог обратиться к документации, даже не работая с программой. Кроме того, документация, выложенная на сайт, повышает SEO факторы сайта.
И напоследок, переведите пользовательскую документацию в формат PDF, чтобы клиенты могли скачать и распечатать руководство.
Но помните, что после публикации документации, придется иногда её обновлять.
Инструменты
Для того, чтобы написать, а затем опубликовать документацию одного Wordа не хватит, но и пользоваться большим количеством программ тоже не хочется.
Ну и пользуясь случаем, я хочу рассказать про проект, в котором я работаю уже много лет и который закрывает все потребности писателей пользовательской документации.
Dr.Explain – программа для создания руководств пользователя для ПО, web-сервисов и баз знаний.
Благодаря «доктору» вы сможете опубликовать и обновлять документацию в востребованных форматах (CHM; HTML; PDF; DOC), не выходя из программы.
В программе есть шаблоны документации, ведь по образцу работать проще.
Импортируйте в программу заранее написанные фрагменты документации.
Вы сможете создать контекстно-зависимую документацию, настроить визуальный стиль руководства, добавить в него видео и многое другое!
Какой можно сделать вывод
Если вы хотите создать по-настоящему хорошую документацию – придется потрудиться, потому что это займет много времени и усилий всей команды. Но игра стоит свеч, так как после этого вы получите лояльных и довольных клиентов.
Руководство пользователя должно стать персональным гидом по продукту для клиента. Если пользователь останется недовольным после работы с документацией, то это может повлиять на решение отказаться от продукта.
Работая с Dr.Explain, можно быстро написать пользовательскую документацию, которая будет помогать клиентам разбираться в продукте, а вам позволит сосредоточить свои силы на более важных задачах — разработке и продвижении программного продукта.
Спасибо за внимание!
Со всеми возможностями Dr.Explain можно ознакомиться здесь:
Руководство пользователя – это основной документ в составе эксплуатационной документации на автоматизированную систему (ГОСТ 34). Очевидно ли это?
Назначение руководства пользователя
Цель создания документа заключается в том, чтобы предоставить пользователю возможность самостоятельно решать свои прикладные задачи с помощью системы. Этой цели может служить и введение в предметную область, и ознакомление со всеми возможностями программы, и описание конкретных процедур решения задач, и приведение различных инструкций. Иногда Руководство пользователя больше похоже на справочник, к которому можно обращаться в процессе работы, а иногда – на учебник, который позволяет изучить принципы работы с программой и ее возможности, а затем применять их на практике.
Состав типового руководства пользователя
Конкретный подход к написанию определяется многими факторами:
– назначением программы и областью ее применения;
– сложностью программы;
– количеством разнообразных вариантов использования.
Принимая во внимание все различия и особенности, сложно привести структуру любого Руководства пользователя к одному виду. Тем не менее, РД 50-34.698 предлагает нам такой список разделов:
– Введение, где указывают область применения ПО, краткое описывают его возможности, требуемый уровень знаний пользователя и список документов, которые необходимо изучить помимо настоящего руководства;
– Назначение и условия применения, где описывают виды деятельности и функции, которые автоматизированы и условия, при соблюдении которых автоматизация используется;
– Подготовка к работе, где описывают комплектность дистрибутива, порядок установки и загрузки программы, а также способ проверки ее работоспособности;
– Описание операций, представляет собой основной раздел, где описывают функции программы, процессы работы с данными, выполнение конкретных задач пользователя;
– Аварийные ситуации, где описывают действия в нештатных ситуациях – сбоях в программе, ошибок в данных и т.д.;
– Рекомендации по освоению, где приводят методические рекомендации по изучению программы и примеры использования.
Данная структура может меняться и дополняться – например, основной раздел часто разбивают на несколько значимых разделов по группам функций или задач, также в современных системах нередко добавляют раздел Интерфейс пользователя, где описывают взаимодействие пользователя с программой с примерами и снимками экрана.
Стандарты для руководства пользователя
Наличие Руководства пользователя регламентируется ГОСТ 34.201, а структура и содержание – РД 50-34.698. Однако, в зависимости от сложности, назначения и области применения ПО, различные Руководства пользователя могут отличаться друг от друга по способу, методике и стилю изложения.
Стоимость разработки руководства пользователя
Наименование документа |
Наименование стандарта |
Стоимость разработки |
---|---|---|
РП на автоматизированную систему |
РД 50-34.698 |
70 тыс. р. |
Грамотно написанное Руководство пользователя может сэкономить значительное количество времени на обучение и адаптацию пользователя к программе, а также снизить количество ошибок в работе что, в свою очередь, повышает экономическую эффективность системы. Если вы не хотите вникать во все тонкости создания Руководства пользователя, но хотите иметь полный, качественный и полезный документ – обратитесь в компанию ТехРайтКонсалт, и мы применим весь наш опыт и знания для решения вашей задачи по доступной цене!
Возможно, вас также заинтересует:
– разработка руководства администратора;
– создание руководства программиста;
– разработка руководства оператора.
Руководство пользователя – это основной документ в составе эксплуатационной документации на автоматизированную систему (ГОСТ 34). Очевидно ли это?
Назначение руководства пользователя
Цель создания документа заключается в том, чтобы предоставить пользователю возможность самостоятельно решать свои прикладные задачи с помощью системы. Этой цели может служить и введение в предметную область, и ознакомление со всеми возможностями программы, и описание конкретных процедур решения задач, и приведение различных инструкций. Иногда Руководство пользователя больше похоже на справочник, к которому можно обращаться в процессе работы, а иногда – на учебник, который позволяет изучить принципы работы с программой и ее возможности, а затем применять их на практике.
Состав типового руководства пользователя
Конкретный подход к написанию определяется многими факторами:
– назначением программы и областью ее применения;
– сложностью программы;
– количеством разнообразных вариантов использования.
Принимая во внимание все различия и особенности, сложно привести структуру любого Руководства пользователя к одному виду. Тем не менее, РД 50-34.698 предлагает нам такой список разделов:
– Введение, где указывают область применения ПО, краткое описывают его возможности, требуемый уровень знаний пользователя и список документов, которые необходимо изучить помимо настоящего руководства;
– Назначение и условия применения, где описывают виды деятельности и функции, которые автоматизированы и условия, при соблюдении которых автоматизация используется;
– Подготовка к работе, где описывают комплектность дистрибутива, порядок установки и загрузки программы, а также способ проверки ее работоспособности;
– Описание операций, представляет собой основной раздел, где описывают функции программы, процессы работы с данными, выполнение конкретных задач пользователя;
– Аварийные ситуации, где описывают действия в нештатных ситуациях – сбоях в программе, ошибок в данных и т.д.;
– Рекомендации по освоению, где приводят методические рекомендации по изучению программы и примеры использования.
Данная структура может меняться и дополняться – например, основной раздел часто разбивают на несколько значимых разделов по группам функций или задач, также в современных системах нередко добавляют раздел Интерфейс пользователя, где описывают взаимодействие пользователя с программой с примерами и снимками экрана.
Стандарты для руководства пользователя
Наличие Руководства пользователя регламентируется ГОСТ 34.201, а структура и содержание – РД 50-34.698. Однако, в зависимости от сложности, назначения и области применения ПО, различные Руководства пользователя могут отличаться друг от друга по способу, методике и стилю изложения.
Стоимость разработки руководства пользователя
Наименование документа |
Наименование стандарта |
Стоимость разработки |
---|---|---|
РП на автоматизированную систему |
РД 50-34.698 |
70 тыс. р. |
Грамотно написанное Руководство пользователя может сэкономить значительное количество времени на обучение и адаптацию пользователя к программе, а также снизить количество ошибок в работе что, в свою очередь, повышает экономическую эффективность системы. Если вы не хотите вникать во все тонкости создания Руководства пользователя, но хотите иметь полный, качественный и полезный документ – обратитесь в компанию ТехРайтКонсалт, и мы применим весь наш опыт и знания для решения вашей задачи по доступной цене!
Возможно, вас также заинтересует:
– разработка руководства администратора;
– создание руководства программиста;
– разработка руководства оператора.
После
запуска программы Access
автоматически открывается титульный
лист «Базы данных», который предусматривает
использование АРМ двумя типами работников:
«Начальник» и «Операторы».
Рассмотрим
работу начальника. После нажатия
соответствующей кнопки, начальник
попадает в меню проверки, которое
включает в себя написание фамилии и
пароля.
Если
фамилия и пароль неверны, дальнейший
доступ к ресурсам базы данных исключен,
только после правильного введения, как
фамилии, так и пароля, пользователь
попадает в следующее меню. Для начальника
оно выглядит так:
Здесь
начальник может просмотреть отчеты по
месяцам года тетрадей ф1, ф3-А, ф3-М и
списки ф103-А и ф103-М для соответствующих
тетрадей.
Также
начальник может произвести поиск по
дате данных тетрадей и списков ф103-А и
ф103-М, введя нужную дату.
Ещё
начальник может просмотреть отчет
списка ф103 для тетрадей ф1, ф3-А и ф3-М.
По
необходимости все найденные и нужные
данные начальник может распечатать.
Путь
оператора состоит в следующем: выбрав
на титульном листе базы данных кнопку
«Операторы», пользователь также попадает
в меню проверки пользования ресурсами
базы данных, где должен ввести свою
фамилию и имя.
При
неправильно введенном пароле или фамилии
пользователю в доступе отказывается.
Если все введено правильно оператор
попадает в ту часть базы данных, которая
предназначена для его работы.
Войдя
в форму для оператора, работник может
добавить новый список ф103-А и ф103-М и
распечатать их.
Также оператор может просмотреть ранее
напечатанные списки.
Оператор
может по необходимости просмотреть
тетради ф1, ф3-А и ф3-М.
Оператор
также как и начальник по необходимости
может произвести поиск по дате тетрадей
ф1, ф3-А, ф3-М и списков ф103-А и ф103-М.
Данное
автоматизированное рабочее место
заметно облегчает заполнение списков
ф103-А,М и ведение различных отчетов.
Обеспечивается быстрый оперативный
ввод информации, удобное хранение в
электронном виде, обеспечивается
возможность пересылки и обмен данными
между другими ОПС и обеспечен вывод
информации на бумажный носитель.
Список литературы
1.
Почтовые правила. М.: Радио и связь, 1992.
2.
Самоучитель Microsoft
Access
2002. –CПб.:
БХВ – Санкт-Петербург, 1999.-480с.
3.
Харитонова И., Вольман Н., Программирование
в Access
2002: учебный курс. – СПб.: Питер, 2003. –
480с.
4.
Гарматин А., Учимся работать на компьютере.
– Ростов н/Д, изд. «Владис». 2002. – 384с.
5.
Ананьев А. И., Федоров А. Ф. Самоучитель
Visual Basic 6.0. – СПб.: БХВ – Санкт — Петербург
, 2000. – 624с.
6.
Технологические процессы в почтовой
связи. Кн.1 и 2, Учебник для вузов / Бутенко
Б.П., Мамзелев И.А., Мицкевич В.А., Цибульский
Б.А.; Под ред. Бутенко Б.П. и Мамзелева
И.А. – М.: Радио и связь, 1998. – 176с., 128с.
18
Писать руководство пользователя по шаблону. Удобно? Удобно
Время на прочтение
4 мин
Количество просмотров 4.7K
Команда, разрабатывающая софт для создания пользовательской документации, делится лайфхаками на тему написания идеальной пользовательской документации для тех, кто далёк от написания руководств к программе.
Для чего мы сами конструируем некоммерческие образцы документации и инструкций для пользователей
Наш проект существует и развивается уже долгое время, практически шестнадцать лет, если быть точнее. За этот срок была сформирована определенная база, где собраны самые актуальные и насущные вопросы, которые возникают перед людьми, создающими справочные элементы к своему проекту.
Ведя диалог с нашими клиентами, мы смогли выделить их потребности и понять основную «боль». Если обобщить, основная проблема заключалась в том, что ни одна программа для создания файл-справок и инструкций не могла выполнить самую нудную, энергозатратную часть проекта — само разрабатывание и оформление этой пользовательской документации
Даже имея осознание того, что файл-справка — неотъемлемый и действительно полезный элемент для пользователя, очень редко возникает мотивация оформить его грамотно и качественно. Еще реже желание возникает, когда в написании пользовательской документации нет опыта или специалистов, которые бы этот опыт имели. Обычно, эта обязанность с легкой руки падает на плечи самих создателей программы, людей, занимающихся тестированием, аналитикой, специалистам поддержки или даже руководителей компании, которые тоже не совсем понимают, как грамотно создать что-то подобное.
Отсюда вытекает еще одна загвоздка. Люди, у которых нет опыта и в принципе понимания, как начать и что туда вносить, просто не знают, как создать качественное руководство для пользователей. В таких случаях большинство следует привычному пути: загуглить определение и найти готовый шаблон.
И с какой-то стороны, это разумно. Мы достаточно часто сталкиваемся с такими запросами, пользователи просят у нас пошаговое руководство или хотя бы костяк готовой инструкции.
Так вышло, что потребности наших клиентов практически на сто процентов входят в нашу экспертную сферу. И мы приняли решение по возможности помочь всем, кто хочет (или вынужден) заниматься созданием файл-справок и инструкций к своему продукту и предоставить возможность получить образцы, которые могут послужить базой и легко быть адаптированными под конкретный запрос.
В связи с этим, мы сами создали готовые образцы и костяки шаблонных проектов в программе. Что входит в нашу базу:
-
Руководство пользователя программного обеспечения.
-
Руководство пользователя web-сервиса.
-
Корпоративная база знаний компании.
В чем удобство создания руководства пользователя по образцу
Вы бережете своё время.
Адаптируя уже созданный образец под свой продукт, вы не тратите время на создание основы с нуля, вам не нужно тратить время, чтобы найти мастер-класс о том, как правильно это сделать. Используя готовый шаблон документации, вы значительно экономите время на создание структуры проекта с нуля и на поиск и изучение информации о том, как это делается.
Вы сосредотачиваете внимание на вашей программе, а не на создании файл-справки
В шаблоне уже есть текстовые и графические вставки, вы можете сами добавлять нужный контент в предложенные места и не продумывать вариант оформления.
Наглядность.
Все образцы и костяки инструкций для пользователя изначально настроенные с динамическими стилями оформления, которые помогут вам быстрее освоиться и разобраться, как можно использовать это для быстрого выполнения своей цели.
Адаптация шаблонов и образцов под ваш проект.
Всё, что находится в шаблонах, можно назвать нашим советом, который был создан на основе многолетнего опыта в данной сфере и выработанной экспертностью. Абсолютно всё в этих шаблонах может быть подвержено адаптации, так как для пользовательской документации нет жестких стандартов, она должна быть выстроена персонально под ваш продукт.
О шаблонах
За 15 лет мы смогли подвергнуть аналитике более сотни разных файл-справок, инструкций и технических документаций, что дало нам возможность сделать вывод и определить шаблонные разделы, которые могут быть применены к огромному количеству программ, после чего мы интегрировали их в наши образцы. Давайте немного подробнее поговорим о структуре.
Обзор возможностей программ. Здесь идет краткое содержание сути вашего продукта. Где вы рассказываете о том, для чего нужна ваша программа. Какие боли и потребности она удовлетворяет, на что способна.
Пользовательский интерфейс. Здесь вы можете наглядно показать вашему клиенту интерфейс, ознакомить его со всеми режимами, дополнительными кнопками и.т.д. Если пользователь может персонализировать интерфейс под себя, об этом тоже лучше указать именно в этом разделе.
Типовые задачи. Здесь нужно максимально подробно познакомить пользователя со всеми основными возможностями программы и детально описать ряд задач и вопросов, которые клиент сможет решить с её помощью. В нашем образце этот блок сформирован из двух подразделов. В подразделе «Примеры использования» лучше всего рассказать пользователю, как ваш продукт будет решать его вопросы и задачи. Если обобщить, то в этом подразделе вы рассказываете про клишированные проблемы, с которыми сталкивается большинство пользователей. В подразделе «Лучшие практики» лучше разместить максимально полезную информацию о том, как упростить свою работу в программе и как пользоваться ей максимально эффективно.
Особые случаи. Здесь нужно рассказать пользователю про то, какие трудности могут возникнуть и как их решить, выделить часто задаваемые вопросы и дать на них самый доступный ответ. Подразделы: «FAQ» и «Устранение типовых проблем»
Вспомогательная и юридическая информация. Здесь вы размещаете информацию о компании, размещаете контактные данные тех.поддержки, информацию о сотрудничестве, сайт, а также лицензионные соглашения.
Названия проекта публиковать не будем, Хабр ругается.
P.S. Мы будем рады, если наши образцы помогут вам закрыть вопрос и успешно реализовать документацию в своем проекте.
Всем доброго времени суток, кто решил прочитать статью, посвященную документации. Здесь вы найдёте как общие, так и довольно специфические советы по созданию руководства пользователя. Надеюсь, они будут вам полезны.
Приятного чтения.
Если перед вами стоит вопрос – нужно ли вашему продукту пользовательское руководство, то отвечу сразу – да, нужно. Почему? На это есть две причины:
1. Качественная документация повышает лояльность клиента и ценность продукта в целом.
Как это не странно, но люди до сих пор читают пользовательскую документацию. Конечно, не просто так, а когда сталкиваются с проблемой. И если с руководством все хорошо, то пользователь быстро найдет ответ на свой вопрос – это будет ещё один балл в копилку вашего проекта!
2. Руководство пользователя экономит время и силы техподдержки.
Данный факт напрямую зависит от первого. Если документация качественная, то пользователи будут редко обращаться в техподдержку, и ваша команда будет работать с действительно нестандартными ситуациями. Ну а если руководство «так себе», то поддержка будет завалена однотипными вопросами. Из-за этого пользователям придется дольше ждать ответа, поддержке больше работать, а это в свою очередь будет злить как пользователя, так и команду.
А теперь к советам!
Общие советы по созданию руководства пользователя
Прежде чем начинать писать руководство пользователя нужно ответить на несколько вопросов. — Для кого вы пишите? Кто будет пользоваться файлом справки? (ваша целевая аудитория)
— Где скорее всего пользователи будут прибегать к документации? (дома, на работе, в машине)
— Насколько объективно сложен для понимания продукт и как часто пользователь будет обращаться к документации?
И так, вы ответили на эти вопросы и теперь можете сделать вывод какого размера документация вам нужна, какой стиль изложения в ней использовать, и как часто пользователь будет читать документ.
(Для изложения лучше всего выбрать нейтрально-формальный стиль)
Структура руководства пользователя
У любого качественной документации продуманная и логичная структура. Представьте, что вы сами работаете в программе и сталкиваетесь с проблемой. Открываете файл справки – а там просто сплошной текст. Такая документация вам не поможет.
Создайте оглавление, которое будет началом вашего руководства. Оно поможет вам в дальнейшем написании документации, а также поможет пользователю ориентироваться в тексте.
В первом разделе расскажите общую информацию о продукте. Для чего создан проект и какие задачи он решает.
Во второй «главе» укажите основные элементы интерфейса. Клиент вряд ли сможет достичь своей цели в программе, если не будет знать для чего служат различные детали интерфейса. Объясните предназначение всех окон, кнопок и так далее.
Дальше расскажите, как эффективно пользоваться программой. Какие задачи стоят перед пользователем и как продукт быстро их решает.
В любом руководстве желательны разделы «Частые вопросы» и «Устранение типовых проблем». Расскажите о проблемах, с которыми часто сталкиваются клиенты и о путях их решения.
Информацию для этого раздела лучше брать у техподдержки. Проанализируйте, какие вопросы задаются чаще всего и ответьте на них один раз максимально информативно.
И последний «обязательный» раздел, которой точно должен быть в любой документации – «контактная информация». Данный раздел даст пользователю возможность связаться с разработчиком. Если руководство вдруг не закрывает потребность читателя, то он может обратиться в поддержку. Кроме того, клиент может дать совет, поделиться опытом или предложить выгодное вам сотрудничество.
Профессиональный совет: если вы хотите максимально облегчить ношу клиента при чтении документации создайте контекстно-зависимую справку. Что это такое?
Представьте, что вы работаете в программе для создания пользовательской документации. Открываете меню основных настроек и видите раздел «аннотирование экрана» Заходите в него, там показаны разные стили аннотации, тени, фон и так далее. Но что такое аннотация? Допустим вы не знаете — нажимаете кнопку F1 и перед вами открывается руководство именно на той странице, где рассказано об «аннотировании экрана»
Как ее сделать? Смотрите ниже.
Контент
И так, мы создали «каркас» нашей документации, но чтобы руководство стало полезным нужно наполнить её компетентной информацией.
Конкретного совета дать невозможно, так как все продукты разные. Поэтому расскажу про общие положения, которые делают документацию лучше.
1. Понятность.
Помните, что руководство будут читать люди, которые не сильно знакомы с вашим продуктом. Пишите простым языком, избегайте профессиональных терминов. Руководство пользователя должно быть написано на языке этого самого пользователя, а не на языке писателя.
2. Наглядность.
Добавляйте в руководство побольше графики и скриншотов с аннотациями. Читателю будет проще и приятнее решать проблему, если будет наглядно показано как это делать.
3. Видео.
Лучше один раз увидеть, чем сто раз услышать. Продемонстрируйте пользователю последовательность действий для достижения конкретной цели. Документация, содержащая видео вставки будет пользоваться большей популярностью, чем обычный текстовый документ.
Но как добавить в документацию видео? Смотрите ниже.
Больше советов!
Когда документация будет готова, чтобы она стала «полноценной» её нужно опубликовать. Иначе какой от неё толк, если клиент не может её прочитать. У «юзера» всегда должен быть доступ к документации, и не важно где он. Такую потребность легко закрывают три формата: HTML, PDF и CHM.
Создайте файл справки и загрузите его прямо в вашу программу в формате CHM. Таким образом, у пользователя будет возможность открыть документ, не выходя из программы. Не забудьте добавить элемент вызывающий руководство в меню программы.
Выложите руководство на сайт в формате HTML, чтобы клиент мог обратиться к документации, даже не работая с программой. Кроме того, документация, выложенная на сайт, повышает SEO факторы сайта.
И напоследок, переведите пользовательскую документацию в формат PDF, чтобы клиенты могли скачать и распечатать руководство.
Но помните, что после публикации документации, придется иногда её обновлять.
Инструменты
Для того, чтобы написать, а затем опубликовать документацию одного Wordа не хватит, но и пользоваться большим количеством программ тоже не хочется.
Ну и пользуясь случаем, я хочу рассказать про проект, в котором я работаю уже много лет и который закрывает все потребности писателей пользовательской документации.
Dr.Explain – программа для создания руководств пользователя для ПО, web-сервисов и баз знаний.
Благодаря «доктору» вы сможете опубликовать и обновлять документацию в востребованных форматах (CHM; HTML; PDF; DOC), не выходя из программы.
В программе есть шаблоны документации, ведь по образцу работать проще.
Импортируйте в программу заранее написанные фрагменты документации.
Вы сможете создать контекстно-зависимую документацию, настроить визуальный стиль руководства, добавить в него видео и многое другое!
Какой можно сделать вывод
Если вы хотите создать по-настоящему хорошую документацию – придется потрудиться, потому что это займет много времени и усилий всей команды. Но игра стоит свеч, так как после этого вы получите лояльных и довольных клиентов.
Руководство пользователя должно стать персональным гидом по продукту для клиента. Если пользователь останется недовольным после работы с документацией, то это может повлиять на решение отказаться от продукта.
Работая с Dr.Explain, можно быстро написать пользовательскую документацию, которая будет помогать клиентам разбираться в продукте, а вам позволит сосредоточить свои силы на более важных задачах — разработке и продвижении программного продукта.
Спасибо за внимание!
Со всеми возможностями Dr.Explain можно ознакомиться здесь:
Кто помог нам разобраться
Научный сотрудник лаборатории измерения новых конструктов и дизайна тестов в Центре психометрики и измерений в образовании Института образования ВШЭ. Руководитель проекта «4К: измерение критического мышления, креативности, коммуникации и кооперации». Преподаёт в Институте образования психометрику и методологию измерений в психологии и образовании.
В этой статье речь пойдёт о разработке образовательных тестов — заданий по проверке предметных знаний и навыков. Но в целом описанные правила универсальны: тесты для оценки психологических качеств или софт-скиллов разрабатываются аналогично.
Вы узнаете:
- можно ли с помощью теста, где учащийся выбирает из вариантов ответов, проверить, как он умеет рассуждать;
- можно ли измерить тестом не просто знание фактов, а понимание учебного материала;
- чем трудные задания отличаются от сложных и почему трудным тест может быть, а вот сложным его лучше не делать;
- с каких заданий лучше начинать — простых или трудных;
- какое количество вариантов ответа оптимально;
- как проверить, работает ли тест.
Психометрики называют тестом любой инструмент измерения — и ролевую игру, и эссе, и оценку портфолио. Мы подробно разберём инструмент, за которым в русском языке закрепилось слово «тест» в узком значении, — вопросы с выбором ответа из предложенных вариантов.
У стандартизированных тестов в образовании не лучшая репутация. Но психометрики по-прежнему отстаивают такой способ измерения: тесты с выбором ответа масштабируемы, справедливы и объективны. Это значит, что по одному и тому же тесту можно проверить сколько угодно учащихся, причём все будут в равных условиях, а на результат не повлияет ничьё постороннее мнение.
Но в то же время любой психометрик скажет вам, что тесты с выбором ответа — не универсальный инструмент. Способ проверки знаний выбирают с учётом того, какой именно конструкт необходимо измерить. Конструктом в психометрике называют свойство психики или способность, которые нельзя наблюдать напрямую, но можно измерить по внешним поведенческим признакам.
Для каких конструктов подходят тесты с выбором ответа? Это практически идеальный инструмент для оценки знания фактов и сугубо технических навыков. Например, для проверки знания о том, как отделить команды друг от друга при программировании на определённом языке.
А вот проверить, как учащийся умеет рассуждать, взаимодействовать с коллегами или находить практическое решение в сложной ситуации, тест с выбором ответов не поможет. Чем сложнее природа конструкта, тем более гибким должен быть инструмент измерения.
Такие тесты способны выявить не любые знания. В любой дисциплине есть простые факты, и по ним легко написать вопросы с несколькими вариантами ответа. Например, спросить, в каком году Колумб открыл Америку.
А есть элементы знания, для которых простого запоминания недостаточно. Например, если мы хотим спросить, какие события и явления стали предпосылками для открытия Америки, вопрос с выбором ответа из нескольких уже не так хорош.
Каждый преподаватель хочет, чтобы студенты не только помнили факты, но и понимали материал. Но, увы, понимание как таковое пока невозможно измерить. Может быть, нейронауки в отдалённом будущем дадут возможность следить за всем, что происходит внутри черепной коробки каждого ученика. Но сейчас психометрика работает с тем, что можно наблюдать, с поведенческими проявлениями. У понимания таких универсальных проявлений нет.
Потому в педагогических измерениях, когда нужно оценить более глубокие, не фактологические знания, измеряют не само по себе понимание, а умение интерпретировать или анализировать. И более практичны, чем тесты с выбором из нескольких вариантов, тут задания с открытым ответом или компьютерные симуляции и игры. В таких инструментах среда тестирования будет более гибкой, чем стандартизированные тесты.
Если ваша задача — проверить усвоение фактологических знаний или отдельных навыков, тест с выбором ответов вполне подойдёт. Чтобы составить и распространить такой тест, не нужны сложные цифровые сервисы. Для базовых задач вполне достаточно форм Google или «Яндекса».
В этом разделе статьи разберёмся с основными вопросами о том, как составить хороший тест. А если нужно узнать по этой теме больше, советую книгу: Haladyna T. M., Rodriguez M. C. Developing and validating test items (Routledge, 2013) — и другие работы её авторов. Правда, на русском языке она, к сожалению, не выходила.
К концу теста любой учащийся устаёт. Поэтому последние задания зачастую уже не дают никакой информации о знаниях тестируемого. Получается, делать тест слишком длинным нельзя.
Но и коротким он быть не может — у небольших тестов ниже надёжность. На какой-то вопрос учащийся даст неверный ответ по невнимательности, а где-то, наоборот, случайно угадает правильный вариант. Если тест будет достаточно объёмным, больше шансов, что такого рода ошибки уравновесят друг друга и итоговый результат будет достоверен.
Так как определить, какой длины должен быть тест? Нужно отталкиваться от времени на решение одного задания. Оно зависит от трудности и может составлять от нескольких десятков секунд до пяти минут. Также стоит учитывать возраст учащихся:
- Детям до подросткового возраста нельзя давать задание дольше, чем на 20 минут, — или нужно предусмотреть возможность перерыва в тесте.
- Для старших подростков и студентов, а также взрослых лучше исходить из продолжительности привычного занятия. Например, для старшеклассника нормально посвятить тесту урок в 45 минут (или два урока с переменой между ними). А для студентов уже можно написать тест и на 80 минут.
- В дополнительном образовании взрослых следует учитывать, что взрослый человек уже не считает себя обязанным участвовать ни в каких тестах. Ему нужна дополнительная мотивация. Например, можно пообещать индивидуальную обратную связь по результатам теста (и потом обязательно её предоставить!).
Золотое правило таково: чем больше часов на тему отведено в курсе, тем больше вопросов в финальном тесте. Потому что изначально, когда курс составлялся, большее число часов было запланировано на более важную тему.
Если темы не слишком дробные, хорошо бы поставить минимум три вопроса на каждую. Опять же, потому, что случайные ошибки уравновесят друг друга. Но обратную связь потом лучше давать не только по каждому отдельному заданию, но и по теме в целом.
Небольшое отступление: в психометрике задание может быть трудным, но не сложным. Трудность в этой науке понимают так же, как обычно в русском языке. Чтобы справиться с трудным заданием, нужно обладать высоким уровнем знаний по теме. Скорее всего, немногие ученики решат трудное задание.
А сложность — отдельное психометрическое понятие. Оно характеризует, сколько действий и когнитивных операций нужно выполнить в процессе решения. Возьмём математический пример. Задание разделить 0,219 на 0,365 трудное, но не сложное: оно состоит всего из одного действия.
И начинать тест следует с более лёгких заданий, то есть с нетрудных. В начале теста уровень стресса всегда выше, что искажает результаты. Если вопросы в тесте распределены по тематическим блокам, можно в каждом из них располагать задания от лёгких к трудным.
Кстати, вопрос о распределении по тематическим блокам сам по себе непростой. С одной стороны, правильнее, чтобы тестируемый концентрировался в каждый момент теста на одной теме. С другой стороны, иногда важно проверить, может ли он быстро переключаться с одной проблемы на другую.
Как именно поступить, решают в зависимости от дисциплины и задач теста. Но важно ставить всех тестируемых в одинаковые условия, чтобы результаты были сопоставимы.
В целом делить на блоки тест правильно: так тестируемый увидит, что тест не бесконечен. В ситуации компьютерного тестирования, когда нельзя пролистать задания и понять, сколько ещё осталось, это важно. И, конечно, нужно предупредить, если время на ответы ограничено.
Наиболее привычны сегодня тесты как в ЕГЭ — с четырьмя вариантами ответа. Иногда можно услышать, что это связано с объёмом рабочей памяти: якобы четыре варианта появились, потому что именно такое количество элементов средний человек способен одновременно удерживать в уме.
Психологи-когнитивисты такое обоснование считают ненаучным. Скорее всего, к четырём вариантам ответа практики пришли случайно, и ничего биологически или психологически заданного в этой цифре нет. Вариантов может быть и меньше — например, три.
А вот придумать больше неверных ответов обычно затруднительно.
Создание неправильных вариантов ответа — на самом деле сложное психометрическое мастерство. Не зря их называют дистракторами, то есть отвлекающими внимание от верного варианта.
Суть в том, что неправильные ответы должны быть похожи на правильный и привлекательны. Очевидно неправильных ответов нужно избегать, как и ответов из другой области. Например, если в вопросе стоит формулировка «В каком году?», все ответы должны быть датами примерно из одного диапазона.
Но неверные варианты не должны содержать в себе правильный ответ или какую-то его часть — иначе нужно в вопросе объяснить, что тестируемый должен выбрать самый правильный ответ.
Высший пилотаж — неправильные варианты на основе типичных ошибок студентов. Это позволяет давать более глубокую обратную связь: не просто показывать, где учащийся ошибся, а анализировать, почему он выбрал именно такой неправильный вариант.
Кроме надёжности, у любого теста есть ещё одно важное качество — валидность. По классическому определению, валидность — свойство теста измерять то, на что он направлен. Более современное определение гласит, что результаты валидного теста можно интерпретировать в той логике, в которой он создан.
И иногда на валидность может повлиять просто то, что тестируемый иначе (но не неправильно!) смотрит на ситуацию в задании.
Возьмём пример из теста на критическое мышление, разработанного в ВШЭ. Это тест‑симуляция онлайн-среды, в ней нужно общаться с ботом. Одна из задач — получить недостающую информацию для рецепта торта.
По идее, тестируемый должен задать боту конкретный вопрос, например: «Сколько яиц нужно добавить?» Но человек может начать с приветствия, и не потому, что не понял задание. Сказать «Привет, как дела?» перед тем, как уточнять рецепт, вообще‑то нормально. Но если об этом не подумать при составлении теста, такой ответ будет оцениваться как ошибочный.
Одно из частых опасений по поводу тестов и причин, почему в них предлагают добавлять больше вариантов ответа, — «угадайка». Кажется, что в задании с двумя вариантами ответа вероятность угадать составляет 50%. Но это верно только в случае, когда весь тест состоит из одного вопроса с двумя вариантами ответа.
Если добавить второй вопрос, в котором не будет подсказок к первому и наоборот, вероятности просто перемножатся. И шанс случайно угадать правильные ответы составит уже 25%. В случае с тестом из десяти заданий вероятность ответить на всё правильно случайно пренебрежимо мала.
Но такой расчёт справедлив только для тестов с хорошо написанными неправильными ответами.
На магистерской программе Института образования психометриков учат проверять работоспособность тестов все два учебных года. Попробуем коротко разобрать, что именно они изучают.
Проверить тест можно качественным или количественным методом. Качественный метод представляет собой интервью. Разработчик теста выдаёт задания представителю целевой группы, наблюдает за ним и расспрашивает. Так можно выяснить, всё ли понятно в заданиях, что именно тестируемый делает для решения, какие вопросы ставят его в тупик, а какие кажутся слишком простыми.
Цель качественной проверки — убедиться, что решение теста задействует именно те когнитивные процессы, которые требовалось вовлечь (скажем, тестируемый действительно решает математическую задачу, а не навскидку выбирает из вариантов наиболее подходящий), что варианты-дистракторы не содержат элементов правильного ответа, что все инструкции к тесту понятны и так далее.
Оценка работоспособности теста количественными методами — как раз психометрика в узком смысле слова. Проводится она через статистический анализ, для которого нужно порядка 100 наблюдений.
Понятно, что для каждого курса такую проверку не проведёшь, обычно достаточно интервью. Но количественная оценка обязательна, если по результатам теста принимается какое-либо решение — о зачислении на курс, о сертификации.
В результате разработчик теста получит все те же данные, что и при качественной оценке. К тому же количественная оценка покажет, какие вопросы и утверждения не измеряют то, что должны, а какие вообще избыточны — тест работает и без них.
Наверняка вы сами хоть раз в жизни составляли тесты и уж точно неоднократно проходили разнообразное тестирование – от серьезного до совсем шуточного из серии «Какой ты овощ во время карантина?».
Очень часто, за неимением нужных знаний и подготовки, разработчики придумывают тесты, опираясь исключительно на свой опыт, интуицию и здравый смысл (за исключением «овоща на карантине»). Многие, приступая к разработке собственных тестов, поначалу думают: что тут может быть сложного? Составить вопросы, придумать к ним ответы — вот и вся недолга! Это очень глубокое заблуждение. Создание хорошего задания в тестовой форме – настоящее искусство.
Существуют разработанные учеными методики составления тестовых заданий. В этой статье я хочу рассказать об одной из таких методик, которую используют в системе общего и профессионального образования. В частности, ее нередко применяем и мы в учебном центре «Сетевая Академия ЛАНИТ» для разработки проверочных тестов и систем аттестации сотрудников.
Источник
Вместо предисловия
Почему я решила, что вам это может пригодиться? Во-первых, потому что многим из вас – людям, совсем далеким от педагогики, приходится проводить разнообразные обучающие мероприятия, разрабатывать учебные курсы и т.п., а все это требует проверки усвоения учебного материала. А какой еще способ, кроме тестирования, способен проверить знания быстро, надежно и объективно?
Во-вторых, потому что использование педагогических тестов актуально не только для образования, но и для областей, весьма далеких от него. Тесты – очень полезный инструмент для решения многих задач: и для аттестации сотрудников, и для первичной проверки соответствия знаний и навыков соискателей вакансии, и для оценки степени информированности аудитории о какой-либо проблеме, и много для чего еще.
Сразу оговорюсь, что эта статья в первую очередь рассчитана на людей, не имеющих большого опыта в составлении тестовых заданий. Ее цель – предоставить новичкам достаточный объем материала, который помог бы им научиться составлять качественные педагогические тесты разных видов.
Да простят меня «продвинутые» в вопросах тестовой теории читатели, речь пойдет о базовых сведениях. Хотя, как показывает практика, вспомнить основы тоже никогда не вредно.
Методику, о которой пойдет речь, разработали ведущие отечественные специалисты в области тестологии: В. С. Аванесов, М. Б. Челышкова, А.Н. Майоров и другие.
В качестве примеров приводятся тестовые задания из открытого банка заданий ЕГЭ, размещенного на официальном сайте ФГБНУ «Федеральный институт педагогических измерений», из книги М. Б. Челышковой «Теория и практика конструирования педагогических тестов», из книги В. С. Аванесова «Композиция тестовых заданий», а также задания, составленные автором статьи и преподавателями разных образовательных организаций.
Сначала немного теории
Говоря о тестах в разных сферах деятельности, подразумевают разное. Например, в вычислительной технике тест – это задача с известным решением, с помощью которой проверяется правильность работы системы, а в медицине тестом будет называться метод исследования, заключающийся в пробном воздействии на организм. В общем понимании, тест – это объективное и стандартизированное измерение, которое легко поддается количественной оценке, статистической обработке и анализу.
В рамках наших целей нас интересует педагогический тест со своей спецификой. Это система тестовых заданий различной трудности, созданная для качественного и эффективного измерения структуры и качества подготовленности испытуемых. Тестовое задание является одним из элементов педагогического теста, включает в себя инструкцию, тестовую задачу и эталон ответа.
Преподаватели используют тесты, чтобы:
- оценить исходные знания учащихся перед началом обучения и скорректировать план и содержание занятия;
- сделать срез знаний во время курса, чтобы вовремя внести изменения в процесс обучения, если слушатели недостаточно хорошо усваивают учебный материал;
- проверить финальный результат обучения.
Наиболее часто используются закрытые тесты, в которых ответы уже есть, как в игре «Кто хочет стать миллионером?». Но встречаются и открытые тестовые задания, требующие самостоятельно сконструировать или дополнить ответ.
Итак, выполняя закрытые тесты, обычно надо:
- выбрать один или несколько ответов среди заданных вариантов;
- установить соответствие между элементами двух множеств;
- установить правильный порядок действий или процессов, перечисленных автором теста.
Открытые тесты требуют:
- дополнить имеющийся ответ;
- полностью сконструировать ответ самостоятельно.
Какой материал следует включить в тест
Содержание теста зависит от того, какие цели вы перед собой ставите и зачем вам вообще нужен этот тест. Прежде всего, нужно самому себе ответить на вопрос, можно ли с помощью составленных вами заданий проверить подготовленность аудитории.
Вот такое тестовое задание предложил своим ученикам преподаватель анатомии по теме «Скелет грудной клетки». Одна из целей занятия – знать количество ребер у человека.
Инструкция
: Выберите один правильный ответ.
Количество ребер
- у мужчин больше, чем у женщин
- у женщин больше, чем у мужчин
- индивидуально у каждого человека
- зависит от жизненных обстоятельств
Как вы понимаете, при помощи этого задания невозможно проверить, знают испытуемые, сколько у человека ребер или нет. Поэтому, строго говоря, нет смысла включать такой тест в материалы контроля. Отдельный разговор о качестве подобранных автором вариантов ответа. Особенно интересно влияние жизненных обстоятельств на количество ребер. Но правила подбора неправильных ответов (дистракторов) к тестовым заданиям мы рассмотрим позже.
Основные правила подбора материала для теста следующие:
- Материал, заложенный в тест, должен соответствовать содержанию темы тестирования и программы учебного курса.
- В тест включается только то содержание темы, которое является признанным, объективно истинным и поддается рациональной аргументации. Спорные точки зрения в тестовые задания включать не рекомендуется. Суть тестовых заданий заключается как раз в том, что они требуют четкого, заранее известного преподавателям ответа, признанного ими в процессе разработки заданий объективно истинным.
- Уровень детализации содержания теста зависит от целей тестирования. Если вы планируете использовать тесты для сравнения уровня подготовки тестируемых в какой-то области (например, для конкурсного отбора соискателей вакансии или кандидатов на обучение), то уровень детализации материала должен быть низким. В заданиях такого теста достаточно отобразить только наиболее значимые элементы содержания.
- Если же тесты предназначены для выяснения, насколько успешно испытуемый освоил учебный материал (курс, раздел, тему) и освоил ли он его вообще, то уровень детализации области содержания должен быть довольно подробным. Это позволит сделать вывод о знаниях каждого испытуемого, при необходимости аттестовать его, а также проанализировать, какой материал лучше или хуже освоили испытуемые.
- Вместе с тем в тест необходимо включать те элементы содержания, которые можно отнести к наиболее важным, без которых знания по заявленной теме становятся несущественными. Нет смысла перегружать тест второстепенными деталями, не имеющими большого значения.
- Если с помощью тестовых заданий планируется оценивать знания по всему учебному курсу, следует равномерно включить в итоговый тест задания по всем изучаемым темам курса, убедившись в том, что они охватывают все самые важные аспекты предметной области и в правильной пропорции.
Например, если вы составляете тесты по курсу «Microsoft Excel» и включаете в него задания, посвященные исключительно созданию сводных таблиц и диаграмм, то при помощи этих тестов вы явно не сможете полноценно оценить уровень знаний по всему курсу в целом.
- Не всякое содержание можно выразить в форме тестового задания, то есть тесты – не универсальная форма для проверки знаний.
Сколько времени нужно выделить для тестирования
Сидеть над тестом невозможно бесконечно долго: начало и завершение тестирования должны быть фиксированными. К сожалению, довольно часто временной интервал для этого процесса выбирается спонтанно. И если ошибиться – дать слишком мало времени или слишком много, эффективность теста снизится.
Тестирование в спешке приведет к тому, что как «слабые», так и «сильные» испытуемые не успеют выполнить все задания, и мы не поймем – тестируемый не выполнил задание, поскольку не знал ответа, или вообще не успел к нему обратиться.
Если времени вагон и маленькая тележка, «сильные» испытуемые, успевшие быстро пройти тестирование, начинают отвлекать других, подсказывать ответы, что нарушает процедуру тестирования (мы не соблюдаем правило равных условий для всех испытуемых).
Если человек проходит тестирование в одиночестве или тестируется онлайн, при избытке времени он будет долго сидеть над заданиями, не решаясь выбрать ответ. Это вызовет утомление, снижение концентрации внимания, расслабление, что также снижает точность тестирования.
Всегда нужно иметь в виду, что испытуемые устают. А значит, тестирование не должно занимать слишком много времени, что напрямую связано с объемом самого теста. Практика показывает, что объем осознанно воспринимаемой информации начинает существенно снижаться примерно через 40-45 минут с начала тестирования (Ким В. С. Тестирование учебных достижений. – Уссурийск, 2007, стр. 29-35).
Общее время тестирования определяется количеством и сложностью заданий. Некоторые преподаватели используют, например, такие методики расчета времени тестирования:
- Время, затраченное преподавателем на выполнение составленного им теста, умножить на 3.
- Суммировать время, необходимое для выполнения каждого задания:
• задание закрытой формы с выбором одного правильного ответа – примерно 10 секунд;
• задание более сложных форм – в среднем от 30 секунд до 1 минуты.
Однако бывает, что теоретически рассчитать время тестирования невозможно, поэтому рекомендуется использовать эмпирические данные по результатам первичной апробации теста.
Составление тестовых заданий закрытой формы
А теперь давайте рассмотрим конкретные примеры и поймем, как составлять свои тесты. В фокусе нашего внимания – тестовые задания закрытой формы.
В таких тестовых заданиях выделяют следующие элементы:
- инструкцию (содержит общие требования к выполнению задания – рис. 1);
- основную часть (задание, постановка проблемы – рис. 2);
- варианты ответа (верный ответ(ы) и ответы-обманки – рис. 3).
Рекомендуется, чтобы задания в тесте представляли собой не вопросы, а утверждения, которые в зависимости от ответов могут превращаться в истинные или ложные высказывания.
Среди готовых ответов правильным чаще всего бывает только один, хотя не исключаются и варианты с выбором нескольких правильных ответов.
Неправильные, но похожие на правильные (и поэтому правдоподобные) ответы называются дистракторами (от англ. distract – отвлекать). Они используются для отвлечения внимания от правильного ответа тех, кто либо совсем не знает правильный ответ, либо пытается угадать его во время тестирования. Сделать неправильные ответы правдоподобными – одна из самых сложных задач разработчика теста.
Отдельно от тестовых заданий в программу тестирования вводится эталон выполнения заданий и разрабатываются критерии оценки.
Если вы проводите тестирование по старинке, в письменном виде, то вам потребуется ответник, трафарет для проверки ответника и эталон выполнения тестового задания.
Как оформить тестовые задания
Тестовое задание должно быть оформлено таким образом, чтобы облегчить тестируемому работу над ним.
Существует несколько вариантов дизайна тестовых заданий закрытой формы, но все сходятся в одном: все элементы тестового задания тем или иным образом должны быть графически выделены.
Подробнее о том, как принято оформлять задания
Рекомендован следующий вариант оформления.
- Инструкция не является частью задания. Она пишется отдельно от текста задания и выделяется графически, например, курсивом (пример выше – рис. 1).
- Инструкция может быть записана однократно, если в тесте используются задания одной формы. Каждая новая форма тестового задания требует своей инструкции.
Рекомендуется менять инструкцию как можно реже – ровно столько раз, сколько это оправдано стратегией тестирования. Слишком частая смена инструкции путает испытуемых.
- Текст задания выделяется полужирным шрифтом (рис. 2). Иногда текст задания пишут прописными буквами, но это
too muchвыглядит слишком громоздко и сильно снижает скорость чтения. - Задания нумеруются арабскими цифрами.
- Во избежание путаницы варианты ответов рекомендуется индексировать буквами кириллического или латинского алфавитов (рис. 3).
- Варианты ответа пишутся с маленькой буквы (если не представляют собой имена собственные), поскольку являются продолжением тестового задания, сформулированного в виде утверждения. Если задание сформулировано в вопросительной форме, варианты ответа пишутся так же.
- Варианты ответа располагают в столбик, причем желательно, чтобы все они были немного сдвинуты вправо относительно текста задания.
- Между вариантами ответа и по завершении задания знаки препинания, как правило, не ставятся. Это нарушает правила русской пунктуации, если рассматривать задание как текст, но тестологи мотивируют отсутствие знаков препинания тем, что и без них все части тестового задания графически выделены. Обилие запятых или точек с запятой между вариантами ответов способны помешать восприятию текста задания.
- Не рекомендуется перегружать задания вспомогательными словами: «Вопрос», «Варианты ответов» и пр.
- В печатном варианте теста каждое задание должно быть расположено целиком на одной странице.
- И, конечно же, стиль оформления заданий должен быть единым по всему тесту.
Как написать инструкцию к тестам
Инструкция – это общие требования к выполнению тестового задания. Она должна устранить все вопросы испытуемых об оформлении своих ответов. Кроме того, в тексте инструкции оговаривают специфику задания, например, указывают количество правильных ответов в тесте (один/несколько).
При написании инструкции используют стандартные формулировки. Формулировка инструкции зависит от формы тестового задания, количества правильных ответов и пр.
Для тестовых заданий с выбором одного правильного ответа в зависимости от способа проведения тестирования можно предложить следующие варианты инструкций.
- Выберите один правильный ответ.
- Внимательно прочитайте текст задания и выберите верный ответ из списка.
- Выпишите номер тестового задания и индекс правильного ответа.
- Обведите кружком букву (номер) правильного ответа.
- Для ответа нажмите клавишу с буквой (номером) правильного ответа.
Иногда, по замыслу автора, при разработке задания закладываются несколько правильных ответов, среди которых есть более и менее предпочтительные. В этом случае задание может сопровождаться следующей инструкцией: «Выберите наиболее правильный ответ».
Для тестовых заданий с выбором нескольких правильных ответов в зависимости от способа проведения тестирования можно предложить следующие варианты инструкций.
- Выберите несколько правильных ответов.
- Выберите все правильные ответы.
- Отвечая на задание теста, нажимайте на клавиши с буквами (номерами) всех правильных ответов.
Для тестовых заданий на выбор неправильного ответа инструкция может быть такой: «Выберите неправильный ответ».
Для группы однотипных заданий допускается делать одну инструкцию, которая помещается в начале теста или данной группы заданий в тесте.
Как правильно сформулировать основную часть задания
Эффективность и технологичность теста во многом зависят от того, насколько грамотно сформулированы задания. Если тестируемый не поймет смысл вопроса, ему придется отвечать наугад. А это уже минус к объективности конечного результата. Потому важно тщательно проработать каждое задание. Вот несколько рекомендаций.
1. Рекомендуется, чтобы задания в тесте были формулированы в форме утверждений, которые после ответов испытуемых естественным образом превратятся в истинные или ложные высказывания (рис. 1).
Если продолжить утверждение из основной части этого задания правильным ответом (в данном случае это вариант Б), получится истинное высказывание: Признаком протекания химической реакции между оксидом меди и водородом является изменение цвета. При «подстановке» неправильного ответа высказывание получится ложным.
По мнению многих отечественных тестологов (В.С. Аванесова, М.Б. Челышковой, В.С. Кима и др.), смысл тестового утверждения улавливается всегда лучше, чем смысл вопроса, потому что в тестовых утверждениях нет ни одного лишнего слова и даже знака, в то время как вопрос требует ряда дополнительных слов и знаков для выражения требуемого смысла, значения и интонации. Вопросы и ответы на них иногда бывают столь неопределенными и многословными, что для выявления их истинности требуются большие затраты времени и сил, в то время как технологичная методика тестирования предполагает четкую и быструю дифференцируемость ответов.
Действительно, если трансформировать задание, составленное в форме вопроса, в логическое утверждение, мы увидим, что задание уж точно не стало хуже, а даже выиграло – стало более кратким, понятным, лаконичным. После выбора ответа такое утверждение превратится в законченное высказывание, истинность или ложность которого легко поддается пониманию и оценке.
Пример 1. Задание в вопросительной форме:
Инструкция
: Выберите один правильный ответ.
С каким из названных событий связано окончание периода разрядки международной напряженности в 1970-е гг.?
- начало Корейской войны
- разрыв отношений с Югославией
- конфликт с Китаем
- ввод советских войск в Афганистан
То же задание в виде логического утверждения:
Окончание периода разрядки международной напряженности в 1970-е гг. связано c
- началом Корейской войны
- разрывом отношений с Югославией
- конфликтом с Китаем
- вводом советских войск в Афганистан
Пример 2. Задание в вопросительной форме:
Инструкция
: Выберите несколько правильных ответов.
Какие из перечисленных примеров относят к ароморфозам?
- возникновение теплокровности у позвоночных
- развитие трехкамерного сердца у земноводных
- формирование торпедообразного тела у акул
- развитие зародыша внутри матки
- появление рогов у копытных
- формирование крыльев у летучих мышей
То же задание в виде логического утверждения:
К ароморфозам относят
- возникновение теплокровности у позвоночных
- развитие трехкамерного сердца у земноводных
- формирование торпедообразного тела у акул
- развитие зародыша внутри матки
- появление рогов у копытных
- формирование крыльев у летучих мышей
Подобной трансформации легко поддается большинство заданий, сформулированных в вопросительной форме. Иногда возникают ситуации, когда, казалось бы, задание формулируется только в виде вопроса. Однако после тщательного анализа цели задания и его содержания все же удается подобрать утвердительную форму задания.
Конечно, утверждение об использовании в заданиях исключительно утвердительной формы не категорично. К тому же иногда встречаются задания, в которых вопросительная форма выглядит удобнее и короче.
Вопросительная форма заданий по-прежнему используется при составлении тестов и в России, и за рубежом, и имеет много сторонников. Выбор остается за вами. Главное – не забывать, что выбранная вами форма задания должна быть максимально понятна для испытуемых.
Лично я являюсь сторонником формулировки заданий в виде утверждений, считаю эту форму наиболее удачной, использую только ее и ничего с собой поделать не могу.
2. Текст задания должен содержать достаточную, недвусмысленную и релевантную информацию для ответа.
3. Формулировка задания должна быть грамотной, согласованной с формой вариантов ответа (простите за капитанство).
4. Формулировка задания должна быть предельно лаконичной, но не в ущерб пониманию сути задания. Необходимо исключить повторы слов и, тем более, целых фраз. Чем лаконичнее задание, тем лучше оно воспринимается.
5. Рекомендуется, чтобы основная часть задания состояла из одного предложения (не более 7-8 слов), а во всем задании было не более одного придаточного предложения. Эта рекомендация подходит, конечно, не ко всем случаям. Например, тестовое задание может представлять собой кейс/ситуационную задачу, тогда одним предложением точно не обойтись.
6. Если задание сформулировано в вопросительной форме, предпочтительнее применять прямые вопросы, представляющие собой полное предложение с вопросительным знаком в конце.
7. В основной части задания не должна присутствовать дополнительная информация, не существенная для поставленной проблемы.
8. Из текста задания нужно исключить все вербальные ассоциации, по которым можно догадаться о правильном ответе.
9. Стоит исключить из формулировки задания частицу «не». А если НЕ получается, ее надо выделить прописными буквами (как в этом предложении).
10. Исключаются задания, содержащие оценочные суждения тестируемого: «на ваш взгляд», «по вашему мнению», «что вы думаете…», «согласны ли вы с …», «как бы вы сформулировали…» и т.п.
11. Рисунки, графики, схемы, используемые в задании, должны соответствовать тексту (рис. 2). И, конечно же, присутствие графических объектов в задании должно быть оправдано. Не стоит «добавлять картинку» просто для красоты.
12. Элементы рисунка, графика, схемы рекомендуется обозначать по часовой стрелке (рис. 3).
13. В большинстве случаев варианты ответов замыкают задания (так было и в примерах выше), образуя завершенное истинное или ложное высказывание. Но иногда ответы приходится ставить в середине или за одно-два слова от конца содержательной основы задания теста. Тогда можно использовать такой вариант:
Инструкция
: Выберите один правильный ответ.
Невская битва произошла в … году.
- 1198
- 1240
- 1242
- 1245
14. Ответ на одно тестовое задание не должен служить ключом к правильным ответам на другие задания теста. Это нарушает условие локальной независимости заданий. В этом случае невозможно сделать корректный вывод о том, знает ли испытуемый ответ на второе и последующие задания, или он не справился с ними потому что неправильно ответил на первый вопрос.
Как подобрать дистракторы
К каждому тестовому заданию нужно подобрать правдоподобные неправильные варианты ответа (дистракторы). Это одна из самых сложных задач, стоящих перед составителем тестов. Перед вами основные рекомендации по подбору дистракторов:
1. Все предложенные в задании дистракторы должны быть правдоподобными, теоретически вероятными.
Наиболее хороши дистракторы, подобранные на основе типичных ошибок, которые допускают тестируемые, или на основе распространенных заблуждений.
2. Все дистракторы к заданию должны быть одинаково привлекательными для тестируемых, не знающих правильного ответа.
Дистрактор, который никто не выбирает в качестве правильного ответа, обычно называют неработающим. Если в задании имеется хотя бы один неработающий дистрактор, удалите его, и вы сразу увидите реальное, а не формальное число ответов к заданию теста.
Если все дистракторы в задании не работают, все испытуемые выполнят даже сложное задание верно, выбрав единственный правдоподобный ответ. Например, такое задание:
Инструкция
: Выберите один правильный ответ.
Во вращении предплечья наружу участвует
- двуглавая мышца плеча
- двуглавая мышца бедра
- икроножная мышца
- прямая мышца живота
- собственно жевательная мышца
Даже не будучи знатоком данной предметной области, нетрудно догадаться, что мышцы, расположенные на нижней конечности, животе или черепе, не могут приводить в движение предплечье. Получается, что в тесте нет ни одного работающего дистрактора. Имеется всего один работающий вариант ответа, его и выберут испытуемые как единственно правильный.
Вы спросите: «А что же здесь плохого»? Как мы писали выше, педагогические тесты создаются для объективной оценки структуры и качества знаний. А о какой объективной оценке можно говорить, если правильный ответ можно просто угадать, не имея совсем никакого представления о предмете? Конечно, если целью тестирования было узнать, отличает ли испытуемый живот или бедро от предплечья, то можно сказать, что все прошло успешно. Но все же перед тестами обычно ставятся более серьезные задачи.
Если в предложенном задании мы заменим неработающие дистракторы на правдоподобные, теоретически вероятные (все перечисленные мышцы тем или иным образом двигают предплечье), справиться с ним так просто будет нельзя:
Во вращении предплечья наружу участвует
- плечевая мышца
- двуглавая мышца плеча
- трехглавая мышца плеча
- локтевая мышца
- круглый пронатор
3. Дистракторы должны быть однородными, подобранными по общему (единому) основанию.
Пример 1: Задание с однородными дистракторами
Инструкция
: Выберите один правильный ответ.
Телиоспоры возникают из
- урединиоспор
- эциоспор
- базидиоспор
- пикниоспор
Здесь все дистракторы подобраны по одному основанию, т.к. все они отвечают на вопрос «из чего?» и характеризуют то, из чего могут возникнуть телиоспоры.
А в следующем задании дистракторы подобраны неудачно.
Пример 2: Задание с неоднородными дистракторами
Инструкция
: Выберите несколько правильных ответов.
Телиоспоры возникают
- из урединиоспор
- из эциоспор
- поздней осенью на том же мицелии, на котором летом формировались урединиоспоры
- весной в результате слияния дикариона и последующего мейоза
В этом задании два первых ответа выбраны по одному основанию т.к. все они отвечают на вопрос «из чего?». Третий ответ подобран по другому основанию, поскольку соответствует вопросам «когда?» и «где?».
Последний ответ не совпадает по основанию выбора ни с одним из предыдущих, он отвечает на вопросы «когда?» и «в результате чего?».
Самая частая причина появления в заданиях неоднородных дистракторов понятна – при невозможности подобрать нужное число дистракторов по одному основанию автор теста увеличивает их число, включая дополнительные, выбранные по другому основанию ответы.
Иногда причиной является желание автора проверить с помощью одного задания как можно больше знаний испытуемых. Возможно, это оправдано спецификой предмета, однако некорректно с точки зрения требований тестовой технологии.
Тестовое задание должно проверять один элемент знания. Если это не так, то становится неясным, с каким именно элементом знания тестируемый не справляется, в чем заключена причина невыполнения задания.
4. Все ответы должны быть параллельными по конструкции и грамматически согласованными с основной частью задания теста.
5. Все повторяющиеся в вариантах ответа слова (как в примере ниже) следует перенести в формулировку заданий.
Инструкция
: Выберите один правильный ответ.
Заштрихованная территория на карте России показывает районы
- газовых месторождений
- нефтяных месторождений
- месторождений каменного угля
- месторождений калийной соли
Вот что получится после небольшой правки этого примера:
Инструкция
: Выберите один правильный ответ.
Заштрихованная территория на карте России показывает районы месторождений
- газовых
- нефтяных
- каменного угля
- калийной соли
6. Рекомендуется использовать длинные задания и короткие ответы. В противоположном случае на прочтение и анализ ответов тратится слишком много времени.
7. Из числа неправильных исключаются ответы, вытекающие один из другого.
8. Ни один из дистракторов не должен быть частично правильным ответом, который при определенных условиях превратится в правильный ответ.
9. Ответы не должны отрицать смысл самого задания. «Почему? – спросите вы, – ведь так часто делают». Давайте разберемся на примере следующего задания:
Инструкция
: Выберите один правильный ответ.
PDF-файл можно преобразовать в документ Word, если на вкладке «Файл» выбрать команду
- Открыть
- Сохранить как
- Экспорт
- PDF-файл нельзя преобразовать в документ Word
В этом примере четвертый ответ прямо противоречит основной части, утверждающей существование возможности преобразовать PDF-файл в документ Word. Налицо явная логическая ошибка. В задании же не спрашивается, можно ли преобразовать, а утверждается, что можно, а варианты ответов представляют собой перечисление способов преобразования.
Если четвертый ответ – дистрактор, то в качестве правдоподобного ответа его вряд ли выберет хотя бы один тестируемый. Тогда этот ответ как неработающий дистрактор необходимо удалить из теста.
Если именно четвертый ответ является верным, все задание будет нерабочим, т.к. большинство тестируемых увидят логическую несообразность формулировок и пропустят задание, посчитав его ошибкой разработчика теста.
Если цель задания – выяснить, знает ли испытуемый, можно ли вообще преобразовать PDF-файл в документ Word или нет, лучше сформулировать вопрос по-другому, без нарушения логики:
Преобразовать PDF-файл в документ Word
- можно
- нельзя
10. Не следует использовать в заданиях ответы типа «все вышеперечисленные», «ни один из вышеперечисленных» или, того хуже, – «все ответы неправильные» и «правильного ответа нет». Эта рекомендация, кстати, так же часто вызывает вопросы и несогласие аудитории, как и предыдущая.
С точки зрения большинства тестологов, применение подобных ответов не оправдано по следующим причинам:
- повышение вероятности угадывания правильного ответа, так как чаще всего это будет неработающий дистрактор, добавленный составителем «для количества» при трудностях с подбором качественных дистракторов;
- нарушение логического закона исключенного третьего – если инструкция предписывает выбрать один верный ответ, то в задании он должен быть. Это придает однозначность замыслу самого задания и не допускает противоречивых толкований у испытуемых.
11. Не рекомендуется использовать слова «всегда», «никогда», «ни одного» и т.п., так как в отдельных случаях они способствуют угадыванию.
12. Частота выбора одного и того же номера места для правильного ответа в различных заданиях теста должна быть примерно одинакова или номер места для правильного ответа выбирается в случайном порядке.
13. Дистракторы из одного задания не используются в качестве ответов к другим заданиям теста.
14. Все ответы к одному заданию должны быть примерно одной длины. Если это трудновыполнимо, возможен вариант, когда в задании половина длинных ответов, половина коротких. Это нужно для того, чтобы исключить вероятность угадывания правильного ответа по признаку его полноты или краткости. Многие разработчики тестов грешат тем, что в их заданиях правильные ответы почти всегда или длиннее, или короче неправильных. Эта тенденция очень быстро «считывается» испытуемыми и делает общий результат теста необъективным. Следующая рекомендация имеет такое же обоснование.
15. Правильный ответ не должен быть длиннее других.
16. Дистракторы располагаются в логической последовательности: числа – по возрастанию, буквы – по алфавиту. Это удобнее при поиске тестируемым правильного ответа.
17. Количество дистракторов к заданию подбирается таким образом, чтобы задание не было слишком громоздким, но и чтобы исключить большую вероятность угадывания правильного ответа. Поэтому чаще всего в заданиях бывает три или четыре дистрактора и один правильный ответ.
В отдельных случаях, например, в заданиях с выбором нескольких правильных ответов, количество дистракторов может достигать шести–семи.
18. Число дистракторов и правильных ответов в разных заданиях может быть разным. Оно не должно быть одинаковым во всех заданиях теста.
Источник
По какому принципу придумывают тестовые задания
Из десяти принципов разработки тестовых заданий закрытой формы, которые выделяет В. С. Аванесов, предлагаю рассмотреть основные. Для наглядности будем это делать на примерах.
1. Принцип противоречия применяется при создании заданий с двумя вариантами ответов. Здесь один ответ отрицает другой. Например:
Инструкция
: Выберите один правильный ответ.
Поощрения в трудовую книжку
- записываются
- не записываются
2. Принцип противоположности ответов близок по смыслу к принципу противоречия, но при противоречии используется отрицание, а при противоположности один ответ заменяется другим, антонимичным по смыслу. Например:
Инструкция
: Выберите один правильный ответ.
С увеличением заряда ядра активность щелочных металлов
- возрастает
- убывает
Возможность промежуточных состояний при использовании принципа противоречия позволяет увеличить число ответов, например, до трех. Например:
Инструкция
: Выберите один правильный ответ.
При движении тягового органа конвейера реле скорости
- включено
- выключено
- заблокировано
3. Тесты, основанные на принципе однородности, содержат ответы, относящиеся к одному роду, виду, или отображают основные стороны, грани явления. Например:
Инструкция
: Выберите один правильный ответ.
Основателем андрагогики как науки является
- Ноулз
- Джарвис
- Холтон
- Ушинский
Инструкция
: выберите несколько правильных ответов.
Буква «о» пишется в словах
- пл_вец
- пок_рить вершину
- распол_гать
- осн_щенный
- ум_лять значение
4. Принцип кумуляции означает, что второй ответ вбирает в себя (аккумулирует) содержание первого, третий – содержание второго и т.д.
Пример:
Инструкция
: Выберите один правильный ответ.
Чтобы задать движение точки естественным способом, надо знать
- траекторию
- траекторию и закон движения
- траекторию, закон движения, начало отсчета
- траекторию, закон движения, начало отсчета, скорость
Тестируемые, привыкшие давать полные и правильные ответы, выбирают обычно последний ответ в таких заданиях, ошибочно полагая, что он всегда самый правильный. Поэтому при разработке заданий по принципу кумуляции полезно иметь большую часть правильных ответов не на последнем месте.
5. Принцип сочетания. Используется сочетание слов (знаков) по два или по три, реже четыре, в каждом ответе.
Пример 1: сочетание более или менее однородных и правдоподобных пар ответов
Инструкция
: Выберите один правильный ответ.
Ф. Шопен писал
- оперы и симфонии
- балеты и оратории
- мазурки и ноктюрны
Пример 2: сочетание одного слова (понятия) с несколькими другими
Инструкция
: Выберите один правильный ответ.
НЕ имеют ядра клетки крови
- эритроциты и лейкоциты
- эритроциты и тромбоциты
- эритроциты и лимфоциты
- эритроциты и базофилы
Пример 3: сочетание ответов по правилу цепочки, когда последнее слово в первом ответе становится первым во втором ответе, последнее во втором – первым в третьем и т.д.)
Инструкция
: Выберите один правильный ответ.
Служебными частями речи являются
- предлоги, союзы, частицы
- частицы, союзы, местоимения
- местоимения, частицы, предлоги
6. При использовании принципа градуирования ответы располагаются по возрастанию (увеличению) или по убыванию (уменьшению). Этот принцип применим для заданий с тремя и большим числом ответов. Например:
Инструкция
: Выберите один правильный ответ.
Растворимость газов при повышении температуры
- увеличивается
- остается без изменений
- уменьшается
Согласно ч. 3 ст. 5.63 КоАП РФ, нарушение должностным лицом порядка или сроков рассмотрения жалобы влечет наложение административного штрафа в размере … рублей.
- от трех тысяч до пяти тысяч
- от пяти тысяч до десяти тысяч
- от десяти тысяч до пятнадцати тысяч
- от двадцати тысяч до тридцати тысяч
7. Принцип формулирования заданий с ответами, правильными в различной мере, требует изменения инструкции, содержания задания и логики подбора ответов.
Инструкция, как мы уже говорили, обычно пишется так: Выберите наиболее правильный ответ.
Задача таких заданий – проверить сопоставительные знания, а ответы формулируются так, чтобы был реальный выбор между ответами, правильными в разной степени. Например:
Инструкция
: Выберите наиболее правильный ответ.
Зигота – это
- одна яйцеклетка
- оплодотворенная яйцеклетка
- диплоидная клетка, образующаяся в результате оплодотворения
- одноклеточная стадия развития многоклеточного организма млекопитающих
В этом задании наиболее правильным считается третий ответ (он наиболее емко и точно описывает все характеристики зиготы), следующий по степени правильности – второй ответ (он содержит совершенно правильное, но менее полное определение зиготы), затем четвертый (потому что зиготы образуются не только у млекопитающих). На последнем месте по степени правильности находится первый ответ – он самый неполный, ведь одной яйцеклетки для образования зиготы явно недостаточно.
Задания на выбор наиболее правильного ответа разрабатывать довольно сложно: наиболее правильный ответ далеко не всегда должен быть самым полным. В противном случае тестируемый при выполнении задания будет выбирать правильный ответ только по признаку полноты.
Составили тест? Не поленитесь и пройдите по этому чек-листу.
Проверка качества тестовых заданий
- Соответствует ли задание целям тестирования?
- Все высказывания логичны?
- Все формулировки однозначны и лаконичны?
- Технологичен ли тест? (Задания становятся технологичными, если их содержание точно и быстро понимается испытуемыми, и если форма заданий способствует процессу компьютеризации тестирования)
- Правильно ли выбрана форма задания?
- Содержание корректно?
- Правила оценки ответов разработаны заранее и соответствуют форме теста?
- Правильно ли расположены элементы задания?
- Инструкции одинаковы для всех тестируемых?
- Инструкция соответствует форме и содержанию задания?
В этой статье мы обсудили основные аспекты составления тестовых заданий закрытой формы с одним или несколькими правильными ответами. Благодарю вас за внимание и терпение и надеюсь, что эта статья будет полезной для вас.
Если вы считаете, что стоит продолжить цикл подобных статей и поговорить о методике составления тестовых заданий других видов, напишите, пожалуйста, об этом в комментариях. А если вам нужны готовые инструменты оценки качества обучения, обращайтесь к нам в «Сетевую Академию ЛАНИТ». Будем рады помочь.
канд. пед. наук, доцент кафедры непрерывного профессионального образования КГУ. Автор массовых онлайн открытых курсов (ИКТ в образовательном процессе).
Эксперт: в области информационных технологий и учебного видео
Прежде чем мы перейдем к принципам разработки тестов, необходимо сделать ряд замечаний.
Различия между тестом и заданиями в тестовой форме
В обыденном сознании постоянно смешиваются понятия теста и системы заданий в тестовой форме (или предтестовых заданий).
Тест только тогда может считаться тестом, когда были произведены необходимые статистические расчеты – выявлены показатели трудности, надежности, валидности и ряд других.
Как правило, тест разрабатывается коллективом исследователей и апробируется в течении определенного времени. После апробации в тест вносятся коррективы. Тест состоит из тестовых заданий. В англоязычной литературе для обозначения теста употребляется термин «Quiz» (но не «Test»!).
Таким образом, преподаватель (учитель) не может создавать тесты. Вместо этого, он разрабатывает задания в тестовой форме, которые внешне похожи на тест, но не проходят статистической и иной апробации. Такие задания можно использовать в образовательном процессе для решения определенных педагогических задач.
Из этого следует принципиальная невозможность использования ряда характеристик теста. Например, трудность тестового задания определяется экспериментально, исходя из результатов большого объема выборки учащихся. На практике учитель не располагает как временем для проведения эксперимента, так и необходимым объемом выборки. Поэтому часто трудность определяется «на глазок».
В общем виде задания в тестовой форме (как и тестовые задания) отвечают следующим требованиям:
- краткость;
- технологичность;
- определённость цели;
- логическая форма высказывания;
- определенность места для ответов;
- одинаковость правил оценки ответов;
- правильность расположения элементов задания;
- одинаковость инструкции для всех испытуемых;
- адекватность инструкции форме и содержанию задания.
Так, краткость заданий в тестовой форме обеспечивается тщательным подбором слов, символов, графиков, позволяющих минимумом средств добиваться максимума ясности смыслового содержания задания. Технологичность заданий определяется как свойство, которое позволяет вести процесс тестирования с помощью технических средств, и делать это точно, быстро, экономично и объективно. Логическая форма высказывания – это средство упорядочения и эффективной организации содержания задания.
Формы тестовых заданий
Кроме того, принципы разработки тестовых заданий (заданий в тестовой форме) связаны с их формами. Разные авторы по-разному классифицируют формы тестовых заданий. Положение усугубляется тем, что каждая автоматизированная система для проведения тестирования называет одни и те же формы по-разному. Обобщим все многообразие форм тестовых заданий следующей классификацией.
- Верно/Неверно (Правда или Ложь, от анг. True or False) – содержит утверждение, с которым обучающийся должен либо согласиться, либо нет.
Например:
Первым президентом США был Джордж Вашингтон
- Верно
- Неверно
В ЕГЭ подобные задания встречаются в КИМах по иностранным языкам в заданиях на аудирование: учащиеся слушают текст, далее переходят к заданиям типа Правда или Ложь.
Данная форма тестовых заданий самая простая как для составления преподавателем, так и для ответа обучающимся. Такие формы задания характеризуются высокой степенью угадывания правильного ответа.
2. Множественный выбор (задания с выбором одного или нескольких правильных ответов). Эта самая распространённая форма тестовых заданий. Она содержит утверждение (вопрос) и альтернативные ответы.
Для заданий с выбором одного правильного ответа рекомендуется не менее 4 (если меньше, то вероятность угадывания правильного ответа увеличивается) и не более 6 (трудно придумать правдоподобные альтернативы).
Для заданий с выбором нескольких правильных ответов рекомендуется не менее 6 альтернатив.
3. Задания на установление соответствия. Оно представляет собой набор элементов в двух столбцах – обучающемуся нужно установить соответствие между элементами левого и правого столбцов. Наличие заголовка для каждого набора столбцов является обязательным – он позволяет учащемуся не тратить время на обобщение элементов в столбцах и сразу перейти к упражнению.
Сравните:
- a) Ярлык
- b) Улус
- c) Волостень
- d) Порок
- e) Плинфа
- Стенобитное сооружение
- Кирпич
- Ханская грамота
- Правитель волости
- Владение
Тоже задание, переформатированное с учетом специфических требований:
Древнерусские названия |
Современные аналоги |
a) Ярлык | 1. Стенобитное сооружение |
b) Улус | 2. Кирпич |
c) Волостень | 3. Ханская грамота |
d) Порок | 4. Правитель волости |
e) Плинфа | 5. Владение |
Как мы видим, во втором случае задание более читабельно, его смысл легко улавливается. Обратите внимание, что, например сервис OnlineTestPad и некоторые другие позволяют добавлять такие заголовки. Другие (как Moodle) не обладают таким функционалом. В этом случае необходимо писать полную инструкцию, например, «Установите соответствие между ….и….»
В бумажных тестах такой формы заданий для правильного ответа предлагается заполнить специальную табличку. Вариант со стрелочками считается менее технологичным для проверки, поэтому его следует избегать.
1 |
2 | 3 | 4 |
5 |
Также желательно устанавливать нечетное количество элементов левого и правого столбца, чтобы последний элемент выбирался не методом исключения.
Посмотрите на это задание:
Расположите имена русских полководцев в хронологической последовательности (по возрастанию) их деятельности
Дмитрий Пожарский
Алексей Ермолов
Михаил Скобелев
Алексей Орлов
Это тоже задание на установление соответствия, точнее, его разновидность – задание на установление правильной последовательности. Ряд зарубежных исследователей склонны к такому объединению. Именно поэтому, например в Moodle мы не найдем такой формы. Но ее легко можно сконструировать из задания на установление соответствия. Для наглядности немного переформатируем предыдущее задание:
Хронологическая последовательность (по возрастанию) их деятельности |
Полководцы |
1 | a. Дмитрий Пожарский |
2 | b. Алексей Ермолов |
3 | c. Михаил Скобелев |
4 | d. Алексей Орлов |
Мы видим классическое задание на соответствие, просто левый столбец представляет собой числовой порядок. Правильные ответы обучающийся также заносить в специальную таблицу.
Иногда описанные выше задания верно-неверно, множественного выбора и соответствия объединяют в группу заданий закрытого типа, которые обладают следующими общими чертами:
- Присутствует в явном виде правильный ответ, его нужно просто выбрать тем или иным способом;
- Ответы на вопросы можно угадать (вероятность угадывания вырастает с уменьшением количества альтернатив);
- Ответы можно припомнить
- Ответы можно подобрать логически, откинув явно неправильные альтернативы.
5. Дополнение (краткий ответ). В этих заданиях учащемуся необходимо дописать правильный ответ. Иногда такой тип заданий называют заданиями открытого типа. В отличие от рассмотренных выше форм тестовых заданий, такие стратегии как угадывание, припоминание правильного ответа и др. «не работают». Поэтому данный тип задания считается более трудным для обучающихся.
6. Эссе – краткий ответ учащегося по сути вопроса. Строго говоря эссе не является формой тестового задания, т.к. он не соответствует необходимым критериям краткости, технологичности и прочее. По нашему мнению, эссе было введено для преодоления известных трудностей при составлении типичных тестовых заданий, главные из которых – невозможность представить весь учебный материал в тестовом виде и репродуктивный характер типичных тестовых заданий.
Тем не менее в заданиях эссе должны быть предложен(ы) эталон(элементы) оптимального ответа вместе со стандартизованными правилами оценки результатов его выполнения.
Пример:
При каких значениях х соответственные значения функций f(х)=log2x и g(х) = log2(3 – х) будут отличаться меньше, чем на 1?
Критерии для оценивания правильного ответа
Баллы | Критерии оценки выполнения задания 9 |
2 | Приведена верная последовательность шагов решения:
1) составление неравенства, содержащего модуль; 2) решение неравенства. Все преобразования и вычисления проведены правильно, получен верный ответ |
1 | Приведена верная последовательность шагов решения. При решении неравенства в шаге 2 допущена описка и/или негрубая вычислительная ошибка, не влияющая на правильность дальнейшего хода решения. В результате этой описки и/или ошибки может быть получен неверный ответ |
0 | Все случаи решения, не соответствующие указанным выше критериям выставления оценок в 1 или 2 балла |
Принципы разработки заданий в тестовой форме
Следующее, на чем нас стоит остановиться – на принципах разработки заданий в тестовой форме.
Долгое время существовала убеждённость, что тест сам по себе является объективным средством контроля. Однако затем пришло понимание, что тест обеспечивает, в первую очередь процедурную объективность. Для оценки же качества теста существует ряд смежных направлений – надежность (гарантия отсутствия в тесте случайных ошибок), валидность (гарантия, что тест измеряет именно то, что он должен измерять), трудность и т.д. Как мы указывали выше, все эти параметры разрабатываются на основе различных математических моделей в ходе экспериментальной работы авторского коллектива и недоступны для учителей, преподавателей. Поэтому мы лишь остановимся на ряде теоретических требований к разработке заданий в тестовой форме.
- Начинайте конструировать задание с правильного ответа. Часто так случается, что задание формально содержит больше правильных ответов, чем запланировано. Встречаются и обратные случаи – задание вообще не содержит правильного ответа.
- Содержание задания опирается на требования программы и отражает предметное (метапредметное) содержание. Иногда в тест пытаются включить вопросы, правильного ответа на которые просто не существует.
Например:
Мы будем изучать латинский язык потому, что…
- На нем говорят во многих странах мира
- Хотим лучше понимать родной язык, так как в нём много слов, заимствованных из латыни
- Хотим лучше понимать историю и культуру древнего мира
Это хорошее задание. Но его следует использовать в социологическом опросе, а не в заданиях на проверку учебных достижений.
- Вопрос должен быть направлен на выявление одного элемента знания, одной законченной мысли. В противном случае трудно диагностировать причину невыполнения задания.
Конфуций ..
- жил в Африке
- жил в Китае
- был врачом
- был правителем
- был философом
Данное задание направленно на выявление сразу двух элементов – где жил Конфуций и кем он был. Необходимо разделить эти два вопроса.
- При составлении вопросов следует избегать слов «иногда», «часто», «всегда», «мало», «больше» и т.д. Подобные слова имеют субъективное значение и могут приводить к ошибочным ответам. Тестовые задания (задания в тестовой форме) должны иметь четкий однозначный ответ.
- Избегайте вводных фраз или предложений, имеющих мало связи с основной мыслью, не следует прибегать к пространным утверждениям.
Например:
«Анадырская впадина. Очень плоско, и Анадырь по ней виляет огромным удавом… «Анадырь – жёлтая река», – можно так назвать потом очерк. Тундра и озёра по всей впадине. Трудно понять, чего больше: или озёр, или земли» (О. Куваев). В какое море впадает эта река?
Вполне понятно желание авторов разнообразить задание в тестовой форме, сделать его более поэтичным. Однако прочтение вводной части занимает много времени и размывает суть задания.
- Правильные ответы должны быть правдоподобны, умело подобраны, не должно быть явных неправильных ответов (они являются своеобразной подсказкой – данный ответ уж точно является ошибочным). Неправильные ответы, очень похожие на правильные, называют дистракторами. Например:
Родина Карла Маркса:
- Трир
- Карл-Маркс-Штадт
- Штургард
- Мюнхен
Здесь можно предположить, что город Карл-Маркс-Штадт получил свое название потому, что в именно в нем родился Карл Маркс. Однако правильный ответ – Трир.
- Не следует задавать вопросы с подвохом – скорее всего в заблуждение будут введены наиболее способные или осведомленные учащиеся, которые знают достаточно для того, чтобы попасться в ловушку, а также это противоречит цели – определению уровня знаний и понимания.
- Следует использовать более длинные вопросы и более короткие ответы, грамматически согласованные с основной частью задания.
Например:
Какое суждение верно?
- Неполные предложения ‒ это предложения, в которых пропущен один из главных членов
- Неполные предложения ‒ это предложения, в которых пропущен один из второстепенных членов
- Неполные предложения ‒ это предложения, в которых пропущен какой-либо член предложения ‒ главный или второстепенный
Нетрудно увидеть, что здесь есть повторяющееся словосочетание, которое и следует вынести в формулировку задания:
Неполные предложения ‒ это предложения, в которых пропущен
- один из главных членов
- один из второстепенных членов
- какой-либо член предложения ‒ главный или второстепенный
- Не используйте отрицание в основной части вопроса. Во-первых, это приводит к непониманию сути задания. Во-вторых, объектом контроля должны быть элементы знания, а не элементы незнания.
Например:
Жили ли или нет эти люди в реальности в Древней Греции?
- Гомер
- Ахилл
- Зевс
- Перикл
- Фидий
- Аристотель
- Сократ
В данном случаи не ясно как отвечать – да жили, или да не жили. Поэтому вопрос нужно сформулировать более точно, например: Назовите мифологических персонажей Древней Греции.
- При чередовании правильных ответов в вопросах не должно быть явной системы – например, всегда только 1 варианты правильные, или правильными вариантами являются последовательно первый, второй, третий, четвертый вариант. В компьютерном тестировании обычно такой проблемы не существуют, потому что компьютер автоматические перетасовывает альтернативы.
- Если ставится вопрос количественного характера, то необходимо указать последовательность (от меньшего к большему или наоборот) выбора правильных ответов.
Например:
Удаленность от Солнца
a) Сатурн
b) Меркурий
c) Земля
d) Уран
e) Венера
f) Марс
В данном пример существуют как бы два набора правильных вариантов ответов – одна последовательность от наиболее близкой планеты от Солнца, другая – от наиболее удаленной.
- Вопрос и ответ должны отличаться шрифтовым и пространственным оформлением. Например, вопрос (задание) выделяется жирным шрифтом, ответ – обычным. Для записи ответов используются дополнительные отступы. Но это правило касается только бумажных тестов – в компьютерных автоматизированных системах оформление задается программное, которое изменять не целесообразно.
И помните – не каждое задание можно представить в виде тестового контроля.
При написании статьи использовались примеры http://koi.tspu.ru/koi_books/samolyuk/
Изображение с сайта Freepik