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

Содержание:

Введение

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

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

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

Принято выделять три основные задачи, решаемые в делопроизводстве (ДОУ):

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

В настоящее время документационное обеспечение деятельности российских предприятий осуществляется в основном стихийно, не принимая во внимание существующую нормативную базу и богатый опыт совершенствования ДОУ, накопленный в России за последние 175 лет.

Объектом исследования является ревизионный отдел банка.

Предметом исследования является документооборот ревизионного отдела банка.

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

Задачами работы являются:

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

1. Обзор проектных решений

1.1. Описание предметной области

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

• кредиты;
• депозиты;
• расчетно-кассовое обслуживание;
• дистанционное банковское обслуживание;
• денежные переводы;
• валютные операции;
• зарплатные проекты;
• и прочее.

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

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

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

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

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

Рассмотрим технологию автоматизации работы ревизионного отдела.

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

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

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

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

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

Основные особенности данной архитектуры:

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

Плюсы:

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

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

Клиент и сервер взаимодействую друг с другом в сети Интернет или в любой другой компьютерной сети при помощи различных сетевых протоколов, например, IP протокол, HTTP протокол, FTP и другие. [15, стр. 211]

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

Данная концепция взаимодействия была разработана в первую очередь для того, чтобы разделить нагрузку между участниками процесса обмена информацией, а также для того, чтобы разделить программный код поставщика и заказчика. Ниже вы можете увидеть упрощенную схему взаимодействия клиент-сервер. [3, стр. 81]

Существует два вида архитектуры взаимодействия клиент-сервер: первый получил название двухзвенная архитектура клиент-серверного взаимодействия, второй – многоуровневая архитектура клиент-сервер (иногда его называют трехуровневая архитектура или трехзвенная архитектура, но это частный случай).

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

Суть многоуровневой архитектуры заключается в том, что запрос клиента обрабатывается сразу несколькими серверами. Такой подход позволяет значительно снизить нагрузку на сервер из-за того, что происходит распределение операций, но в то же самое время данный подход не такой надежный, как двухзвенная архитектура. Примером многоуровневой архитектуры может стать СУБД. [10, стр. 180]

Если рассматривать в контексте систем управления базами данных, то первый уровень – это клиент, который позволяет нам писать различные SQL запросы к базе данных. Второй уровень – это движок СУБД, который интерпретирует запросы и реализует взаимодействие между клиентом и файловой системой, а третий уровень – это хранилище данных. [14, стр. 198]

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

Таблица 1

Варианты стратегий автоматизации

Стратегия	Описание
Хаотичная	Предполагает установку частей ИС по мере возможностей. Представляет собой заплатку. Является наиболее плохим вариантом с точки зрения долгосрочного эффекта. Полное отсутствие стратегического плана развития ИС. Потребность во внедрение чаще всего определяется сиюминутными задачами
По участкам	Процесс автоматизации отдельных производственных или управленческих подразделений, объединенных по функциональному признаку. Внедрение характеризуется большой трудоемкостью для эффективной реализации стратегии обязательно наличие стратегических и оперативных планов. Данный подход выбирается: когда инвестиционные ресурсы недостаточны для полной автоматизации предприятия, когда автоматизация участка позволяет достичь существенного эффекта.
Автоматизация по направлениям	Автоматизация отдельных групп, бизнес-процессов (направлений), таких как производство, сбыт, управления финансами. При смене объекта, меняется предметная область. Выбор системы автоматизации зависит от вида услуг и состава затрат. Внедряемая система автоматизации представляет «конструктор» автоматизированных рабочих мест.
Полная автоматизация	Распространение систем автоматизации на все функциональные направления деятельности компании за счет проведения системной интеграции (объединения) ИС при внедрении.

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

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

2. Техническое задание на разработку

1.2.1 Общие сведения

1.2.1.1 Полное наименование системы и ее условное обозначение

Полное наименование: информационная система учёта инцидентов ревизионного отдела банка.

Условное обозначение: ИС учёта инцидентов.

1.2.1.2 Шифр темы или шифр договора

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

1.2.1.3 Плановые сроки начала и окончания работы по созданию системы

Сроки создания системы:

• плановый срок начала работ – 01.09.2020 г.,
• плановый срок окончания работ – 31.10.2020 г.

1.2.1.4 Сведения об источниках и порядке финансирования работ

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

1.2.1.5 Порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы производится согласно требования к документации и ГОСТ

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

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

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

1.2.2 Назначение и цели создания (развития системы)

1.2.2.1 Назначение системы

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

В ИС учёта инцидентов должны храниться и обрабатываться следующие данные:

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

1.2.2.2 Цели создания системы являются

Цели создания ИС учёта инцидентов:

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

1.2.3 Характеристика объектов автоматизации

1.2.3.1 Краткие сведения об объекте автоматизации, или ссылки на документы, содержащие такую информацию

Объектом автоматизации является рабочее место специалиста ревизионного отдела банка.

1.2.3.2 Сведения об условиях эксплуатации объекта.

Условия эксплуатации, а также виды и периодичность обслуживания технических средств ИС учёта инцидентов должны соответствовать требованиям по эксплуатации, техническому обслуживанию, ремонту и хранению, изложенным в документации изготовителя (производителя) на них.

Технические средства системы должны размещаться в помещениях, которые по климатическим условиям должны соответствовать ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды» (температура окружающего воздуха от 5 до 40° C, относительная влажность от 40 до 80% при Т=25° C, атмосферное давление от 630 до 800 мм ртутного столба). Размещение технических средств и организация автоматизированных рабочих мест должны быть выполнены в соответствии с требованиями ГОСТ 21958-76 «Система "Человек-машина". Зал и кабины операторов. Взаимное расположение рабочих мест. Общие эргономические требования».

Для электропитания технических средств должна быть предусмотрена трехфазная четырехпроводная сеть с глухо заземленной нейтралью 380/220 В (+10-15) % частотой 50 Гц (+1-1) Гц. Каждое техническое средство запитывается однофазным напряжением 220В частотой 50 Гц через сетевые розетки с заземляющим контактом.

1.2.4 Требования к системе

1.2.4.1 Требования к системе в целом

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

В системе требуется предусмотреть учёт следующих данных:

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

1.2.4.2 Требования к структуре и функционированию системы

Общими требованиями к Системе являются следующие функции:

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

1.2.4.3 Требования к режимам функционирования системы

Система должна обеспечивать в нормальном режиме:

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

В аварийном режиме система должна позволять:

• отказ изменение данных;
• восстановления связи с базой данных.

1.2.4.4 Требования к численности и квалификации персонала системы и режиму его работы

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

В состав персонала должны входить:

• сотрудник ревизионного отдела;
• системный администратор.

1.2.4.5 Показатели назначения

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

• возможность в полном объеме реализации системой всех функций, описанных в данном техническом задании,
• время доступа к информации – не более 1 минуты,
• время формирования всех отчетных форм в соответствии с требуемыми запросами – не более 3 минут.

1.2.4.6 Требования к надежности системы

Требования к надёжности для ИС учёта инцидентов включает в себя:

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

1.2.4.7 Требования безопасности при разработке и функционирования ИС

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

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.

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

Составляющие процессы:

• учёт инцидентов;
• создание списка участников.

Далее, рассмотрены недостатки данных процессов и выявление варианта решения.

В ходе проведённого анализа выявлен объёмный документооборот процесса учёта инцидентов, выявленных специалистами ревизионного отдела. Также, выявлено, что процесс ведётся средствами пакета MS Office, что сильно осложняет задачу:

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

Была составлена DFD диаграммы процесса документооборота по учёту инцидентов, выявленных сотрудниками ревизионного отдела – рисунок 5.

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

Диаграммы UML

Специалист ревизионного отдела должен:

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

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

Рисунок 6. Диаграмма вариантов использования

Была разработана диаграмма классов. Диаграммы классов отображают классы и взаимодействие между ними.

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

• Main – класс, описывающий главную форму;
• Grid – класс, описывающий форму работы с таблицами;
• Report – класс, описывающий форму отчётов;
• Incindent – класс, описывающий форму добавления и правки данных об инцидентах;
• Actor – класс, описывающий форму создания списка участников инцидента;
• Instruction – класс, описывающий форму учёта предписаний;
• ListIncident – класс, описывающий форму для создания списка инцидентов для основания;
• DataModule – модуль работы с базой данных.

В таблице 2 представлено описание диаграммы классов.

Таблица 2

Описание классов

Класс	Атрибуты	Методы
Main	grdMain; grdSub.	Show(); AddMain(); EditMain(); DelMain(); AddSub(); EditSub(); DelSub(); OpenGrid(); OpenSub(); Close(); Instruction().
Grid	grdMain.	Show(); Add(); Edit(); Delete(); OpenGrid(); Save(); Cancel(); Select(); Close().
Report	vwReport	Show(); Format(); Export(); Close().
Incident	atrIncident	Show(); Save(); Cancel().
Actor	atrActor	Show(); Save(); Cancel().
Instruction	grdMain, grdSub, atrInstruction	Show(); Add(); Edit(); Delete(); Save(); Cancel(); AddSub(); DeleteSub(); Close().
ListInstruction	Instruction	Show(); Save(); Cancel().
DataModule	Connect; Tbls; Query.	Connecting(); Insert(); Update(); Delete(); Select().

На рисунке 7 представлена диаграмма классов для ИС учёта инцидентов и предписаний ревизионного отдела банка.

Рисунок 7. Диаграмма классов

Были рассмотрены сценарии взаимодействия классов. Представлены два сценария – формирование журнала инцидентов и учёт предписаний. Для этого были построены диаграммы последовательности. На рисунке 8 представлена диаграмма последовательности сценария формирования журнала инцидентов.

Рисунок 8. Диаграмма последовательности формирования журнала инцидентов

На рисунке 9 представлена диаграмма последовательности сценария учёта предписаний.

Рисунок 9. Диаграмма последовательности сценария учёта предписания

Логическая модель данных

К входной информации относится:

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

В таблице 3 представлена входная информация.

Таблица 3

Входная информация

Документ	Атрибуты
Анкета сотрудника	фамилия имя отчество; дата рождения сотрудника; пол сотрудника; адрес, по которому зарегистрирован сотрудник; контактный номер телефона; СНИЛС сотрудника; паспортные данные сотрудника.
Место работы	сотрудник; отдел; должность; стаж; работает или нет.
Инцидент	номер; дата; тип; описание.
Участники инцидентов	сотрудник; инцидент; роль.
Предписание	сотрудник; описание; дата выписки; действует или нет.
Список инцидентов для основания	инцидент; предписание.

В таблице 4 представлена нормативно-справочная информация.

Таблица 4

НСИ системы

Справочник	Кто ведёт	Обновления
Отдел	Специалист ревизионного отдела	1 раз в год
Должность	Специалист ревизионного отдела	2 раза в год
Тип инцидента	Специалист ревизионного отдела	2 раза в год
Роль	Специалист ревизионного отдела	2 раза в год

К результатной информации относится:

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

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

Таблица 5

Описание результатной информации

Название	Реквизиты	Условия отбора
Отчёт об инцидентах по сотруднику за период	Номер инцидента; название инцидента; тип инцидента; роль сотрудника.	Идентификатор сотрудника; период дат.
Отчёт об инцидентах за период	Данные об инциденте (номер, дата, название) список участников и их роли	Период дат.

В таблице 6 представлено описание связей между сущностями.

Таблица 6

Описание связей между сущностями

Сущность 1	Сущность 2	Тип	Ограничение
Должность	Работа	Один ко многим	-
Отдел	Работа	Один ко многим	-
Персонал	Работа	Один ко многим	Не null
Тип инцидента	Инцидент	Один ко многим	Не null
Инцидент	Участник	Один ко многим	Не null
Роль	Участник	Один ко многим	Не null
Персонал	Участник	Один ко многим	Не null
Персонал	Предписание	Один ко многим	Не null
Предписание	Список	Один ко многим	Не null
Инцидент	Список	Один ко многим	Не null

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

Рисунок 10. Логическая модель

Заключение

Цель работы – разработка проекта информационной системы документооборота по учёту инцидентов и предписаний ревизионного отдела банка. Цель работы была достигнута.

Был выполнен анализ предметной области, спроектирована модель процессов, спроектирована объектная модель системы. Спроектирована логическая модель базы данных. Спроектирована физическая модель в MS SQL Server 2017. Спроектирован интерфейс для работы с базой данных.

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

Участники процесса специалист ревизионного отдела оперируют очень большим объёмом данных. Это трудоёмкий комплекс задач. При работе используются средства МS Office, что имеет ряд недостатков:

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

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

В системе требуется предусмотреть учёт следующих данных:

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

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

Были выбраны инструменты проектирования:

• ERWin ProcessModeler;
• StarUML;
• ErWin DataModeler.

Спроектирована база данных, которая включает в себя:

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

Определены классы, из которых состоит система: Main; Actor; Instruction; ListIncident; Incident; Grid; Report; DataModule. Построена диаграмма классов. Рассмотрено взаимодействие классов на диаграммах последовательности по сценариям: ведение журнала инцидентов и учёт предписаний.

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

• ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. [Текст] - Введ. 01.03.12. - М.: Стандартинформ, 2012. – 98 с. – (Государственный стандарт Российской Федерации).
• Амбалова, З.А. Сравнение методологий разработки интеллектуальных систем в сфере управления комплексными проектами [Текст]// В сб.: Инновационные механизмы решения проблем научного развития сборник статей по итогам Международной научно-практической конференции. 2017. С. 139-141.
• Белов В.В., Чистякова В.И. Проектирование информационных систем: учебник для студ. учреждений высш. проф. образования – М.: Издательский центр «Академия», 2017. – 352с.
• Бетенекова, Н.В., Николаенко В.С. Обобщение структуры проектной документации [Текст]// В сб.: Государство и бизнес. Современные проблемы экономики: материалы IX Международной научно-практической конференции. Северо-Западный институт управления РАНХиГС при Президенте РФ. 2017. С. 224-228.
• Внуков А.А. Защита информации. Учебное пособие - М.: Юрайт, 2017. - 242 с.
• Грекул В.И. Проектирование информационных систем jnТекст]/ В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина – М.: Интернет-университет информационных технологий, 2018 г. - 321 с.
• Гудсон Д.Н, Стюард Р.Б. Практическое руководство по доступу к данным. – СПб.:БХВ-Петербург, 2015. – 304 с.
• Давыдова Е.М., Новгородова Н. А. Базы данных Учебное пособие для вузов. – Томск: В-Спектр, 2015. – 128 с.
• Добжинская М.А. Обзор существующих систем электронного документооборота // Научное сообщество студентов XXI столетия. Технические науки: сб. ст. по мат. XLIII междунар. студ. науч.-практ. конф. № 6(42). [Электронный ресурс]. – URL: https://sibac.info/archive/technic/6(42).pdf
• Дубейковский В.И. Эффективное моделирование с CA ErwinProcessModeler. – М.: Диалог-МИФИ, 2015. – 384 с.
• Зыков С.В. Основы проектирования корпоративных систем. – М.: Изд. дом Высшей школы экономики, 2015. – 431 с.
• Ильин В.В. Управление эффективностью внедрения информационных систем. - М.: Нобель Пресс, 2015. - 289 с.
• Иришкова К.Д., Найдис О.А. Исследование вариантов разработки и дальнейшей поддержки автоматизированных систем обработки информации // АНИ: экономика и управление. 2018. №1 (22). URL: https://cyberleninka.ru/article/n/issledovanie-variantov-razrabotki-i-dalneyshey-podderzhki-avtomatizirovannyh-sistem-obrabotki-informatsii
• Коваленко В. Проектирование информационных систем. - М.: Форум, 2018. - 320с.
• Пирогов В.Ю. Некоторые особенности преподавания языка управления базами данных // Мир науки. – 2018. Т.6. №6. С.55.
• Трофимов В.Б., Кулаков С.М. Интеллектуальные автоматизированные системы управления технологическими объектами – М.: Инфра-Инженерия, 2016. – 233с.
• Уткин, В. Информационные системы в экономике / В. Уткин, К. Балдин. – Москва: Academia, 2016. – 288с.