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

СУБД «Почтовое отделение» создана для удобного хранения, просмотра и исправления информации на аптечном складе. Главная форма является первым шагом в работе с этой СУБД. Описание главной формы:

Кнопка «Отправления» открывает форму, которая содержит полную информацию об отправлениях.

Кнопка «Получения» открывает форму, которая содержит полную информацию о получениях.

Кнопка «Подписка» открывает форму, которая содержит полную информацию о подписках.

Форма «Получения» содержит:

Кнопка «письма» открывает форму содержащую информацию о полученных письмах.

Кнопка «посылки» открывает форму содержащую информацию о полученных посылках.

Кнопка «бандероли» открывает форму содержащую информацию о полученных бандеролях.

Кнопка «Отчет» открывает отчет по получениям.

Форма «Отправка» содержит:

Кнопка «письма» открывает форму содержащую информацию об отправленных письмах.

Кнопка «посылки» открывает форму содержащую информацию об отправленных посылках.

Кнопка «бандероли» открывает форму содержащую информацию об отправленных бандеролях.

Кнопка «Отчет» открывает отчет по отправке.

Форма «Подписка» содержит:

Кнопка «Действующая» открывает форму, которая отображает информацию о действующих подписках.

Кнопка «Дешевая » открывает форму, которая содержит информацию о недорогой подписке.

Кнопка «Отчет» открывает отчет по подписке.

ЗАКЛЮЧЕНИЕ

Проектирование базы данных представляет собой длительный и трудоемкий процесс. Качество созданной базы данных зависит от анализа предметной области и выбранной методологии проектирования. При неполном анализе предметной области в процессе эксплуатации созданной базы данных может возникать избыточное дублирование данных, а так же различные аномалии, что, скорее всего, приведет к потере необходимых данных и повторному проектированию базы данных. Процесс последующего проектирования базы данных не менее ответственный, так как необходимо четко выявить необходимые сущности и согласно связям между ними сформировать отношения. Процесс реализации базы данных средствами СУБД является преобразованием выполненного проектирования на ЭВМ.

Целью являлось проектирование базы данных «Почтовые отделения» средствами СУБД FOXPRO.

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

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

– перечень запросов на предоставление справочной информации;

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

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

Результаты проведенного анализа должны быть сгруппированы должным образом и представлены в виде отчета на бумажном носителе.

Второй этап проектирования делится на две фазы, первая из них это выбор методологии проектирования, а вторая — проектирование базы данных «Почтовые отделения». Для проектирования моей базы данных я выбрал метод «сущность-связь» и метод нормальных форм.

Третий этап проектирования заключается в реализации базы данных «Почтовые отделения» с помощью СУБД Microsoft Visual FOXPRO.

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

Как с помощью руководства пользователя повысить качество информационной системы

В действительности все совершенно иначе, чем на самом деле.
Антуан де Сент-Экзюпери

Многое в разработке руководства пользователя регламентировано и описано ГОСТами. Но при создании больших гетерогенных систем могут возникать вопросы, не до конца освещенные этими документами.

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

Статья будет полезна для тестировщиков, технических писателей, аналитиков и даже для руководителей проектов.

Описание проблемы

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

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

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

2. Параллельная разработка.
Из-за масштаба системы над ней работают изолированные команды аналитиков, разработчиков и тестировщиков.

3. Частые изменения.
Опять же следствие масштаба — постоянный поток изменений и доработок.

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

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

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

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

Нужно было срочно исправлять ситуацию. Причем сделать это с минимальными затратами.

Поиск решения

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

Неактуальность документа

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

1. Составить описание модели «AS IS» (т.е. что у нас есть сейчас, какие функции и бизнес-процессы описаны).
2. Описать модель «TO BE» (в качестве консультантов привлекались ведущие аналитики по каждой подсистеме).
3. Сравнить «AS IS» и «TO BE» с помощью индикатора «Светофор» и составить план действий.

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

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

Далее наглядным индикатором «Светофор» были отмечены результаты сравнения:

1. Зеленый цвет – процесс есть в руководстве и нужен в бизнесе.
2. Красный – процесс есть, но не нужен (удалить!).
3. Желтый – процесс отсутствует, но нужен (добавить!).
4. Серый – процесс отсутствует и не нужен.

Использование цветовых индикаторов позволило выявить общую картину: руководство пользователя нужно править… и существенно.

Рисунок 1

Началась работа над документом. Подспорьем на данном этапе опять же стала таблица: если процесс редактируется в одном блоке, то и в другом он создается схожим процентов на 80 образом.

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

Рисунок 2

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

Таблица соответствия в ходе работы над документом:

Рисунок 3

По завершении «покрасочных» работ обозначились приоритеты:

1. убрать оранжевый цвет – все должно быть описано корректно;
2. cделать светло-зеленые поля ярко-зелеными.

На этом моменте важно вспомнить про закон Парето (принцип 20/80): мы относительно быстро исправили наиболее проблемные оранжевые области и долго работали над светло-зелеными. Ведь в них, собственно, вся суть, если мы стремимся к тому, чтобы пользователь действительно мог работать с руководством.

Отсутствие единообразия

При решении этой проблемы ставилась задача обеспечить единообразие при описании сходных процессов (кейсов) и существенно сократить трудозатраты на обновление и поддержание документа. Был выбран подход, в соответствии с которым описание каждого процесса представляется в виде строительного блока (1), а сам документ – их комбинации (3). Все строительные блоки должны располагаться в репозитории (Wiki) с обязательным контролем изменений и поддержкой версионности (2).

Рисунок 4

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

Принципиально важный момент: доступ к репозиторию должен быть обеспечен всем командам, работающим над проектом, согласно сформированному регламенту его использования.
Используя такой подход для актуализации и метод «строительных блоков» для сборки, документ удалось за короткий срок привести в надлежащее состояние. Трудозатраты сократились более чем на 30%, по сравнению с традиционным методом формирования документа. Казалось бы, на этом месте можно было бы обозначить happy end, но мне бы хотелось продолжить. Будет интересно.

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

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

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

Рисунок 5

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

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

Рисунок 6

Выводы

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

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

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

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

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

---

P.S. В статью не вошли вопросы содержательности элементов и разделов руководства пользователя. Подробно это рассмотрено и регламентировано подразделом 3.4 документа РД 50-34.698-9 и стандартом IEEE 1063-2001.

Структура и содержание документов Руководство оператора, Руководство программиста, Руководство системного программиста регламентированы ГОСТ 19.505-79, ГОСТ 19.504-79 и ГОСТ 19.503-79 соответственно.

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

---

Подборка по базе: ТЕСТ Заключение.docx, Методическое руководство.docx, Памятка пользователя в МИС.pdf, Базисное руководство по психотерапии.pdf, 10-11. Руководство для учителей биологии по методике организации, прил.1 Заключение о допуске УПРАВЛЕНИЕ.doc, 3. ViPNet_Client_4U_for_Linux Руководство пользователя.pdf, 5. Сканер-ВС анализ защищенности Руководство пользователя.pdf, Руководство пользователя.docx, Методическое руководство по выполнению практических работ в 1С А

---

Содержание

Введение

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

1 Характеристика организации

1. Структура, инфраструктура организации. Основные направления деятельности

Характер деятельности — коммерческий.

Форма собственности — частная.

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

Для поддержки стабильности основной деятельности наша фирма планирует предложить клиентам следующее:

 производство мягкой мебели для дома: комплекты, состоящие из кресел и диванов, отдельно диваны, кресла;

 производство корпусной мебели: шкафы;

 производство столов и стульев;

 ремонт мебели;

 доставка мебели по месту назначения.

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

На фабрике работают 5 мастеров, каждый из которых «ведет» несколько заказов. Мастер занимается всеми операциями — от распилки пиломатериалов до обтяжки мебели тканью.

У фабрики также есть собственный дизайнер-технолог, который занимается разработкой новых моделей мебели.

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

На ООО «Кураж» используют в работе Средства МS Оffice.

МS Оffice применяется для разных участков экономической деятельности предприятия:

— учет товарных и материальных средств;

расчет заработной платы.

Что касается аппаратно-программного обеспечения, то на ООО «Кураж» имеется восемь компьютеров, пять принтеров, сетевое оборудование для объединения компьютеров в локальную сеть.

Список программного обеспечения, используемого предприятием:

— MICROSOFT WINDOWS 7 — Базовый комплекс компьютерных программ, обеспечивающий интерфейс пользователя, управление аппаратными средствами компьютера, работу с файлами, ввод и вывод данных.

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

ООО «Кураж» следит за состоянием вычислительной компьютерной техникой. Устаревающая техника регулярно обновляется и поэтому в главном офисе предприятия установлены современные производительные компьютеры на базе процессора AMD Athlon(tm) II X2 265 3.30GHz. Оперативная память — 4 Гбайт, объем жесткого диска-160 Гбайт.

Так же на предприятии учет данных ведется на основе базы данных Microsoft Access с оболочкой в Delphi 7.

1. Разработка проекта и специфики программного продукта с использованием средств проектирования

2.1 Разработка кода программного продукта на языке Delphi

В ходе практики я провела анализ технической документации на уровне взаимодействия компонентов программного обеспечения.

Проанализировала программную систему и выбрала язык программирования Delphi 7, так как на нем написана оболочка ПО используемого на предприятии. Технология Delphi разработана с целью ускорения и унификации процессов разработки и интеграции программного обеспечения. В основу технологии положен принцип интеграции программных комплексов в единую информационно-аналитическую систему с помощью единой консоли и модулей, обеспечивающих определенную функциональность.

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

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

В ходе прохождения практики было осуществлено тестирование программного модуля.

Тестирование проводилось с двумя целями:

 продемонстрировать разработчикам и заказчикам, что программа соответствует требованиям;

 выявить ситуации, в которых поведение программы является неправильным, нежелательным или не соответствующим спецификации.

Тестирование проводилось в ручном режиме, без использования автоматизированных систем.

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

I этап тестирования.

Характеристика программного модуля «Авторизация».

Имя модуля: «Авторизация».

Входные параметры: имя пользователя, пароль.

Выполняемые функции: это модуль защиты информационной системы от несанкционированного доступа. Здесь производится проверка имени пользователя и пароля и определения для него прав доступа.

Выходные данные: уровень доступа.

Особенности: нет.

Требования к функциональным характеристикам модуля

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

 идентификация уникального пользователя;

 разграничение прав доступа;

 обеспечение безопасности от несанкционированного доступа или воздействия.

Требования к надежности.

Модуль «Авторизация» должен нормально функционировать в информационной системе мебельного магазина при бесперебойной работе компьютера.

Требования к аппаратному и программному обеспечению.

Для корректной работы программы необходима установленная на компьютере ОС Windows 7, мышь, клавиатура.

II этап тестирования.

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

 Функциональные

 Нефункциональные

 Связанные с изменениями

Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.

Преимущества функционального тестирования:

 имитирует фактическое использование системы;

Недостатки функционального тестирования:

 возможность упущения логических ошибок в программном обеспечении;

 вероятность избыточного тестирования.

Далее был составлен сценарий для ручного тестирования (таб.1)

Таблица 1. Сценарий для ручного тестирования.

№	Шаг сценария	Условие сценария	Результат выполнения
1	Запустить модуль «Авторизация»	Нажать на кнопку «Вход», расположенной в нижней части программы	Появление окна «Авторизация»
2	Ввести имя пользователя в поле «Пользователь» и пароль в поле «Пароль»	Нажать на кнопку «Вход» в окне «Авторизация»	Поиск соответствия имени пользователя по базе учетных записей. Проверка подлинности пользователя путем сравнения введенного им пароля с паролем сохраненным в базе учетных записей
3	Вводимое имя пользователя и пароль соответствует имеющейся учетной записи		Вход в систему под введенным именем пользователя
3.1	Вводимое имя пользователя не соответствует не одной учетной записи находящейся в базе учетных записей		Появление окна с ошибкой
3.2	Вводимый пароль не соответствует паролю от данной учетной записи		Появление окна с ошибкой

III этап тестирования

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

Рисунок 1. Окно «Ошибка при входе в учетную запись»

3 Техническая документация

3.1 Руководство пользователя

Описание программного модуля «Авторизация»

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

Рис. 2 — Расположение кнопки «Вход»

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

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

Рис. 5 — Пример отображения информации о правах пользователя

Следует заметить, что после авторизации, кнопку в нижней части экрана с надписью «Вход», изменит свое значение на «Выход», и повторное нажатие на нее, позволит выйти из системы.

Заключение

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

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

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

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

Список использованных источников

1. Федоров А. Г. Создание Windows-приложений в среде Delphi / А. Г. Федоров. — М. : ТОО «Компьютер Пресс», 1999. — 347 с.
2. Кетков Ю.Л.Практика программирования: Visual Basic, C++ Builder, Delphi: производственно-практическое издание / Ю. Л. Кетков, А. Ю. Кетков. ­– СПб.: БХВ-Петербург, 2010. – 464 с
3. Павловская Т.C/C++. Структурное и объектно-ориентированное программирование: практикум / Т.Павловская, Ю.Щупак. – СПб.: Питер, 2011. – 352 с.
4. Фаронов В.Delphi. Программирование на языке высокого уровня: учеб. для вузов / В.Фаронов. – СПб.: Питер, 2003. – 640 с.
5. Гниденко, И. Г. Технология разработки программного обеспечения : учеб. пособие для СПО / И. Г. Гниденко, Ф. Ф. Павлов, Д. Ю. Федоров. — М. : Издательство Юрайт, 2017. — 235 с.

Приложение

Unit5

unit Unit5;

interface, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, StdCtrls, DBCtrls, DB, IBCustomDataSet, IBQuery, dblookup;= class(TForm): TEdit;: TLabel;: TLabel;: TIBQuery;: TDataSource;: TComboBox;: TButton;: TButton;FormCreate(Sender: TObject);Button2Click(Sender: TObject);ComboBox1Change(Sender: TObject);Button1Click(Sender: TObject);

{ Private declarations }

{ Public declarations };: TLogin;Unit1;

{$R *.dfm}TLogin.Button1Click(Sender: TObject);.Close;;TLogin.Button2Click(Sender: TObject);.First;.MoveBy(ComboBox1.ItemIndex);IBQuery1.FieldByName(‘PASS’).AsString = Edit1.Text then

ShowMessage(‘Авторизация прошла успешно! Вы вошли с правами ‘+

IBQuery1.FieldByName(‘NAME’).AsString);IBQuery1.FieldByName(‘SELECT_GOODS’).AsInteger = 1 then.MODE[1]:= true else Unit1.MODE[1]:= false;IBQuery1.FieldByName(‘SELECT_SALES’).AsInteger = 1 then.MODE[2]:= true else Unit1.MODE[2]:= false;IBQuery1.FieldByName(‘EDIT_GOODS’).AsInteger = 1 then.MODE[3]:= true else Unit1.MODE[3]:= false;IBQuery1.FieldByName(‘ADD_GOODS’).AsInteger = 1 then.MODE[4]:= true else Unit1.MODE[4]:= false;IBQuery1.FieldByName(‘SUPER’).AsInteger = 1 then.MODE[5]:= true else Unit1.MODE[5]:= false;.MODENAME := IBQuery1.FieldByName(‘NAME’).AsString;.USERNAME := IBQuery1.FieldByName(‘FN’)

.AsString + ‘ ‘ + IBQuery1.FieldByName(‘LN’)

.AsString + ‘ ‘ + IBQuery1.FieldByName(‘PN’).AsString;.Button5.Caption:= ‘Выход’;.IDUSER:= IBQuery1.FieldByName(‘ID’).AsInteger;.Clear;.Close;

ShowMessage(‘Пароль введен неверно, пожалуйста повторите ввод’);

end;;TLogin.ComboBox1Change(Sender: TObject);.Clear;;TLogin.FormCreate(Sender: TObject);: byte;: string;IBQuery1 do;.Clear;.Add(‘SELECT .ID,FN,LN,PN,PASS,NAME,SELECT_GOODS,SELECT_SALES,’

+

‘EDIT_GOODS,ADD_GOODS,SUPER FROM USERS,USER_TYPE USERS.TYPE=USER_TYPE.ID’);;;i := 0 to IBQuery1.RecordCount do:= IBQuery1.FieldByName(‘FN’)

.AsString + ‘ ‘ + IBQuery1.FieldByName(‘LN’)

.AsString + ‘ ‘ + IBQuery1.FieldByName(‘PN’).AsString;.Items.Add(t);.Next;;.ItemIndex:=0;;.Unit6;, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, StdCtrls, ExtCtrls;= class(TForm): TLabel;: TLabel;: TLabel;: TLabel;: TLabel;: TLabel;: TLabel;: TLabel;: TLabel;: TLabel;: TLabel;: TImage;: TImage;: TImage;: TImage;: TImage;: TButton;Button1Click(Sender: TObject);FormCreate(Sender: TObject);

{ Private declarations }

{ Public declarations };: TAboutR;

{$R *.dfm}TAboutR.Button1Click(Sender: TObject);.Close;;TAboutR.FormCreate(Sender: TObject);;.

Существует множество видов предоставления справочной информации пользователю – это и FAQ (frequently asked questions, часто задаваемые вопросы) и онлайн справка и руководство пользователя (user guide) и популярные сегодня подсказки (coachmarks, см. пример ниже), обучающие видео и другие.

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

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

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

 1. Стандарты

Часто бывает нужно написать документ, который бы удовлетворял требованиям действующих стандартов. Это могут быть:

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

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

Также может оказаться полезной книга Юрия Кагарлицкого MetaGuide. Руководство для разработчиков технической документации к программному обеспечению.

2. Структура

Хорошо продумайте структуру документа: она должна покрывать все функциональные возможности системы, быть полной и понятной.

Хорошее руководство пользователя должно содержать:

• Аннотацию, в которой приводится краткое изложение содержимого документа и его назначение. Также рекомендуется писать краткую аннотацию в начале каждого крупного раздела.
• Введение, содержащее информацию о том, как лучше всего использовать данное руководство
• Содержание
• Главы, описывающие, как использовать ПО
• Глоссарий и
• Предметный указатель

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

• FAQ и ответы на них
• Ссылки на дополнительную информацию по системе
• Раздел, описывающий возможные проблемы и пути их решения

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

3. Пользователи

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

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

Уважайте пользователей системы, не пишите инструкции в пренебрежительном стиле.

4. Особенности изложения

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

Стиль руководства должен быть нейтрально-формальным – использование стилистически окрашенных слов отвлекает пользователя от сути.

Для составления хорошего документа пригодятся знания грамматики и немного психологии.

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

Хорошо: In File menu, select Save item.
Хуже: Select Save item from File menu.

4.2 Используйте повелительное наклонение, не употребляйте вежливые обороты (please, could и т.д.) — излишняя вежливость именно здесь будет помехой.

Хорошо: Click Logout to log out current user account from the system.

Хуже: It is needed to click Logout to log out current user account from the system.

Хуже: If user wants to log out current user account from the system (s)he needs to click Logout. 

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

Хорошо:
To create project:

1. Click the Create button on toolbar.
2. On the Create Project overlay fill in all mandatory fields.
3. Click the Save button to save the project.

Хуже: To create project click the Create button on toolbar, on the Create Project overlay fill in all mandatory fields, click the Save button to save the project.

4.4 Не используйте будущее или прошлое время.  Например, часто встречаются руководства, в которых реакция системы на действие пользователя передается фразами, сформулированными в будущем времени. У ПО нет прошлого или будущего: всё случается в настоящем как прямой результат конкретного действия пользователя. Как только событие случается, ПО реагирует.

Хорошо: When user clicks the Start button, the program starts the process.

Хуже: When user clicks the Start button, the program will start the process.

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

Например, глагол «press» означает нажатие клавиши на клавиатуре, а «click» – нажатие кнопки или значка в окне программы при помощи мыши, а «hit» вообще является жаргонным словом.

Разумеется, орфографические ошибки недопустимы.

4.6 Не используйте синонимы для одного и того же термина. В IT литературе на английском (или любом другом) языке есть стандартный набор глаголов, обозначающих действия (click, double-click, select, type, press и т.д.) и такой же стандартный набор названий элементов управления. Определитесь с терминологией и придерживайтесь ее в рамках всего документа.

Например, не допускайте, чтобы в одной части документа выпадающий список назывался dropdown, а в другой точно такой же элемент – combobox или dropdown list. Это путает пользователя.

4.7 Разумно используйте сокращения и исключите жаргон.

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

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

5. Внешний вид

5.1 Продумайте стиль документа. Это может быть корпоративный шаблон или цветовая схема ПО или специально сделанный для документа дизайн.

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

5.2 Не экономьте место – разбивайте текст на короткие абзацы, используйте сравнительно крупные заголовки, начинайте новый раздел с новой страницы. Это облегчит восприятие прочитанной пользователем информации.

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

6. Поддержка

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

Заключение

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

Помните главное: документ должен помогать пользователям.

Статью подготовила

Тарасюк Надежда, участник сообщества analyst.by,

аналитик с 6-летним опытом в сфере.