Файл: Разработка регламента выполнения процесса «Управление документооборотом» (Описание предметной области).pdf

1.2.4.7 Требования к эргономике и технической эстетики

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

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

1.2.4.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

Специальных требований нет.

1.2.5 Требования к функциям (задачам), выполняемым системой

1.2.5.1 Перечень подлежащих автоматизации функций

В системе потребуются следующие модули:

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

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

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

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

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

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

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

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

1.2.5.2 Требования к функциям

К функциям программного комплекса должны предъявляться следующие требования:

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

1.2.6 Требования к видам обеспечения

1.2.6.1 Требования к информационному обеспечению

Данные о персонале предприятия:

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

Данные о работе персонала подразумевает учёт должностей, отделов, и пометок работает сотрудник или уволен.

Информация о инциденте нарушения техники безопасности:

• номер происшествия;
• дата и время происшествия;
• тип происшествия;
• описание нарушения;
• пометка о травме, была или нет.

Данные об участниках инцидента:

• идентификатор сотрудника предприятия;
• роль участника в инциденте.

Данные о предписании:

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

Список, на которых основывается предписание содержит идентификатор предписания и идентификатор инцидента.

1.2.6.2 Лингвистические требования к системам классификации и кодирования информации

Должна использоваться внутренняя система классификации и кодирования информации в ИС.

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

Системное программное обеспечение:

• MS Office 2016 и выше;
• клиентская часть – ОС MS Windows 10;
• серверная часть – MS Windows Server 2016 и выше;
• реляционная СУБД;

1.2.7 Требования к методическому обеспечению системы

Состав документов по ИС учёта инцидентов, передаваемых заказчику формируется из документов на комплекс в целом и включает в себя следующие документы:

• техническое задание,
• описание структуры данных,

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

Обоснование выбора среды моделирования

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

Существует много методологий моделирования бизнес-процессов, например, следующие:

• Flow Chart Diagram (диаграмма потока работ);
• Data Flow Diagram;
• Role Activity Diagram (диаграмма ролей);
• IDEF (Integrated Definition for Function Modeling;
• ARIS (Architecture of Integrated information Systems).

Одним из самых распространённых стандартов является IDEF. IDEF – это целый набор аналитических средств, применяемых не только в управлении бизнесом, но и во многих других сферах. Чаще всего встречаются варианты IDEF0 и IDEF3. Первый из этих вариантов представляет собой модель функций, причем сложные функции делятся на более простые составляющие, а затем различные блоки логически объединяются посредством стрелок. При использовании IDEF3 речь идет о «поведенческом» описании: демонстрируется поток работ либо переходные состояния объектов.

Для проектирование концептуальной модели работы склада будет использоваться методология IDEF.

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

Хорошее Case tool для этапа анализа должно иметь в своём составе: редактор для создания моделей бизнес-процессов; редактор данных модели; хранилище для метаданных; генератор проектной документации.

Поскольку этап анализа почти всегда требует рассмотрения анализа бизнес-процесса, необходимо выбрать аналитический инструмент, который может построить БП по одной общей методологии. Поэтому одной из наиболее распространенных методик моделирования для последующего анализа бизнес-процессов является IDEF. Одним из хороших Case tool является ErWin process modeler. Этот инструмент позволяет создавать модели в нотации IDEF0, IDEF3 и DFD. Этот инструмент используется для анализа набора задач, выбранных в этой работе.

Для этапов проектирования информационной системы также необходимо использовать инструмент case. Это позволяет улучшить качество продукта и уменьшите стоимость труда. Case tools для этапа проектирования содержит: графический редактор для создания моделей; поддержку создания кода из схемы; хранилище метаданных; параметров конфигурации; проверка схем.

Для работы с объектной моделью системы часто применяют методологию UML.

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

Для проектирования базы данных рекомендуется выбрать методику IDEF1X. Это наиболее распространенная нотация проектирования баз данных. Удобным инструментом для проектирования баз данных является CA ErWin Data Modeler. В данном случае в качестве инструмента уже в первой главе используется CA ErWin process Modeler, которые связаны и просты в использовании.

Моделирование предметной области

IDEF – моделирование

Документооборот по учёту инцидентов и предписаний в ревизионном отделе – это трудоёмкая задача. Рассмотрим процесс документооборота по учёту инцидентов, выявленных ревизионным отделом – диаграмма верхнего уровня представлена на рисунке 1.

Рисунок 1. Контекстная диаграмма процесса документооборота по учёту инцидентов, выявленных ревизионным отделом

Входные потоки:

• данные о персонале;
• данные об инцидентах.

Выходные потоки:

• журнал о проверках;
• предписания;
• отчёт об инцидентах за период;
• отчёт об инцидентах по сотруднику за период.

Управляющие поток: регламент; указы.

Исполнитель и ресурсы: сотрудник ревизионного отдела.

На рисунке 2 представлена декомпозиция данного процесса.

Рисунок 2. Структурно-функциональная диаграмма процесса документооборота по учёту инцидентов, выявленных ревизионным отделом

Выявлены следующие процессы:

• учёт сотрудников;
• формирование журнала инцидентов;
• формирование предписаний;
• формирование отчётов.

На рисунке 3 представлена декомпозиция процесса учёта сотрудников.

Рисунок 3. Структурно-функциональная диаграмма процесса учёта сотрудников

Представлены следующие процессы:

• получение данных о сотруднике;
• регистрация анкеты сотрудника.

Более подробно рассмотрен процесс формирования журнала инцидентов – рисунок 4.