Как написать руководство пользователя программы или сайта — инструкции, советы, помощь, программное обеспечение
Журавлев Денис
Что такое руководство пользователя и для чего его создавать
Ежедневно создаются новые продукты, программы, сервисы и часто пользователям приходится несладко при освоении какой-нибудь сложной программы, поэтому каждому новому продукту желательно собственное руководство. Для чего?
Большинство людей не хочет разбираться с чем-то незнакомым без персонального, всегда доступного и понятного помощника. А именно им и является хорошее руководство пользователя.
Общие советы по созданию пользовательской документации
Перед тем как приступить к созданию руководства, нужно определиться с некоторыми важными моментами. Например, определить, для кого вы его пишете? Кто его будет читать — рядовые пользователи, для которых важны базовые функции продукта, или люди, которым нужны особые, нечасто используемые функции программы/сервиса.
После этого важно подумать о том:
- Где пользователь будет к нему обращаться: дома, на работе, в машине?
- Как часто он будет его просматривать?
- Насколько объективно сложен для понимания продукт?
Из этого можно сделать вывод, насколько интенсивно пользователь будет работать с документацией, а значит уже можно выбрать между сжатым «справочником» или объемным «путеводителем» Также важно, чтобы руководство писал профессионал, знающий продукт. Так что по возможности делегируйте написание техническому специалисту или аналитику, у которого есть полное представление о всех тонкостях продукта.
Определившись со всеми представленными пунктами, станет понятнее, какой нужно использовать стиль изложения, какого объема написать текст. Но помните, что излишне стилистически окрашенные слова мешают пользователю добраться до сути. Так что лучшим вариантом в большинстве случаев будет нейтрально-формальный стиль. Пишите так, чтобы пользователь вас понял. Постарайтесь по возможности избегать технических терминов, но проанализируйте — не сделает ли полное отсутствие терминов ваше руководство бесполезным?
Структура руководства пользователя
После того как вы ответили на предыдущие вопросы, создайте структуру руководства. У любого хорошего «путеводителя» хорошая и логичная структура. Начните с оглавления. Информативное содержание поможет читателю легко ориентироваться в документе.
В первом разделе желательно рассказать общую информацию о программе:
- Для чего создан продукт.
- Какие задачи он решает.
- Какие основные выгоды от использования для клиента.
В следующем разделе можно указать основные элементы пользовательского интерфейса. Пользователю будет трудно разобраться в софте, если он не поймёт для чего служат различные элементы интерфейса, или он не разберётся в основных режимах работы ПО. Опишите понятным языком предназначение экранов и окон.
Создайте раздел, где расскажете о наиболее эффективных способах применения продукта для решения типовых задач. Какие цели стоят перед клиентом, и как ваша программа/сервис помогает достичь их. Укажите информацию о том, как быстро и продуктивно пользоваться программой.
Ни одно руководство не обойдется без таких разделов как: «Частые вопросы» и «Устранение типовых проблем» В них разбираются вопросы и проблемы, с которыми часто сталкиваются пользователи. Для заполнения данного раздела вам скорее всего понадобятся уже готовые отзывы клиентов. Если у вас абсолютно новый продукт, вы можете предугадать проблемы ваших клиентов либо на первое время не включать данный пункт в ваше руководство.
Иногда технические писатели забывают о важном моменте в руководстве пользователя — контактная информация. Этот раздел поможет пользователям связаться с вами, даже если у них нет никаких вопросов и руководство полностью закрывает все их потребности. Клиент может дать совет, поделиться опытом или предложить выгодное вам сотрудничество.
Инструменты для быстрого создания руководства пользователя
Но как создать руководство пользователя, если пишешь его впервые? Или что делать, если руководство пользователя нужно постоянно обновлять и дорабатывать? Или нужны особые функции, которых нет в традиционных текстовых редакторах, например, в 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 — инструмент для создания мобильной версии пользовательской документации к программным продуктам
- Шаблоны файлов помощи, руководства пользователя программного обеспечения или сайта, шаблон базы знаний — бесплатные шаблоны и примеры пользовательской документации
Как написать руководство пользователя программы или сайта — инструкции, советы, помощь, программное обеспечение
Журавлев Денис
Что такое руководство пользователя и для чего его создавать
Ежедневно создаются новые продукты, программы, сервисы и часто пользователям приходится несладко при освоении какой-нибудь сложной программы, поэтому каждому новому продукту желательно собственное руководство. Для чего?
Большинство людей не хочет разбираться с чем-то незнакомым без персонального, всегда доступного и понятного помощника. А именно им и является хорошее руководство пользователя.
Общие советы по созданию пользовательской документации
Перед тем как приступить к созданию руководства, нужно определиться с некоторыми важными моментами. Например, определить, для кого вы его пишете? Кто его будет читать — рядовые пользователи, для которых важны базовые функции продукта, или люди, которым нужны особые, нечасто используемые функции программы/сервиса.
После этого важно подумать о том:
- Где пользователь будет к нему обращаться: дома, на работе, в машине?
- Как часто он будет его просматривать?
- Насколько объективно сложен для понимания продукт?
Из этого можно сделать вывод, насколько интенсивно пользователь будет работать с документацией, а значит уже можно выбрать между сжатым «справочником» или объемным «путеводителем» Также важно, чтобы руководство писал профессионал, знающий продукт. Так что по возможности делегируйте написание техническому специалисту или аналитику, у которого есть полное представление о всех тонкостях продукта.
Определившись со всеми представленными пунктами, станет понятнее, какой нужно использовать стиль изложения, какого объема написать текст. Но помните, что излишне стилистически окрашенные слова мешают пользователю добраться до сути. Так что лучшим вариантом в большинстве случаев будет нейтрально-формальный стиль. Пишите так, чтобы пользователь вас понял. Постарайтесь по возможности избегать технических терминов, но проанализируйте — не сделает ли полное отсутствие терминов ваше руководство бесполезным?
Структура руководства пользователя
После того как вы ответили на предыдущие вопросы, создайте структуру руководства. У любого хорошего «путеводителя» хорошая и логичная структура. Начните с оглавления. Информативное содержание поможет читателю легко ориентироваться в документе.
В первом разделе желательно рассказать общую информацию о программе:
- Для чего создан продукт.
- Какие задачи он решает.
- Какие основные выгоды от использования для клиента.
В следующем разделе можно указать основные элементы пользовательского интерфейса. Пользователю будет трудно разобраться в софте, если он не поймёт для чего служат различные элементы интерфейса, или он не разберётся в основных режимах работы ПО. Опишите понятным языком предназначение экранов и окон.
Создайте раздел, где расскажете о наиболее эффективных способах применения продукта для решения типовых задач. Какие цели стоят перед клиентом, и как ваша программа/сервис помогает достичь их. Укажите информацию о том, как быстро и продуктивно пользоваться программой.
Ни одно руководство не обойдется без таких разделов как: «Частые вопросы» и «Устранение типовых проблем» В них разбираются вопросы и проблемы, с которыми часто сталкиваются пользователи. Для заполнения данного раздела вам скорее всего понадобятся уже готовые отзывы клиентов. Если у вас абсолютно новый продукт, вы можете предугадать проблемы ваших клиентов либо на первое время не включать данный пункт в ваше руководство.
Иногда технические писатели забывают о важном моменте в руководстве пользователя — контактная информация. Этот раздел поможет пользователям связаться с вами, даже если у них нет никаких вопросов и руководство полностью закрывает все их потребности. Клиент может дать совет, поделиться опытом или предложить выгодное вам сотрудничество.
Инструменты для быстрого создания руководства пользователя
Но как создать руководство пользователя, если пишешь его впервые? Или что делать, если руководство пользователя нужно постоянно обновлять и дорабатывать? Или нужны особые функции, которых нет в традиционных текстовых редакторах, например, в 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 — инструмент для создания мобильной версии пользовательской документации к программным продуктам
- Шаблоны файлов помощи, руководства пользователя программного обеспечения или сайта, шаблон базы знаний — бесплатные шаблоны и примеры пользовательской документации
Ниже представлен пример (образец) документа «Руководство пользователя«, разработанного на основании методических указаний РД 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. настоящего документа.
Писать руководство пользователя по шаблону. Удобно? Удобно
Время на прочтение
4 мин
Количество просмотров 4.7K
Команда, разрабатывающая софт для создания пользовательской документации, делится лайфхаками на тему написания идеальной пользовательской документации для тех, кто далёк от написания руководств к программе.
Для чего мы сами конструируем некоммерческие образцы документации и инструкций для пользователей
Наш проект существует и развивается уже долгое время, практически шестнадцать лет, если быть точнее. За этот срок была сформирована определенная база, где собраны самые актуальные и насущные вопросы, которые возникают перед людьми, создающими справочные элементы к своему проекту.
Ведя диалог с нашими клиентами, мы смогли выделить их потребности и понять основную «боль». Если обобщить, основная проблема заключалась в том, что ни одна программа для создания файл-справок и инструкций не могла выполнить самую нудную, энергозатратную часть проекта — само разрабатывание и оформление этой пользовательской документации
Даже имея осознание того, что файл-справка — неотъемлемый и действительно полезный элемент для пользователя, очень редко возникает мотивация оформить его грамотно и качественно. Еще реже желание возникает, когда в написании пользовательской документации нет опыта или специалистов, которые бы этот опыт имели. Обычно, эта обязанность с легкой руки падает на плечи самих создателей программы, людей, занимающихся тестированием, аналитикой, специалистам поддержки или даже руководителей компании, которые тоже не совсем понимают, как грамотно создать что-то подобное.
Отсюда вытекает еще одна загвоздка. Люди, у которых нет опыта и в принципе понимания, как начать и что туда вносить, просто не знают, как создать качественное руководство для пользователей. В таких случаях большинство следует привычному пути: загуглить определение и найти готовый шаблон.
И с какой-то стороны, это разумно. Мы достаточно часто сталкиваемся с такими запросами, пользователи просят у нас пошаговое руководство или хотя бы костяк готовой инструкции.
Так вышло, что потребности наших клиентов практически на сто процентов входят в нашу экспертную сферу. И мы приняли решение по возможности помочь всем, кто хочет (или вынужден) заниматься созданием файл-справок и инструкций к своему продукту и предоставить возможность получить образцы, которые могут послужить базой и легко быть адаптированными под конкретный запрос.
В связи с этим, мы сами создали готовые образцы и костяки шаблонных проектов в программе. Что входит в нашу базу:
-
Руководство пользователя программного обеспечения.
-
Руководство пользователя web-сервиса.
-
Корпоративная база знаний компании.
В чем удобство создания руководства пользователя по образцу
Вы бережете своё время.
Адаптируя уже созданный образец под свой продукт, вы не тратите время на создание основы с нуля, вам не нужно тратить время, чтобы найти мастер-класс о том, как правильно это сделать. Используя готовый шаблон документации, вы значительно экономите время на создание структуры проекта с нуля и на поиск и изучение информации о том, как это делается.
Вы сосредотачиваете внимание на вашей программе, а не на создании файл-справки
В шаблоне уже есть текстовые и графические вставки, вы можете сами добавлять нужный контент в предложенные места и не продумывать вариант оформления.
Наглядность.
Все образцы и костяки инструкций для пользователя изначально настроенные с динамическими стилями оформления, которые помогут вам быстрее освоиться и разобраться, как можно использовать это для быстрого выполнения своей цели.
Адаптация шаблонов и образцов под ваш проект.
Всё, что находится в шаблонах, можно назвать нашим советом, который был создан на основе многолетнего опыта в данной сфере и выработанной экспертностью. Абсолютно всё в этих шаблонах может быть подвержено адаптации, так как для пользовательской документации нет жестких стандартов, она должна быть выстроена персонально под ваш продукт.
О шаблонах
За 15 лет мы смогли подвергнуть аналитике более сотни разных файл-справок, инструкций и технических документаций, что дало нам возможность сделать вывод и определить шаблонные разделы, которые могут быть применены к огромному количеству программ, после чего мы интегрировали их в наши образцы. Давайте немного подробнее поговорим о структуре.
Обзор возможностей программ. Здесь идет краткое содержание сути вашего продукта. Где вы рассказываете о том, для чего нужна ваша программа. Какие боли и потребности она удовлетворяет, на что способна.
Пользовательский интерфейс. Здесь вы можете наглядно показать вашему клиенту интерфейс, ознакомить его со всеми режимами, дополнительными кнопками и.т.д. Если пользователь может персонализировать интерфейс под себя, об этом тоже лучше указать именно в этом разделе.
Типовые задачи. Здесь нужно максимально подробно познакомить пользователя со всеми основными возможностями программы и детально описать ряд задач и вопросов, которые клиент сможет решить с её помощью. В нашем образце этот блок сформирован из двух подразделов. В подразделе «Примеры использования» лучше всего рассказать пользователю, как ваш продукт будет решать его вопросы и задачи. Если обобщить, то в этом подразделе вы рассказываете про клишированные проблемы, с которыми сталкивается большинство пользователей. В подразделе «Лучшие практики» лучше разместить максимально полезную информацию о том, как упростить свою работу в программе и как пользоваться ей максимально эффективно.
Особые случаи. Здесь нужно рассказать пользователю про то, какие трудности могут возникнуть и как их решить, выделить часто задаваемые вопросы и дать на них самый доступный ответ. Подразделы: «FAQ» и «Устранение типовых проблем»
Вспомогательная и юридическая информация. Здесь вы размещаете информацию о компании, размещаете контактные данные тех.поддержки, информацию о сотрудничестве, сайт, а также лицензионные соглашения.
Названия проекта публиковать не будем, Хабр ругается.
P.S. Мы будем рады, если наши образцы помогут вам закрыть вопрос и успешно реализовать документацию в своем проекте.
Руководство пользователя – это основной документ в составе эксплуатационной документации на автоматизированную систему (ГОСТ 34). Очевидно ли это?
Назначение руководства пользователя
Цель создания документа заключается в том, чтобы предоставить пользователю возможность самостоятельно решать свои прикладные задачи с помощью системы. Этой цели может служить и введение в предметную область, и ознакомление со всеми возможностями программы, и описание конкретных процедур решения задач, и приведение различных инструкций. Иногда Руководство пользователя больше похоже на справочник, к которому можно обращаться в процессе работы, а иногда – на учебник, который позволяет изучить принципы работы с программой и ее возможности, а затем применять их на практике.
Состав типового руководства пользователя
Конкретный подход к написанию определяется многими факторами:
– назначением программы и областью ее применения;
– сложностью программы;
– количеством разнообразных вариантов использования.
Принимая во внимание все различия и особенности, сложно привести структуру любого Руководства пользователя к одному виду. Тем не менее, РД 50-34.698 предлагает нам такой список разделов:
– Введение, где указывают область применения ПО, краткое описывают его возможности, требуемый уровень знаний пользователя и список документов, которые необходимо изучить помимо настоящего руководства;
– Назначение и условия применения, где описывают виды деятельности и функции, которые автоматизированы и условия, при соблюдении которых автоматизация используется;
– Подготовка к работе, где описывают комплектность дистрибутива, порядок установки и загрузки программы, а также способ проверки ее работоспособности;
– Описание операций, представляет собой основной раздел, где описывают функции программы, процессы работы с данными, выполнение конкретных задач пользователя;
– Аварийные ситуации, где описывают действия в нештатных ситуациях – сбоях в программе, ошибок в данных и т.д.;
– Рекомендации по освоению, где приводят методические рекомендации по изучению программы и примеры использования.
Данная структура может меняться и дополняться – например, основной раздел часто разбивают на несколько значимых разделов по группам функций или задач, также в современных системах нередко добавляют раздел Интерфейс пользователя, где описывают взаимодействие пользователя с программой с примерами и снимками экрана.
Стандарты для руководства пользователя
Наличие Руководства пользователя регламентируется ГОСТ 34.201, а структура и содержание – РД 50-34.698. Однако, в зависимости от сложности, назначения и области применения ПО, различные Руководства пользователя могут отличаться друг от друга по способу, методике и стилю изложения.
Стоимость разработки руководства пользователя
Наименование документа |
Наименование стандарта |
Стоимость разработки |
---|---|---|
РП на автоматизированную систему |
РД 50-34.698 |
70 тыс. р. |
Грамотно написанное Руководство пользователя может сэкономить значительное количество времени на обучение и адаптацию пользователя к программе, а также снизить количество ошибок в работе что, в свою очередь, повышает экономическую эффективность системы. Если вы не хотите вникать во все тонкости создания Руководства пользователя, но хотите иметь полный, качественный и полезный документ – обратитесь в компанию ТехРайтКонсалт, и мы применим весь наш опыт и знания для решения вашей задачи по доступной цене!
Возможно, вас также заинтересует:
– разработка руководства администратора;
– создание руководства программиста;
– разработка руководства оператора.
Практическая работа №25-26
Составление инструкции по работе с программным продуктом.
Цель работы:
— Составить
документ «Руководство пользователю» к разработанной ранее
программы.
Порядок выполнения работы и отчетность.
Во время выполнения лабораторной работы необходимо составить
документ «Руководство пользователю» к разработанной ранее программе.
Работа должна быть оформлена в виде документа «Руководство
пользователю».
Теоретические сведения.
Формальные требования к документации программного обеспечения
описаны в ЕСПД (Единая система программной документации), неформально:
состав документации к программному обеспечению состоит из описания его
внешнего эффекта и описания его внутреннего устройства.
Первая часть документации, так называемая «Инструкция
пользователю» или «Руководство пользователю» предназначена для того, кто
собирается использовать программное обеспечение (для пользователя), не вникая в
подробности его внутреннего устройства.
Вторая часть — «Руководство программисту» необходима при
модификации программного обеспечения или при необходимости исправить в нем
ошибку.
В целом, документация к программному обеспечению может содержать
ниже перечисленные сведения:
1. Наименование
ПО и описание задачи, которую оно решает.
2. Область
применимости ПО.
3. Режим работы
ПО, сообщения, выдаваемые по ходу его работы, ответы пользователя на них (если
это необходимо).
4. Исходные
данные, необходимые для работы ПО; а также выдаваемые им результаты;.
5. Правила
подготовки исходных данных на внешних носителях (если они применяются) и вид
выдаваемой информации.
6. Описание
структуры данных. Для любой переменной описывается ее назначение,
атрибуты (тип, размер массива и т.д.), структура информации в ней, если она не
очевидна. Описание переменных должно начинаться с тех, которые служат исходными
данными и результатами.
7. Описания форм,
объектов. Опись свойств форм и объектов.
8. Тексты
программ, процедур (в виде распечатки ЭВМ) с комментариями.
9. Тесты.
10. Инструкция (руководство)
пользователю.
Инструкция по использованию программы (или просто «Инструкция
пользователю», или «Руководство для пользователя») — это выдержка из полной
документации, предназначенная для эксплуатации программы. Она представляет
собой независимый документ для пользователя программы, в котором описывается:
что делает программа и как им пользоваться.
«Инструкция пользователю» должна содержать всю необходимую для пользователя
информацию и должна быть ему понятна без дополнительных материалов (без
обращения к другим спецификациям). Следовательно, необходимая для этой инструкции
информация переписывается полностью из соответствующих спецификаций.
Первая часть инструкции является описательной и должна
содержать:
— наименование программы;
— краткое описание программы;
— перечень выполняемых программой
функций;
— краткую характеристику метода (или
методов) решения поставленной задачи, его достоинство и недостатки;
— полную библиографическую ссылку на
полное описание метода;
— описание входных и выходных данных.
— описание структуры базы данных (если
она имеется), всех ее таблиц в словесной (вербальном) форме.
Вторая часть документа должна описывать порядок работы с
программой. Она должна содержать описание всех режимов работы программы, а
также содержание всех печатей и диагностических сообщений, которые выдаются по
ходу выполнения программы.
Следует помнить, что пользователь по своей квалификации не
является программистом и поэтому его работа с программой описывается на
понятном ему языке и достаточно подробно, а именно:
— как запустить программу;
— как продолжить работу с программой
(описывается подробный интерактивный режим работы пользователя с программой);
— подготовка и ввод исходных данных в
программу;
— как реагировать на запросы программы;
— как вести работу в исключительных
ситуациях;
— как реагировать на ошибки;
— как восстановить работу программы в случае аварийного его
завершения;
— как получить требуемый результат;
— как правильно закончить работу с
программой (запланированный программой выход);
— другие сведения, необходимые
пользователю программы.
Приложение с (информативное) Руководство по процессам и организациям
Это приложение,
для лучшего понимания, представляет
обсуждение процессов, организаций и их
отношений с точек зрения (позиций)
основных субъектов использования
программного обеспечения.
С.1 Процессы с различных ключевых позиций.
Данный Международный
Стандарт содержит процессы, применимые
во время жизненного цикла программного
обеспечения. Однако, эти процессы могут
быть использованы различными организациями
и сторонами с различными представлениями
и целями. В этом пункте процессы и их
отношения рассматриваются с ключевых
позиций. Смотрите 4.1.1 для обзора процессов.
На рисунке С.1
изображены процессы жизненного цикла
программного обеспечения и их отношения
с позиций основных субъектов использования
данного Международного Стандарта.
Основными действиями субъектов являются
: заключение контракта, управление,
применение, инженерные действия и
поддержка. С позиции заключения контракта,
покупатель и поставщик ведут переговоры
и вступают в контакт, применяя при этом
Процесс Покупки и Процесс Поставки
соответственно. С позиции управления,
покупатель, поставщик, разработчик,
оператор, персонал по сопровождению
или другие стороны управляют своим
соответственным процессом. С позиции
применения, оператор обеспечивает для
пользователя возможность оперирования
программным обеспечением. С инженерной
позиции, разработчик или персонал по
сопровождению выполняют свои инженерные
задачи, чтобы, соответственно, создавать
или модифицировать программные продукты.
С позиции поддержки, стороны (такие как
управление конфигурацией, контроль
качества) обеспечивают другим поддержку
в выполнении специфических, уникальных
задач. Также показаны (см. нижнее окно)
организационные процессы; они применяются
организацией на уровне объединения,
чтобы установить и реализовать структуру,
лежащую в основе объединяемого процесса
(процессов) жизненного цикла системы и
персонала и непрерывно улучшать ее.
На рисунке С.2
представлены первичные (верх, левое
окно), поддерживающие (верх, правое окно)
и организационные (нижнее окно) процессы
жизненного цикла и имена составляющих
их процессов с различных позиций. Число,
являющееся префиксом процесса, является
ссылкой на номер секции в данном
Международном стандарте.
Позиция заключения
контракта связана с двумя процессами
жизненного цикла (см.верхнее затененное
окно Первичных Процессов Жизненного
Цикла): Процесс Покупки для покупателя
и Процесс Поставки для поставщика. Для
каждого процесса показаны составляющие
его работы. Эти процессы определяют
задачи для покупателя и поставщика с
точки зрения контракта.
Позиция выполнения
инженерных действий связана с двумя
процессами жизненного цикла (см. левое
нижнее затененное окно в Первичных
Процессах Жизненного Цикла): Процесс
Разработки и Процесс Сопровождения.
Для каждого процесса показаны составляющие
его работы. Процесс Разработки применяется
инженерами-разработчиками для создания
программного продукта. Процесс
сопровождения применяется инженерами
по сопровождению для модификации
программного обеспечения и сохранения
его текущего состояния.
Позиция применения
связана с одним процессом жизненного
цикла (см. нижнее правое затененное окно
в Первичных Процессах Жизненного Цикла):
Процесс использования и составляющие
его работы. Процесс использования
применяется для применения программного
обеспечения, осуществляемого пользователем.
Позиция управления
качеством связана с шестью процессами
жизненного цикла (см. затененное окно
в Процессах Жизненного Цикла, осуществляющих
Поддержку): Процесс Гарантии Качества;
Процесс Верификации; Процесс Проверки
Достоверности; Процесс Объединенных
Наблюдений и Процесс Ревизии. Составляющие
их работы не показаны. Эти, относящиеся
к качеству процессы, применяются для
управления качеством на протяжении
жизненного цикла программного обеспечения.
Процессы Верификации, Проверки
Достоверности, Объединенных Наблюдений
и Ревизии могут применяться разными
сторонами отдельно и также в качестве
технологии выполнения Процесса Гарантии
Качества.
Позиция Управления
имеет один процесс (см. затененное окно
в Организационных Процессах Жизненного
Цикла): Процесс Управления, который
используется любой организацией для
управления соответствующим ей процессом.
Показаны службы, составляющие этот
процесс.
Соседние файлы в папке Гос стандарты
- #
- #
- #
- #
- #
- #
Describe the bug
At the time of writing, when a user wishes to make use of an experimental feature of Bicep, in case the feature has not been enabled in bicepconfig.json
the user is presented with a message that is not informative enough. Consider the following example of a user attempting to use the extensibility providers
feature:
Notice how the message is not informing the user how to enable the extensibility feature and what steps to take to make use of this feature. An alternative message that is informative would include:
- How to enable the feature. That is, save the file and create a
bicepconfig.json
with the relevant flags set and a or a link to the documentation about how to do it - Any disclaimers about the pre-requisites for the feature including how to make use of it in the extension or without the extension
To Reproduce
Steps to reproduce the behavior:
- Create a manifest as described above
Additional context
Related to the discussion in — #9902
Создание документации ИС
Время на прочтение
9 мин
Количество просмотров 44K
Вступление…
Решился продолжить статьи
«История одной инфраструктуры. Решения MS. Часть 1»
«История одной инфраструктуры. Решения MS. Часть 2»
«История одной инфраструктуры. Решения MS. Часть 3»
и более подробно рассмотреть вопрос создания документации информационной системы (ИС) предприятия. Сразу оговорюсь, что не претендую на истину, всего лишь, мой подход и мои соображения по данному вопросу. Надеюсь, что смогу помочь начинающим разработчикам документации в этом нелегком деле.
О чем это я?
А, почему, собственно, Информационная система? А, почему не ИТ-инфраструктура? Предлагаю разобраться в тонкостях понятий и смысла, который я вкладываю в них.
Мы для себя решили, что ИТ-инфраструктурой будем называть базовый «фундамент», позволяющий возводить на нем, информационные системы.
А понятие ИС, будем использовать в самом широком смысле, т.е. не будем разделять имеющиеся системы и «плодить сущности». Посему, в первую очередь, были разработаны определения данных понятий:
Информационная система (ИС) компании являет собой комплекс средств автоматизации процессов обработки, хранения информации и взаимодействия компонентов, включает в себя ИТ-инфраструктуру компании, информацию компании, персональные компьютеры (ПК), прочие ИТ-активы.
ИТ-инфраструктура (Инфраструктура) – совокупность взаимосвязанных примененных технологий, аппаратных и программных средств, систем связи и коммуникаций, составляющих и/или обеспечивающих основу ИС.
А, что же такое «Сервисы»? Это единицы функционального деления, следующий уровень детализации, это обычно то, что получает пользователь ИС.
ИТ-сервисы (Сервисы) — условно разделенные функции Инфраструктуры, также, представляют собой совокупность взаимосвязанных примененных технологий, аппаратных и программных средств, систем связи и коммуникаций.
Ну, как-то так… Все условно, субъективно и путано.
Зачем оно вообще нужно?
Мало построить, удовлетворяющую нуждам предприятия ИС, необходимо сделать ее максимально управляемой. А назвать ИС управляемой, никак нельзя, если нет адекватной документации. Т.е. ИС может управляться создателями, но, что будет, когда им на смену придут другие?
Руководство, которое инвестирует в ИС предприятия, немало переживает по этому поводу. Предприятие зависит от своих процессов, которые, в свою очередь, попадают в серьезную зависимость от ИС. И все критичные процессы управления ИС на небольшом предприятии, зачастую, замыкаются на одной персоне. А, на мой взгляд, большинству не свойственно иметь желание беспрепятственно делиться «рычагами управления» и, связанными с этим знаниями, по причине опасений потерять значимость и вес. Хотя, по моему мнению, опасения эти неоправданны и желание беспрепятственно делиться знаниями дает обратный эффект. Посему, я часто вижу, что персона, управляющая ИС, является «гордым носителем тайных знаний» и «незаменимым кнопконажимателем». Вот она, одна из возможных предпосылок к недоверию между руководством и представителями ИТ. Одни не желают делиться деньгами, другие – знаниями. Порочный круг, который необходимо разорвать, дабы продолжить эффективно работать.
- Подробная документация нужна руководству, дабы хранить ее в сейфе и чувствовать себя комфортно и уверенно (здесь я, конечно, несколько лукавлю – налицо самообман, но все же…).
- Подробная документация повышает значимость представителей ИТ в глазах руководства (руководство замечает серьезный системный подход, но не стоит забывать о том, что это необходимо подобающе презентовать).
Другим немаловажным фактором является то, что документация жизненно необходима самим персонам от ИТ.
- Процесс создания документации позволяет обнаружить и исправить имеющиеся отклонения.
- Процесс создания документации позволяет систематизировать и «обернуть в формы» имеющиеся представления об ИС, позволяет укрепить свои знания.
- Созданная подробная документация призвана помогать в понимании того, «что», «как» и «почему». А т.к., людям свойственно забывать, то, как говорится, «Лучше плохой карандаш, чем хорошая память…».
«Опыт, сын ошибок трудных…»
В самом начале было не оформившееся понимание нужности наличия какой-либо документации. И в процессе внедрений неоднократно предпринимались попытки ее создания. Но не было опыта и знаний того, с какой стороны подойти к решению данного вопроса и не было тех, на кого можно было ровняться. Результаты попыток сложно назвать успешными, лучшее из созданного имело две схемы — «логическая схема инфраструктуры» и «территориальная схема» (созданные в Photoshop), и документ, пытающийся это описать. В общем, «документация» не превышала 20 страниц и не имела права «носить гордого имени». Были еще разрозненные таблицы (списки учетных, записей, ПК и т.д.), но не было системы.
Шло время, внедрялись новые сервисы, исправлялись ошибки, знания систематизировались, понимание задач оформлялось…
И, первым делом, был разработан документ «Правила доступа и использования данных локальной вычислительной сети». Документ, по сути, описывал политики безопасности предприятия в разрезе ИТ и регламентировал отношения пользователей с ОИТ. Руководство одобрило эту инициативу и выпустило приказ, делающий документ неотъемлемой частью «Правил внутреннего трудового распорядка предприятия». Мы, хоть и старались разработать документ, не теряющий актуальности, но, на текущий момент, ему, все же, необходима актуализация.
Приступим?
Понимание оформилось и, было принято решение «собрать волю в кулак и выдать уже, наконец, приемлемый вариант документации в течение месяца». Документация должна быть подробной ровно настолько, сколько необходимо, чтобы с ее помощью можно было построить ИС с нуля и не упустить важные детали.
В качестве ключевого элемента документации был выбран Сервис, т.е. решено разделить имеющиеся технологии, которые предоставлены пользователям, на понятные сервисы и подробно их задокументировать. Принята следующая структура документации:
- Общее описание ИС (обобщенная схема архитектуры ИС, описание, цели, задачи, краткое описание сервисов)
- Списки используемого оборудования и ПО
- Схемы размещения оборудования (стойки, шкафы, сервера, коммутационное оборудование, ИБП, подключение электропитания, оборудованию даны уникальные имена и номера)
- Логическая схема размещения сервисов (размещение и взаимозависимости сервисов, использование служб ОС)
- Описания сервисов (каждый сервис может иметь свой набор документов, отражающих специфику, в большинстве своем, общими являются «Описание сервиса» и «Организация резервного копирования данных сервиса»)
- Приложения к документации (списки «Список учетных записей администраторов серверов и сервисов», «Список учетных записей пользователей, ПК и групп безопасности», «Рекомендации по техническому обслуживанию Сервисов ИС», обобщенные списки «Общий список настроек серверов» и «Общий список заданий резервного копирования»)
Таким образом, используя данную структуру, мы можем «легко и непринужденно» вносить изменения в содержание, добавляя или убирая сервисы (что и было доказано эмпирическим путем впоследствии).
Дальше, «самое трудное» – выбрать оптимальный уровень детализации, разделить функционал и назвать Сервисы, а, как говорится, «Как вы лодку назовете – так она и поплывет».
Начнем, пожалуй, с коммутаций и назовем «Сервис физических коммуникаций». Объединим под этим названием коммутационное оборудование, его конфигурации, линии связи, схемы подключения.
Следующим шагом, объединим Active Directory, DNS, DHCP, Certificate Authority и назовем «Сервис каталогов».
Продукты Forefront для защиты от вредоносного ПО и нежелательных сообщений объединим под названием «Сервис защиты».
И так далее — «Сервис БД» (SQL Server), «Сервис почты» (Exchange), «Сервис автоматизации управления предприятием» (1С), «Сервис файлового хранилища» (файловый сервер), «Сервис документооборота» (SharePoint (разработанный функционал дополняет документацию сервиса)), «Сервис маршрутизации (ISA Server)», «Сервис конференций» (Office Communication Server), «Сервис обновления ПО» (WSUS), «Сервис автоматизации проектных работ» (САПР), «Сервис виртуализации» (Virtual Server), «Сервис Интернет-сайта» (Windows SharePoint Services).
Основной инструмент – Office 2007. Для создания схем использовался Visio, описания и таблицы, естественно, с помощью Word и Excel. Разрабатывая и дополняя общее, документами, описывающими специфику сервиса, получаем вполне законченную структуру документации ИС («Список документации ИС»).
Содержание «Списка документации ИС» (на текущий момент)
1. Общий дизайн информационной системы: 1.0. Общий дизайн информационной системы (схема) 1.1. Общий дизайн информационной системы (пояснение) 2. Список используемого оборудования 3. Список используемого программного обеспечения 4. Детализированная схема размещения оборудования: 4.0. Детализированная схема размещения оборудования (Серверная) (схема) 4.1. Детализированная схема размещения оборудования (Серверная) (пояснение) 4.2. Детализированная схема размещения оборудования (Точки коммутации) (схема) 4.3. Детализированная схема размещения оборудования (Точки коммутации) (пояснение) 5. Сервис физических коммуникаций: 5.0. Территориальная схема физических коммуникаций (схема) 5.1. Территориальная схема физических коммуникаций (пояснение) 5.2. Схема подключения физических коммуникаций (Точка коммутации №0) (схема) 5.3. Схема подключения физических коммуникаций (Точка коммутации №0) (пояснение) 5.4. Схема подключения физических коммуникаций (Точка коммутации №1) (схема) 5.5. Схема подключения физических коммуникаций (Точка коммутации №1) (пояснение) 5.6. Схема подключения физических коммуникаций (Точка коммутации №2) (схема) 5.7. Схема подключения физических коммуникаций (Точка коммутации №2) (пояснение) 5.8. Схема подключения физических коммуникаций (Точка коммутации №3) (схема) 5.9. Схема подключения физических коммуникаций (Точка коммутации №3) (пояснение) 5.10. Схема подключения физических коммуникаций (Точка коммутации №4) (схема) 5.11. Схема подключения физических коммуникаций (Точка коммутации №4) (пояснение) 5.12. Схема подключения физических коммуникаций (Точка коммутации №5) (схема) 5.13. Схема подключения физических коммуникаций (Точка коммутации №5) (пояснение) 5.14. Схема подключения физических коммуникаций (Точка коммутации №6) (схема) 5.15. Схема подключения физических коммуникаций (Точка коммутации №6) (пояснение) 6. Логическая схема сервисов ИС: 6.0. Логическая схема размещения сервисов ИС (схема) 6.1. Логическая схема размещения сервисов ИС (пояснение) 7. Сервис каталогов (Active Directory): 7.0. Описание сервиса каталогов 7.1. Принципиальная схема организационных подразделений (схема) 7.2. Принципиальная схема организационных подразделений (пояснение) 7.3. Группы безопасности 7.4. Групповые политики 7.5. Службы разрешения имен (DNS) 7.6. Службы автоматического назначения адресов (DHCP) 7.7. Службы сертификации (CA) 7.8. Организация резервного копирования данных сервиса каталогов 8. Сервис защиты (Forefront) 8.0. Сервис защиты от вредоносного ПО 8.1. Сервис защиты от нежелательных сообщений 9. Сервис почты (Exchange): 9.0. Описание сервиса почты 9.1. Принципиальная схема сервиса почты (схема) 9.2. Принципиальная схема сервиса почты (пояснение) 9.3. Организация резервного копирования данных сервиса почты 10. Сервис баз данных (SQL): 10.0. Описание сервиса баз данных (SQL) 10.1. Организация резервного копирования данных сервиса БД 11. Сервис автоматизации управления предприятием (1С): 11.0. Описание сервиса автоматизации управления предприятием 11.1. Подробная документация сервиса автоматизации управления предприятием 11.2. Организация резервного копирования данных сервиса автоматизации управления предприятием 12. Сервис файлового хранилища: 12.0. Описание сервиса и структуры организации хранения данных 12.1. Структура организации хранения данных (схема) 12.2. Структура организации хранения данных (пояснение) 12.3. Автоматическое перенаправление данных пользователей 12.4. Организация резервного копирования данных сервиса файлового хранилища 13. Сервис документооборота (SharePoint): 13.0. Описание сервиса документооборота 13.1. Подробная документация системы управления ИТ Система управления ИТ (схема) Система управления ИТ (описание) Система управления ИТ (описание КПЭ) Система управления ИТ (порядок работы с записями) Система управления ИТ (схемы процессов) и т.д. 13.2. Подробная документация системы управления кадровыми ресурсами 13.3. Подробная документация системы управления технологическим оборудованием 13.4. Подробная документация системы управления заказами 13.5. Организация резервного копирования данных сервиса документооборота 14. Сервис маршрутизации (ISA): 14.0. Описание сервиса маршрутизации 14.1. Схема организации подключений Интернет (схема) 14.2. Схема организации подключений Интернет (пояснение) 14.3. Политики доступа к внешним ресурсам 14.4. Политики публикации внутренних ресурсов 14.5. Организация резервного копирования данных сервиса маршрутизации 15. Сервис конференций (OCS): 15.0. Описание сервиса конференций 15.1. Организация резервного копирования данных сервиса конференций 16. Сервис обновления ПО (WSUS) 17. Сервис автоматизации проектных работ: 17.0. Описание сервиса автоматизации проектных работ 17.1. Подробная документация сервиса автоматизации проектных работ 17.2. Организация резервного копирования данных САПР 18. Сервис виртуализации (VS) 19. Сервис Интернет-сайта (WSS): 19.0. Описание сервиса Интернет-сайта 19.1. Организация резервного копирования сервиса Интернет-сайта Приложения: Приложение 1. Список учетных записей администраторов серверов и сервисов (имя входа, роль, членство в группах безопасности, описание). Приложение 2. Список учетных записей пользователей, ПК и групп безопасности (ФИО, имя входа, принадлежность к структурному подразделению, должность, членство в группах безопасности, почтовые адреса, квоты размеров почтовых ящиков). Приложение 3. Общий список настроек серверов (имена, сетевые настройки, запущенные службы, установленное ПО, расположение ключевых данных, конфигурации массивов). Приложение 4. Общий список заданий резервного копирования (имена заданий, расписания, источник и назначение резервного копирования, подробные сценарии). Приложение 5. Рекомендации по техническому обслуживанию Сервисов ИС.
Детализированная схема размещения оборудования (для примера)
Заключение…
Документация готова в установленные сроки и красуется на полке. На текущий момент, документация насчитывает более 100 документов, 30 из которых схемы, в электронном виде и 250 страниц на бумаге. Результат удовлетворил все ожидания – удобно пользоваться, легко изучать, просто вносить изменения и расширять, а самое главное – очень много, приятных глазу, цветных картинок…
Необходимо, также учесть один важный момент – обеспечить процессы своевременной актуализации документации, иначе – напрасный труд. А стало быть – будем работать в этом направлении…
О системе управления ИТ и о том, как у нас получилось обеспечить процессы актуализации