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

• Название: Регламента выполнения процесса Управление документооборотом
• Анкор: Разработка регламента
• Дата: 27.04.2023
• Размер: 3.64 Mb.
• Имя файла: Разработка регламента выполнения процесса «Управление документоо.docx
• Тип: Регламент; #1094188

Методы и средства проектирования информационных систем и технологий

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

Содержание

Введение 3

Глава 1. Анализ 5

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

1.2.Анализ аналогов 8

1.3.Описание средств реализации 11

Глава 2. Проектирование 14

2.1.Бизнес процесс 14

2.2.Прецеденты 19

2.3.База данных 39

Заключение 47

Список литературы 48

Введение

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

Работа с технологической (ТД) и конструкторской (КД) документацией является неотъемлемой частью процесса производства двигателей. Основная проблема возникающая в данный момент это отсутствие системы контроля выдачи/возврата документации, позволяющей отслеживать сроки работы с документами. Возврат фиксируется постфактум. Документы возвращают пачками, просто складывая их в окно приёма документов. Создаются очереди на получение документов. Нередки случаи потери части листов документов или целиком. Частая передача документа между работниками без информирования архива. Как итог почти полное отсутствие контроля за документацией.

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

Основные функции, обеспечиваемые системой учета выдачи и возврата документов:

• 
  автоматизация учета, хранения, поступления технической документации в информационной системе (ИС) «Архив»;
  
• 
  автоматизация учета выдачи/возврата технической документации в ИС «Архив»;
  
• 
  автоматическое формирование списка абонентов, имеющих задолженность по возврату документов;
  
• 
  обеспечение доступа, на просмотр, к картотеке архива для специалистов ОЗ;
  
• 
  сокращение бумажных документов (Заявки/расписки);
  
• 
  ведение истории изменений бумажных документов;
  
• 
  организация выдачи/возврата с использованием электронных пропусков.
  

Объектом является процесс выдачи/возврата технической документации на предприятии ПАО «ДКА». Предметом работы является информационная система, предназначенная повысить контроль и качество при работе с бумажной документацией на территории ОЗ.

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

Для достижения указанной цели поставлены следующие задачи:

• 
  Сформулировать требования;
  
• 
  Исследовать платформу, в которую будет интегрирована разработанная система;
  
• 
  Спроектировать ИС;
  
• 
  Разработать ИС;
  
• 
  Интегрировать систему в платформу Базис;
  
• 
  Ввести в опытно-промышленную эксплуатацию ИС.
  

Результатом станет ИС «Архив», позволяющая работникам ОЗ сократить трудозатраты и улучшить исполнительную дисциплину при работе с техническими документами.

Глава 1. Анализ

1. Анализ предметной области

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



Рис. 1. Бизнес процесс выдачи/получения документов AS-IS

Во время согласования ТД в отделение главного технолога (ОГТ) согласующим подразделениям необходимо предоставить КД (бумажный оригинал из архива, который хранится в единственном экземпляре). Для этого они должны самостоятельно спустится в архив, отстоять в очереди и запросить пакет документов. Архивариус начнёт искать документы, в случае их отсутствия сообщит информацию о том, кому выданы эти документы. Затем необходимо будет вручную написать расписку на каждый документ, после чего можно будет их получить. Отсутствующие документы придется собирать самостоятельно, они могут быть переданы третьим лицам (другим абонентам), также в документе могут отсутствовать часть листов или он вовсе может быть утерян.



Рис. 2. Бизнес процесс возврата документа AS-IS

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

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

Минусы текущего бизнес процесса (БП):

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

В ходе анализа были выделены следующие требования к ИС:

• 
  Электронная картотека;
  
• 
  Система поиска документов;
  
• 
  Разграничение доступа в рамках ИС;
  
• 
  Информирование пользователей о событиях в системе;
  
• 
  Низкая цена;
  
• 
  Система должна быть подключена к единой системе идентификации работников на предприятии;
  
• 
  Интегрирована в платформу Базис.
  

1. 
   
   

2. Анализ аналогов

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

Технические требования платформы:

• 
  СУБД Oracle Database 11g;
  
• 
  Сервер приложений Oracle Weblogic 12c;
  
• 
  Брокер сообщений RabbitMQ 3.5.4.
  

Платформа имеет веб интерфейс и для работы с ней необходимо наличие на персональном компьютере (ПК) веб-браузера не ниже Internet Explorer 9.

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

• 
  ТЕЗИС - система электронного документооборота с широкой функциональностью, которая применяется для автоматизации управления бизнес-процессами, документооборота, делопроизводства и контроля исполнительской дисциплины в организациях [7];
  
• 
  DIRECTUM - система электронного документооборота и управления взаимодействием, нацеленная на повышение эффективности работы всех сотрудников организации в разных областях их совместной деятельности [8];
  
• 
  Teamcenter - пакет масштабируемых программных решений для поддержки жизненного цикла изделий, созданный на основе открытой платформы PLM [9];
  
• 
  ДЕЛО – система, разработанная компанией «Электронные Офисные Системы» (ЭОС) – система, ориентированная на автоматизацию документооборота (от создания документа до передачи на архивное хранение) с возможностью сквозной автоматизации документооборота территориально-распределенных компаний, поддерживающая интеграцию с существующими информационными системами предприятия. Система ориентирована на автоматизацию смежных документо-ориентированных процессов (финансовый, договорной документооборот, автоматизация внутренних бизнес процессов, работа с обращениями граждан, оказание госуслуг и т.д.), с возможностью организации юридически значимого документооборота компании [5];
  
• 
  Е1 Евфрат - мощный инструмент автоматизации бизнес-процессов и оптимизации документооборота для компаний всех типов и размеров. Система эффективно решает задачи как в рамках небольшой структуры, например, канцелярии, отдела, департамента или локальной организации в целом, так и в рамках территориально распределенной организации со сложной схемой информационных потоков [6].
  

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

Таблица 1

Требования к аналогам

Требования\ Продукты	Дело	Е1 Евфрат	Тезис	Directum	Teamcenter	ИС Архив
Электронная картотека	+	+	+	+	+	+
Система поиска документов	+	+	+	+	+	+
Разграничение доступа	+	+	+	+	+	+
Информирование пользователей о событиях в системе	+	+	+	+	+	+
Подключение к единой системе идентификации работников	-	-	-	-	-	+
Интеграция в платформу Базис	-	-	-	-	-	+
Цена (за 1 лицензию)	11000 руб	5200 руб	5400 руб	13775 руб	-	-

При анализе аналогов были выделены функции, которые должна обеспечивать ИС:

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

3. Описание средств реализации

Платформа представляет собой веб приложение, серверная часть которого написана на языке java, клиентская на javascript [4], html и css. Для реализации системы был выбран этот же набор технологий. Пользователю не понадобится мощное оборудование для работы с ИС, т.к. она будет иметь веб интерфейс.

Чтобы система не отличалась дизайном от платформы и была проста в сопровождении, были выбраны следующие фреймворки и библиотеки для клиентской части:

• 
  Bootstrap 3 – свободный набор инструментов для создания сайтов и веб-приложений;
  
• 
  JQuery – библиотека javascript, фокусирующаяся на взаимодействии javascript и html;
  
• 
  Jqwidgets – инструмент для создания пользовательского интерфейса, основанного на JQuery, позволяет быстро и легко создавать сложные компоненты пользовательского интерфейса;
  
• 
  JSP (JavaServer Pages) - технология, позволяющая веб-разработчикам создавать содержимое, которое имеет как статические, так и динамические компоненты. Страница JSP содержит текст двух типов: статические исходные данные, которые могут быть оформлены в одном из текстовых форматов HTML, SVG, WML, или XML, и JSP- элементы, которые конструируют динамическое содержимое. Кроме этого могут использоваться библиотеки JSP-тегов, а также EL (Expression Language), для внедрения Java-кода в статичное содержимое JSP-страниц [2-3];
  
• 
  JSTL (JavaServer Pages Standard Tag Library) представляет собой набор тегов в стиле HTML, позволяющих обращаться к объектам Java и выполнять многие из конструкций языка Java;
  
• 
  Stomp.js и Sockjs.js – комплект библиотек, позволяющий реализовать обмен сообщениями между брокером сообщений и клиентами, посредством Simple/Streaming Text-Oriented Messaging Protocol (STOMP). STOMP протокол обмена сообщениями, предполагающий широкое взаимодействие со многими языками, платформами и брокерами. Данный протокол подходит под шаблон "издатель-подписчик" и с помощью специальных сообщений организует связь с брокером по методу "запрос-ответ". Издателем в данной схеме может являться как сервер, так и клиент.
  

Рис. 3. Схема взаимодействия элементов системы [1]

Для серверной части:

• 
  Сервлеты – интерфейс java, реализация которого расширяет функциональные возможности сервера. Сервлет взаимодействует с клиентами посредством принципа запрос-ответ;
  
• 
  json_simple-1.1.jar – библиотека для работы с JSON-объектами;
  
• 
  xdocreport-1.0.4.jar – библиотека, объединяющая XML-документы, созданные с помощью MS Office (docx), OpenOffice (odt) или LibreOffice (odt) с Java моделями, для создания отчетов.
  

RabbitMQ 3.5.4 ‒ брокер сообщений. Его основная цель ‒ принимать и отдавать сообщения. Его можно представлять себе, как почтовое отделение: когда вы бросаете письмо в ящик, вы можете быть уверены, что рано или поздно почтальон доставит его адресату [10].

СУБД Oracle Standard Edition – является одной из самых распространённых на предприятиях СУБД.

Oracle Weblogic 12c - сервер для приложений на платформе Java EE, оптимально подходящий и адаптированный для разработки и использования бизнес-дополнений и сервисов. Это продукт, разработанный одноименной компанией Oracle, легко взаимодействующий с различными СУБД. Сервер приложений Weblogic легок в установке и настройке, а также независим от платформы.

Глава 2. Проектирование

1. Бизнес процесс

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



Рис. 4. Схема бизнес процесса «Выдача документов» в ИС

Для получения документов абоненту необходимо создать электронную заявку в ИС, наполнить её документами и отправить в архив. Если документа нет в наличии работник не сможет добавить его в заявку, система выдаст соответствующее сообщение. Но работник в любой момент сможет самостоятельно посмотреть кому выдан тот или иной документ.



Рис. 5. Схема подпроцесса процесса «Создание и запуск заявки» в ИС

При создании заявки абонент выбирает причину из 3 предложенных: в работу, на изменение или на просмотр. Затем открывает окно поиска и задав все необходимые параметры запускает его. После чего система отобразит все документы, соответствующие введенным параметрам. Абонент выбирает необходимые документы и помещает их в заявку. После наполнения заявки, отправляет её в архив.



Рис. 6. Схема подпроцесса процесса «Подготовка документов» в ИС

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



Рис. 7. Схема подпроцесса «Получение документов» в ИС

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



Рис. 8. Схема подпроцесса «Сдача документа» в ИС

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

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

2. Прецеденты

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

• 
  Техник (оператор);
  
• 
  Архивариус;
  
• 
  Специалист.
  

Основная функция техника — это ведение БД технической документации. В неё входит регистрация новых, поступивших документов и смена их статусов. Архивариус занимается выдачей и возвратом документов. Специалист формирует заявки.



Рис. 9. Функции доступные пользователям

Название прецедента: Оформление заявки

Действующее лицо: Специалист

Предусловия: Пользователь авторизован и в браузере открыта страница ИС Архив

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

Главная последовательность:

• 
  Пользователь нажимает на кнопку «Создать»;
  
• 
  Система открывает окно выбора типа заявки;
  
• 
  Пользователь выбирает причину «В работу»;
  
• 
  Подтверждает действие;
  
• 
  Система создает пустую заявку со статусом «Черновик»;
  
• 
  Пользователь нажимает на кнопку «Поиск документа»;
  
• 
  Система открывает окно поиска;
  
• 
  Пользователь заполняет соответствующие поля в окне;
  
• 
  Подтверждает действие;
  
• 
  Система загружает список документов, согласно установленным параметрам поиска;
  
• 
  Пользователь выбирает нужный ему документ;
  
• 
  Нажимает на кнопку «Добавить»;
  
• 
  Система открывает окно выбора листов;
  
• 
  Пользователь выбирает листы;
  
• 
  Подтверждает действие;
  
• 
  Система добавляет документ к заявке;
  
• 
  Пользователь нажимает на кнопку «Запустить»;
  
• 
  Система меняет статус заявки на «Новая»;
  
• 
  Отправляет сигнал Архивариусам;
  
• 
  Загружает данные по заявке, у Архивариусов.
  

Альтернативная последовательность (Пользователь выбирает причину «На изменение»):

• 
  Система отображает дополнительные поля для ввода (№ извещения об изменении и дату извещения);
  
• 
  Пользователь заполняет поля;
  
• 
  Подтверждает действие.
  

Альтернативная последовательность (Документов, согласно установленным параметрам поиска, не найдено):

• 
  Система отображает пустую таблицу выбора документов.
  

Альтернативная последовательность (Выбранного документа нет в наличии):

• 
  Система открывает сообщение: «Документа нет в наличии в архиве».
  

Альтернативная последовательность (База данных недоступна):

• 
  Система открывает сообщение: «В данный момент работа в системе производится не может, т.к. база данных недоступна»;
  
• 
  Перенаправляет на главную страницу платформы.
  

Альтернативная последовательность (Пользователю необходимо добавить ещё документ):

• 
  Пользователь выбирает нужный ему документ;
  
• 
  Нажимает на кнопку «Добавить»;
  
• 
  Система открывает окно выбора листов;
  
• 
  Пользователь выбирает листы;
  
• 
  Подтверждает действие;
  
• 
  Система добавляет документ к заявке.
  

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

• 
  Система открывает сообщение: «Данный документ уже находится в заявке».
  

Альтернативная последовательность (Пользователь пытается запустить пустую заявку):

• 
  Система открывает сообщение: «Невозможно запустить пустою заявку».
  

Рис. 10. Оформление заявки



Рис. 11. Окно выбора причины для заявки



Рис. 12. Окно поиска документов



Рис. 13. Схема интерфейса специалиста



Рис. 14. Окно выбора листов

Название прецедента: Подготовка документов

Действующее лицо: Архивариус

Предусловия: Пользователь авторизован и в браузере открыта страница ИС Архив

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

Главная последовательность:

• 
  Пользователь выделяет новую заявку;
  
• 
  Система загружает список документов, привязанный к данной заявке;
  
• 
  Пользователь подготавливает документ к выдаче;
  
• 
  Выделяет документ;
  
• 
  Нажимает на кнопку «Готов»;
  
• 
  Система меняет статус документа в заявке на «Готов»;
  
• 
  Меняет статус заявки на «Ожидает выдачи»;
  
• 
  Отправляет сигнал инициатору;
  
• 
  Меняет статус заявки у инициатора.
  

Альтернативная последовательность (База данных недоступна):

• 
  Система открывает сообщение: «В данный момент работа в системе производится не может, т.к. база данных недоступна»;
  
• 
  Перенаправляет на главную страницу платформы.
  

Альтернативная последовательность (Документов в заявке больше одного):

• 
  Пользователь подготавливает следующий документ к выдаче;
  
• 
  Выделяет документ
  
• 
  Нажимает на кнопку «Готов».
  

Альтернативная последовательность (Части документов нет в наличии, а которые есть уже подготовлены):

• 
  Пользователь нажимает на кнопку «Ожидает выдачи».
  

Рис. 15. Подготовка документа



Рис. 16. Схема интерфейса архивариуса

Название прецедента: Выдача документов

Действующее лицо: Архивариус, Специалист

Предусловия: Архивариус авторизован и в браузере открыта страница ИС Архив, Специалист спустился в архив для получения документов, Архивариус подготовил документы для выдачи

Краткое описание: Архивариус отмечает выдачу документов, а специалист подтверждает выдачу своим пропуском

Главная последовательность:

• 
  Архивариус выбирает заявку пользователя в таблице;
  
• 
  Система загружает список документов из выбранной заявки;
  
• 
  Архивариус выбирает документ;
  
• 
  Нажимает на кнопку «Выдать»;
  
• 
  Система открывает диалоговое окно с сообщением «Выдать все документы?»;
  
• 
  Архивариус нажимает на кнопку «Нет»;
  
• 
  Система открывает окно выбора листов;
  
• 
  Архивариус выбирает все листы;
  
• 
  Подтверждает выбор нажав на кнопку «Далее»;
  
• 
  Система открывает окно проверки пропуска;
  
• 
  Специалист прикладывает пропуск к датчику;
  
• 
  Система считывает данные пропуска;
  
• 
  Отображает имя специалиста в окне проверки пропуска;
  
• 
  Архивариус нажимает на кнопку «Выдать»;
  
• 
  Система меняет статус документа в заявке на «Выдан»;
  
• 
  Устанавливает фамилию специалиста, которому выдали документ;
  
• 
  Устанавливает дату выдачи;
  
• 
  Устанавливает срок;
  
• 
  Уменьшает количество наличия экземпляров документа в архиве на 1;
  
• 
  Система меняет статус заявки на «Выдано»;
  
• 
  Архивариус выдаёт бумажный документ в руки специалисту.
  

Альтернативная последовательность (База данных недоступна):

• 
  Система открывает сообщение: «В данный момент работа в системе производится не может, т.к. база данных недоступна»;
  
• 
  Перенаправляет на главную страницу платформы.
  

Альтернативная последовательность (Архивариус выбирает часть листов):

• 
  Архивариус выбирает часть листов для выдачи;
  
• 
  Подтверждает выбор нажав на кнопку «Далее».
  

Альтернативная последовательность (Архивариус выдаёт весь подготовленный пакет документов по заявке):

• 
  Архивариус нажимает на кнопку «Да»;
  
• 
  Система открывает окно проверки пропуска;
  
• 
  Специалист прикладывает пропуск к датчику;
  
• 
  Система считывает данные пропуска;
  
• 
  Отображает имя специалиста в окне проверки пропуска;
  
• 
  Архивариус нажимает на кнопку «Выдать»;
  
• 
  Система меняет статус документов в заявке на «Выдан»;
  
• 
  Устанавливает фамилию специалиста, которому выдали документы;
  
• 
  Устанавливает дату выдачи;
  
• 
  Устанавливает срок;
  
• 
  Уменьшает количество наличия экземпляров документа в архиве на 1;
  
• 
  Система меняет статус заявки на «Выдано»;
  
• 
  Архивариус выдаёт пакет документов в руки специалисту.
  

Альтернативная последовательность (В заявке больше 1 подготовленного документа):

• 
  Архивариус выбирает следующий;
  
• 
  Нажимает на кнопку «Выдать».
  

Альтернативная последовательность (Специалист не взял с собой пропуск):

• 
  Архивариус нажимает на кнопку «Отмена».
  

Рис. 17. Выдача документов

Название прецедента: Возврат документов

Действующее лицо: Архивариус, Специалист

Предусловия: Архивариус авторизован и в браузере открыта страница ИС Архив, специалист спустился в архив для возврата документов, Специалист взял с собой документы для возврата

Краткое описание: Специалист сдаёт документы в архив, Архивариус проверяет наличие всех листов и ставит отметку о возврате в заявке

Главная последовательность:

• 
  Архивариус выбирает заявку пользователя в таблице;
  
• 
  Система загружает список документов из выбранной заявки;
  
• 
  Специалист передаёт документ архивариусу;
  
• 
  Архивариус проверяет листы в возвращаемом документе;
  
• 
  Выбирает возвращаемый документ;
  
• 
  Нажимает на кнопку «Вернуть»;
  
• 
  Система открывает окно выбора листов;
  
• 
  Архивариус выбирает все листы;
  
• 
  Нажимает на кнопку «Далее»;
  
• 
  Система открывает окно проверки пропуска;
  
• 
  Специалист прикладывает пропуск к датчику;
  
• 
  Система считывает данные пропуска;
  
• 
  Отображает имя специалиста в окне проверки пропуска;
  
• 
  Специалист нажимает на кнопку «Вернуть»;
  
• 
  Система устанавливает фамилию, кто возвратил документ;
  
• 
  Устанавливает дату возврата;
  
• 
  Увеличивает количество наличия экземпляров документа в архиве на 1;
  
• 
  Меняет статус документа на «Возвращён»
  
• 
  Меняет статус заявки на «Возвращено».
  

Альтернативная последовательность (Специалист не взял с собой пропуск):

• 
  Архивариус нажимает на кнопку «Отмена»;
  
• 
  Возвращает документ Специалисту.
  

Альтернативная последовательность (База данных недоступна):

• 
  Система открывает сообщение: «В данный момент работа в системе производится не может, т.к. база данных недоступна»;
  
• 
  Перенаправляет на главную страницу платформы.
  

Альтернативная последовательность (Архивариус выбирает часть листов):

• 
  Архивариус выбирает часть листов для выдачи;
  
• 
  Подтверждает выбор нажав на кнопку «Далее»;
  
• 
  Система открывает окно проверки пропуска;
  
• 
  Специалист прикладывает пропуск к датчику;
  
• 
  Система считывает данные пропуска;
  
• 
  Отображает имя специалиста в окне проверки пропуска;
  
• 
  Специалист нажимает на кнопку «Вернуть»;
  
• 
  Устанавливает фамилию, кто возвратил документ;
  
• 
  Устанавливает дату возврата;
  
• 
  Отмечает листы, которые вернул специалист.
  

Альтернативная последовательность (Специалист сдает больше 1 документа):

• 
  Архивариус выбирает другой документ в заявке;
  
• 
  Нажимает на кнопку «Вернуть».
  

Альтернативная последовательность (У специалиста больше 1 заявки):

• 
  Архивариус нажимает на кнопку «Поиск»;
  
• 
  Система открывает диалоговое окно поиска активной заявки по обозначению документа;
  
• 
  Архивариус вводит обозначение документа;
  
• 
  Нажимает на кнопку «Подтвердить»;
  
• 
  Система отфильтровывает заявки, в которых выдан документ с введённым обозначением;
  
• 
  Выделяет первую в списке заявку;
  
• 
  Загружает список документов по заявке.
  
• 
  
  

Рис. 18. Возврат документов



Рис. 19. Окно поиска заявки по документу

Название прецедента: Регистрация технической документации

Действующее лицо: Оператор

Предусловия: Оператор авторизован и в браузере открыта страница ИС Архив

Краткое описание: Оператор открывает окно регистрации документа, заполняет его данными и подтверждает сохранение данных

Главная последовательность:

• 
  Оператор нажимает на кнопку «+»;
  
• 
  Система открывает окно регистрации документа;
  
• 
  Оператор вносит все необходимые данные;
  
• 
  Нажимает на кнопку «Подтвердить»;
  
• 
  Система проверяет наличие подобного документа в базе данных;
  
• 
  Заносит данные в базу данных;
  
• 
  Открывает сообщение: «Документ зарегистрирован».
  

Альтернативная последовательность (База данных недоступна):

• 
  Система открывает сообщение: «В данный момент работа в системе производится не может, т.к. база данных недоступна»;
  
• 
  Перенаправляет на главную страницу платформы.
  

Альтернативная последовательность (Документ уже есть в базе данных):

• 
  Система открывает сообщение: «Данный документ уже зарегистрирован».
  

Рис. 20. Регистрация технической документации



Рис. 21. Схема интерфейса техника



Рис. 22. Окно регистрации документа

3. База данных

Информационная система разрабатывается с использованием табличного пространства платформы «Базис» (таблицы с приставкой AP_). Включает в себя таблицу с пользователями, группами, ролями, правами доступа, задачами и т.д. Второе табличное пространство принадлежит разрабатываемой ИС Архив (таблицы с приставкой Z_ARCH_). Результирующее табличное пространство было получено путем нормализации таблицы изображенной на рисунке 23. База данных должна содержать информацию о различных технических документах, кто зарегистрировал и изменил запись в БД, кому выдан тот или иной экземпляр (при наличии нескольких экземпляров).



Рис. 23. Первоначальная таблица с данными о документах архива

На первом шаге произведено удаление повторяющихся групп.



Рис. 24. Таблица с данными о документах архива в 1 нормальной форме (НФ)

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



Рис. 25. Таблица с данными о документах архива в 2 НФ



Рис. 26. Таблица с данными о истории изменения записей в таблице с документами в 2 НФ



Рис. 27. Таблица с заявками на получение документов в 2 НФ



Рис. 28. Таблица с документами из заявок в 2 НФ

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



Рис. 29. Таблица с списками в 3 НФ

В ходе нормализации было получено 5 таблиц и 2 таблицы из табличного пространства платформы Базис:

• 
  Таблица AP_USERS – содержит информацию о пользователях платформы;
  
• 
  Таблица AP_GROUP – содержит информацию об организационном дереве (подразделениях);
  
• 
  Таблица Z_ARCH_DOC - главная таблица системы, содержит информацию о документах;
  
• 
  Таблица Z_ARCH_HISTORY - содержит информацию о истории изменений документов в БД;
  
• 
  Таблица Z_ARCH_REQ - содержит информацию о заявках пользователей на получение документов;
  
• 
  Таблица Z_ARCH_REQ_DOC - содержит информацию о документах, входящих в состав заявки;
  
• 
  Таблица Z_ARCH_LISTS - справочник возможных статусов документов, причин для получения документов, статусов заявок, видов документов, процессов, признаков, признаков применяемости.
  

Итоговый вариант схемы базы данных изображен на рисунке 30.



Рис. 30. Схема базы данных системы в 3 НФ

Заключение

Разработанная ИС получила название «Архив» и была интегрирована в платформу Базис, благодаря использованию api и табличного пространства платформы.

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

Список литературы

1. 
   ГОСТ 19.701-90 (ИСО 5807-85) ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения - Москва: Стандартинформ, 2010 – 23 с.
   
2. 
   Гери Д. JavaServer Faces. Библиотека профессионала, 3-е издание/ Хорстманн К. – Санкт-Петербург: Вильямс, 2011 – 544 с.
   
3. 
   Гупта А. Java EE 7. Основы - Санкт-Петербург: Вильямс, 2014 – 336 с.
   
4. 
   Закас Н. JavaScript для профессиональных веб-разработчиков. – Санкт-Петербург: Питер, 2015. – 960 с.
   
5. 
   Дело [Электронный ресурс] URL: https://www.eos.ru/eos_products/eos_delo/
   
6. 
   СЭД "Е1 Евфрат". Схема оптимизации документооборота [Электронный ресурс] URL: http://www.evfrat.ru/about/
   
7. 
   Система электронного документооборота — СЭД ТЕЗИС [Электронный ресурс] URL: https://www.tezis-doc.ru/ (Дата обращения: 04.10.2018).
   
8. 
   Аналитика. Автоматизация делопроизводства и документооборота уверенно занимает свою нишу в области систем автоматизации предприятия. DIRECTUM [Электронный ресурс] URL: https://www.directum.ru/339091.aspx
   
9. 
   Teamcenter [Электронный ресурс] URL: https://www.plm.automation.siemens.com/global/ru/products/teamcenter/ (Дата обращения: 01.10.2018).
   
10. 
    RabbitMQ - Messaging that just works [Электронный ресурс] URL: https://www.rabbitmq.com/