Пример инструкции к программе

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

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

Типы документации
Существует четыре основных типа документации на ПО:

• архитектурная/проектная — обзор программного обеспечения, включающий описание рабочей среды и принципов, которые должны быть использованы при создании ПО
• техническая — документация на код, алгоритмы, интерфейсы, API
• пользовательская — руководства для конечных пользователей, администраторов системы и другого персонала
• маркетинговая

Архитектурная/проектная документация

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

Как писать инструкции для людей? Работа персонала по инструкциям

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

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

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

Часто при составлении технической документации используются автоматизированные средства — генераторы документации, такие как Doxygen, javadoc, NDoc и другие. Они получают информацию из специальным образом оформленных комментариев в исходном коде, и создают справочные руководства в каком-либо формате, например, в виде текста или HTML. Использование генераторов документации и документирующих комментариев многими программистами признаётся удобным средством, по различным причинам. В частности, при таком подходе документация является частью исходного кода, и одни и те же инструменты могут использоваться для сборки программы и одновременной сборки документации к ней. Это также упрощает поддержку документации в актуальном состоянии.

Пользовательская документация

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

Всё, что нужно знать о должностных инструкциях за 6 минут

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

Обычно, пользовательская документация представляет собой руководство пользователя, которое описывает каждую функцию программы, а также шаги, которые нужно выполнить для использования этой функции. Хорошая пользовательская документация идёт ещё дальше и предоставляет инструкции о том, что делать в случае возникновения проблем. Очень важно, чтобы документация не вводила в заблуждение и была актуальной. Руководство должно иметь чёткую структуру; очень полезно, если имеется сквозной предметный указатель. Логическая связность и простота также имеют большое значение.

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

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

Маркетинговая документация

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

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

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

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

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

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

Прошло много лет, программирование происходит в среде совершенно новых технологий, многие программисты, работая в стиле drag-and-drop, могут годами не видеть текст своих программ. Это не значит, что исчезла необходимость в их документировании. Более того, вопросы о наличии хоть какой-то системы, регламентирующей эту сторону создания программных средств, продолжают задавать постоянно. Спрашивают и о том, есть ли обязательные для применения стандарты (особенно остро стоит этот вопрос, когда разработка выполняется по заказу государственной организации или предприятия). Интересуются и тем, где можно купить имеющиеся стандарты.

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

Техническое задание

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

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

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

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

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

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

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

В связи с этим следует различать две категории пользователей: ординарных пользователей программы и администраторов. Ординарный пользователь программы (end-user) использует программу для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью данной программы.

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

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

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

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

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

Руководство по инсталляции программного средства

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

Инструкция по применению программного средства

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

Справочник по применению программного средства

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

Руководство по управлению программным средством

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

Руководство программиста

Документация по сопровождению программного средства (system documentation) описывает программное средство с точки зрения ее разработки.

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

Документация по сопровождению программного средства можно разбить на две группы:
1. документация, определяющая строение программ и структур данных ПС и технологию их разработки;
2. документацию, помогающую вносить изменения в программное средство.

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

• Внешнее описание программного средства (Requirements document).
• Описание архитектуры программного средства (description of the system architecture), включая внешнюю спецификацию каждой ее программы.
• Для каждой программы программного средства — описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля.
• Для каждого модуля — его спецификация и описание его строения (design description).
• Тексты модулей на выбранном языке программирования (program source code listings).
• Документы установления достоверности программного средства (validation documents), описывающие, как устанавливалась достоверность каждой программы программного средства и как информация об установлении достоверности связывалась с требованиями к программному средству.

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

Документация второй группы содержит

• Руководство по сопровождению программного средства (system maintenance guide), которое описывает известные проблемы вместе с программным средством, описывает, какие части системы являются аппаратно- и программно- зависимыми, и как развитие программного средства принято в расчет в его строении (конструкции).
• Общая проблема сопровождения программного средства — обеспечить, чтобы все его представления шли в ногу (оставались согласованными), когда программное средство изменяется. Чтобы этому помочь, связи и зависимости между документами и их частями должны быть зафиксированы в базе данных управления конфигурацией.

Процесс управления конфигурацией

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

Данный процесс состоит из шести работ. Общее число задач по данным работам равно 6.

1. Подготовка процесса управления конфигурацией — разработка плана управления конфигурацией. Тип выходного результата задачи — план.
2. Определение конфигурации — Определение схемы обозначения программных объектов и их версий (объектов программной конфигурации) и документации, в которой фиксируется состояние их конфигурации. Тип выходного результата задачи — описание.
3. Контроль конфигурации — Регистрация заявок на внесение изменений; анализ и оценка изменений; принятие или непринятие заявки; реализация, верификация и выпуск измененного программного объекта; обеспечение аудиторских проверок изменений.
4. Учет состояний конфигурации — Подготовка протоколов управления конфигурацией и отчетов о состоянии контролируемых программных объектов. Тип выходного результата задачи — протокол, отчет.
5. Оценка конфигурации — Определение и обеспечение функциональной законченности и физической завершенности программных объектов. Тип выходного результата задачи — протокол, отчет.
6. Управление выпуском и поставка — Контроль выпуска и поставки программных продуктов и документации.

Источник: technologiarpo.blogspot.com

РАЗРАБОТКА ДОКУМЕНТАЦИИ

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

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

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

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

Назначение программного обеспечения;

Условия применения программного обеспечения;

Подготовка программного обеспечения к работе;

Назначение программного обеспечения

Как написать статью-инструкцию или пошаговое руководство

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

Например, «Руководство по использованию СВЧ-печи», «Как вылечить дерматит у ребёнка», «Пошаговый рецепт приготовления лазаньи» и «Продвигаем сайт в ТОП: исчерпывающая инструкция». Сегодня вы узнаете, зачем нужны пошаговые руководства и где их можно использовать. Получите чёткий план написания статьи-инструкции с полезными советами.

Зачем нужны инструкции и где их можно использовать

• На инфосайтах и в медиа для привлечения трафика. Примеры: «Как написать коммерческое предложение», «5 шагов для создания роз из фоамирана», «Ремонтируем клавиатуру за полчаса».
• На коммерческих сайтах в блоге для своих клиентов (обычно это статьи о продукте/услуге). Например, «Как пользоваться сервисом eLama», «Выбираем велосипед ребёнку», «Как заказать статью».

Правила составления и написания статей-инструкций

Контент должен быть:

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

Как сделать инструкцию экспертной, если вы не эксперт?

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

Как написать пошаговую инструкцию: наглядный пример

Рассмотрим поочерёдно все этапы.

1. Выбор темы

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

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

Запомните: одна инструкция — одна тема. Распыляться не стоит.

2. Выбор формата инструкции

Выберите наиболее подходящий вид руководства:

1. «Инструмент для…» — расскажите об инструменте/методике из вашей отрасли, которые мало кто использует правильно;
2. «Проблема и её решение» — озвучьте актуальную для ЦА проблему и предложите несколько практик, рекомендаций для её решения;
3. «Экспертная оценка» — проанализируйте новинку на рынке товаров, известный факт, событие или книгу, дайте полезный совет;
4. «Вопрос-ответ» — опишите проблемную ситуацию, с которой к вам обратился клиент, распишите подробно варианты решения;
5. «Практические рекомендации» — предоставьте читателям пошаговую методику решения проблемы (или несколько методик).

3. Выбор названия

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

1. «Простой/уникальный способ…»;
2. «Как…»;
3. «Краткая инструкция…»;
4. «Теперь вы сможете»;
5. «Создайте…»;
6. «Быстрое/бесплатное решение…»;
7. «10 шагов для…»;
8. «Метод…»;
9. «Это обязан знать каждый…»;
10. «Секрет…».

4. Глубокое изучение вопроса

Ваша задача — досконально изучить проблему аудитории и найти решение. Проведите личный эксперимент, на основе которого будете писать руководство.

5. Составление плана

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

6. Подробное рассмотрение всех шагов

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

Обычно структура этапов строится по следующей схеме:

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

7. Добавление визуального контента

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

8. Вычитка текста

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

1. Всё ли вам понятно в инструкции, нет ли сложных предложений и трудных терминов?
2. Перечислено ли то, что следует взять и проверить перед началом работы?
3. Соблюден ли порядок этапов, ничего не пропущено?
4. Учтены ли все подводные камни и тонкости, с которыми может столкнуться читатель?
5. Есть ли чересчур большие этапы, которые лучше разбить на отдельные блоки
6. Имеются ли ненужные подробности (их следует убрать, чтобы не размывать тему)?

9. Проверка уникальности

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

Проверить уникальность текстов можно с помощью специальных сервисов.

Заключение

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

В руководство можно вставить цитату эксперта и после публикации попросить его добавить ссылку на статью в своём блоге или социальной сети.

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

Источник: quasa.io