Файл: Реферат по дисциплине "Организационное обеспечение ис" Усынина К. А. Группа Б. Ист. Рвс. 20. 76.docx
Добавлен: 09.11.2023
Просмотров: 129
Скачиваний: 9
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Можно выделить следующие основные разделы руководства пользователя:
Назначение системы;
Условия применения системы;
Подготовка системы к работе;
Описание операций;
Аварийные ситуации.
Назначение системы
Данный раздел документа Руководство пользователя должен содержать информацию о назначении системы, ее целях и задачах.
Пример:
«Корпоративный интранет портал предназначен для повышения корпоративной культурыр организации эффективного взаимодействия сотрудников.
Основной целью Порта является создание единого информационного пространства предприятия и оптимизация работы сотрудников путем облегчения коммуникаций между ними и оптимизации ряда бизнес-процессов.»
Условия применения системы
Данный раздел документа Руководство пользователя должен включать все те факторы, которые необходимы для корректной работы системы. Здесь можно выделить несколько подразделов:
Требования к аппаратному обеспечению – сюда можно включить требования к конфигурации компьютера пользователя, программное обеспечение необходимое для работы Системы, а также наличие дополнительного оборудования (принтер, сканер и т.п.), если таковое необходимо;
Квалификация пользователя – данный подраздел должен содержать требования к навыкам и знаниям пользователя (пример: «Пользователи должны обладать умениями работать с операционной системой Windows»);
Подготовка системы к работе
Данный раздел документа Руководство пользователя должен содержать пошаговую инструкцию для запуска приложения. К этапу подготовки системы к работе можно отнести установку дополнительных приложений (при необходимости), идентификацию, аутентификацию и т.п.
Описание операций
Это основной раздел документа Руководство пользователя, который содержит пошаговую инструкцию для выполнения того или иного действия пользователем.
Если работа автоматизированной системы затрагивает целый бизнес-процесс, то в руководстве пользователя перед описанием операций целесообразно предоставить информацию о данном процессе его назначении и участниках. Подобное решение позволяет человеку четко представить свою роль в данном процессе и те функции, которые реализованы для него в системе.
Далее в документе Руководство пользователя следует представить описание функций разбитых на отдельные операции. Необходимо выделить подразделы, описывающие функции данного процесса, и действия, которые необходимо совершить для их выполнения.
Пример:
«4.1 Согласование проекта
Данный процесс предназначен для организации работы сотрудников, участвующих в разработке и согласовании проекта.
Автор проекта создает запись в Системе и прикрепляет пакет необходимой документации, далее проект передается на согласование руководящими лицами. Руководители после ознакомления с проектом могут подтвердить его или отправить на доработку Автору.
4.1.1 Создание проекта
Для того чтобы создать Проект необходимо на панели «…» нажать на кнопку «…» и в появившейся форме заполнить следующие поля:
Наименование проекта;
Описание проекта;
Следующие поля заполняются автоматически:
Дата создания проекта – текущая дата;
Автор – ФИО и должность автора проекта.»
Чем подробнее будут описаны действия с системой, тем меньше вопросов возникнет у пользователя. Для более легкого понимания всех принципов работы с программой стандартами в документе Руководство пользователя допускается использовать схемы, таблицы, иллюстрации с изображением экранных форм.
Для крупных автоматизированных систем рекомендуется создавать отдельное руководство для каждой категории пользователя (пользователь, модератор и т.п.). Если в работе с системой выделяются дополнительные роли пользователей, то в документе Руководство пользователя целесообразно поместить таблицу распределения функций между ролями.
Аварийные ситуации
Данный раздел документа Руководство пользователя должен содержать пошаговые инструкции действий пользователя в случае отказа работы Системы. Если к пользователю не были предъявлены особые требования по администрированию операционной системы и т.п., то можно ограничиться фразой «При отказе или сбое в работе Системы необходимо обратиться к Системному администратору».
Методика и стиль изложения руководства пользователей
Руководство пользователя может представлять собой как краткий справочник по основному функционалу программы, так и полное учебное пособие. Методика изложения материала в данном случае будет зависеть от объема самой программы и требований заказчика.
В зависимости от особенностей программы и целевой аудитории руководство пользователя по способу изложения материала может приближаться к учебнику или, наоборот, к справочнику. Порядок изложения материала в руководстве пользователя определяется пользовательской перспективой программы.
Если программа представляет собой инструмент, позволяющий решать практические задачи из некоторого конечного набора, в руководстве приводят типовые процедуры решения каждой из них. Например, пользователю почтового клиента необходимо знать, как написать и отправить сообщение, как загрузить новые сообщения с сервера, как ответить на сообщение и т. п. Каждое из этих действий можно разложить на последовательные элементарные шаги, во всяком случае, для типичных ситуаций. В крупной программе подобных пользовательских задач может быть много, но не бесконечно много. Руководство пользователя, построенное по принципу пользовательских задач, напоминает учебник, хотя, как правило, лишено присущего учебникам методического аппарата: проверочных заданий, вопросов, упражнений.
Если программа представляет собой среду, в пределах которой пользователь может решать задачи, поставленные им самостоятельно, руководство пользователя должно быть ближе к справочнику. В нем последовательно и систематично должны быть описаны все функции программы и порядок их применения. Что с ними делать, на что направить, пользователь будет думать сам (или запишется на учебные курсы). Так, в руководстве пользователя по графическому редактору мы найдем описание всех графических примитивов, инструментов, фильтров, однако, там не будет напрямую сказано, как изобразить здание, автомобиль или, скажем, собаку. Пользователь это либо умеет рисовать, либо нет.
Возможны и другие пользовательские перспективы. Бывают программы, посредством которых пользователь контролирует состояние того или иного объекта, скажем, промышленной установки. Тогда руководство пользователя строится по принципу таблицы: сообщение программы — реакция или возможные реакции пользователя.
Если пользователь применяет программу для решения задач в нетривиальных предметных областях, в руководство пользователя настоятельно рекомендуется включить концептуальный раздел. В нем должен быть описан реализованный в программе способ представления объектов реального мира, чтобы пользователь хорошо понимал, с какими из них и на каком уровне абстракции он может работать.
34. Проведите сравнительный анализ назначения, структуры, содержания технических заданий, выполненных на основе ГОСТ34.ххх и ГОСТ 19.ххх.
На сегодняшний день классификация ГОСТов ведется по Общероссийскому классификатору, разработанному в ВНИИ классификации, терминологии и информации по стандартизации и качеству и введенному в действие в 2000 году. Общероссийский классификатор согласуется с Международным классификатором стандартов ISO.
В данном классификаторе каждому стандарту присваивается соответствующий цифровой код, который состоит из номера и года утверждения ГОСТа. Номер стандарта имеет префикс, указывающий его на принадлежность к определенной серии документации, и порядковый номер, который определяется последовательностью принятия. Например:
· ГОСТ 2.ххх – Единая Система конструкторской документации (ЕСКД)
· ГОСТ 19. ххх – Единая Система программной документации (ЕСПД)
· ГОСТ 24 ххх. - Единая система стандартов автоматизированных систем управления (позднее ГОСТ 34 – Комплекс стандартов на автоматизированные системы)
Так как ГОСТ носит частично международный характер для стандартов, действующих только на территории России, принято наименование ГОСТ Р.
ГОСТ 34 и ГОСТ 19
Наиболее частой проблемой при разработке технической документации является вопрос выбора правильного стандарта (ГОСТ 19 или ГОСТ 34). Ключ к пониманию разницы между данными стандартами заложен в наименовании их комплекса – Единая система программной документации (ГОСТ 19) и Комплекс стандартов на автоматизированные системы (ГОСТ 34).
Автоматизированная система является результатом целенаправленной деятельности ведущей к автоматизации одного или нескольких производственных процессов на предприятии. Таким образом, автоматизированная система (АС) должна иметь:
· цель (например: оптимизация процесса документооборота на предприятии);
· обслуживающий и эксплуатационный персонал (например: системный администратор, администратор баз данных и т.п.);
· программные средства, обеспечивающие корректную работу АС (например: операционная система);
· комплекс технических средств, на котором развернута АС (например: сервер, рабочее место пользователя).
В то время как АС является комплексной системой, программа представляет собой код, исполняемый машиной (компьютером). Программа может существовать как часть автоматизированной системы, так отдельно.
Таким образом, при разработке технической документации на автоматизированную систему необходимо руководствоваться рекомендациями стандартов входящих в состав ГОСТ 34, в то время как для программы принято использовать ГОСТ 19.
Техническое задание является исходным материалом для создания информационной системы или другого продукта. Поэтому техническое задание (сокращенно ТЗ) в первую очередь должно содержать основные технические требования к продукту и отвечать на вопрос, что данная система должна делать, как работать и при каких условиях. Как правило, этапу составления технического задания предшествует проведение обследования предметной области, которое завершается созданием аналитического отчета. Именно аналитический отчет (или аналитическая записка) ложится в основу документа Техническое задание. Если в отчете требования заказчика могут быть изложены в общем виде и проиллюстрированы UML-диаграммами, в техническом задании следует подробно описать все функциональные и пользовательские требования к системе. Чем подробнее будет составлено техническое задание, тем меньше спорных ситуаций возникнет между заказчиком и разработчиком во время приемочных испытаний. Таким образом, техническое задание является документом, который позволяет как разработчику, так и заказчику представить конечный продукт и впоследствии выполнить проверку на соответствие предъявленным требованиям. Руководствующими стандартами при написании технического задания являются ГОСТ 34.602.89 «Техническое задание на создание автоматизированной системы» и ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». Первый стандарт предназначен для разработчиков автоматизированных систем, второй для программных средств. Ниже представлен список и описание разделов, которые должно содержать техническое задание согласно ГОСТам.