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

Содержание

Введение 3

1. Описание предметной области. Постановка задачи 5

1.1 Постановка задачи 5

1.2 Моделирование бизнес-процессов «Как есть» 8

2. 2. Анализ предметной области и моделирование приложения «Как должно быть» 11

2.1 Требования, реализуемые спроектированной системой 11

2.2 Обоснование выбора СУБД MySQL 12

2.3 Диаграммы UML «Как должно быть» 16

2.4 Структура базы данных 26

2.5 Описание работы информационной системы 27

Заключение 35

Библиографический список 36

Введение

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

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

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

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

Основные задачи, необходимые для решения в ходе проектирования системы, которая будет разработана для автоматизации процесса обработки и анализа данных и документов:

• изучение всех этапов работы с документами

• концептуальное проектирование

• выбор СУБД

• реализация приложения СЭД (Системы электронного документооборота).

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

---

Описание предметной области. Постановка задачи

• 1. Постановка задачи

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

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

До разработки информационной системы на предприятии пользовались программой «Делопроизводство», разработанной в среде Borland C++ Builder с использованием СУБД Paradox. Данная информационная система обладала низкой надежностью из-за нестабильности работы СУБД Paradox и файл-серверной архитектуры и поэтому была подвержена частым сбоям. В связи с использованием файл-серверной архитектуры и прямого доступа к базе данных база часто была открыта в режиме редактирования на клиентах. И при возникновении внештатных ситуаций на сервере при открытом приложении на клиенте часто происходили сбои в базе данных, вследствие чего нарушалась ее целостность и требовалось вмешательство разработчика для ее восстановления.

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

Кроме того, сотрудникам организации, чтобы уточнить данные делопроизводства в отношении них (например, список отписанных на них писем, реестр неисполненных документов, даты и сроки командировки и т.д.) необходимо было подходить или звонить в приемную, где установлена программа. Было бы гораздо удобнее, если сотрудник организации прямо со своего рабочего места мог зайти в программу и просмотреть интересующую его информацию. Но для этого нужно было устанавливать на каждом компьютере необходимое программное обеспечение и настраивать доступ к программе. И это стало еще одной причиной выбора в пользу веб-приложения, т.к. при его внедрении не нужно устанавливать дополнительное ПО, необходимо иметь на клиенте лишь браузер (Microsoft Internet Explorer, Opera и т.д.) и знать url-адрес приложения на сервере.

---

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

На данный момент существует несколько разработок в сфере документооборота с применением веб-технологий. К ним относятся, например «ЕВФРАТ-Документооборот», Система «ДЕЛО», Система оперативного управления компанией «МОТИВ», PayDox, DocsVision «Делопроизводство» и другие. Все они предназначены для построения полноценной системы управления бизнес-процессами и документами организации. Инструментарий, входящий в комплект поставки этих систем позволяет реализовать технологии электронного документооборота в любой компании. Стандартная конфигурация этих систем содержит обязательные настройки.

Для учета различных типов документов предназначены регистрационно-контрольные карточки (РКК) документов, которые включают в себя:

• входящие документы;
• исходящие документы;
• внутренние документы.

Шаблоны журналов, справок и отчетов включают в себя:

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

Таким образом, эти приложения позволяют автоматизировать следующие процессы:

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

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

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

Для конвертации данных из старой базы данных Paradox в новую MySQL была написана специальная программа. При этом конвертация проводилась в виде выполнения SQL-запросов. И если данные в СУБД Paradox занимали почти 24 Мб, то после конвертации в MySQL они занимали лишь 11 Мб. При этом количество записей, содержащихся в базе данных составило:

• В таблице счет-фактур – 56336 записей
• В таблице входящих документов – 21589 записей
• В таблице исходящих документов – 13168 записей
• В таблице почтовых отправлений – 20822 записи
• В таблице командировочных – 4615 записей

---

Общее количество записей на момент конвертации составило 116 530 записей.

• 1. Моделирование бизнес-процессов «Как есть»

Как уже было сказано выше, в организации полноценной системы электронного документооборота не существовало. Следовательно, к средствам моделирования (UML или нотации IDEF) также не прибегали. Поэтому, в рамках моделирования «Как есть» представим диаграмму классов и диаграмму вариантов использования.

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

Рисунок 1.1 – Диаграмма Use Case «как есть»

Она хорошо согласуется с приведенной контекстной диаграммой и показывает работу системы в целом. Диаграмма классов (рисунок 1.2) использует три субъекта системы: Делопроизводитель, Сотрудник и Документ организации (бумажный).

Для них создаются две соответствующие сущности: Работник и Документ. Сущность Должность позволяет разделить работников на делопроизводителей и других сотрудников организации. Использованы связи один-ко-многим и многие-ко-многим.

На рисунке 1.3 приведена автоматически построенная диаграмма таблиц, в которой указаны типы данных и реализованы связь многие-ко-многим как совокупность связей один-ко-многим с дополнительной таблицей Т0 и связь один-ко-многим между таблицами Работник и Должность.

Рисунок 1.2 – Диаграмма классов

Рисунок 1.3 – Диаграмма таблиц

2. Анализ предметной области и моделирование приложения «Как должно быть»

• 1. Требования, реализуемые спроектированной системой

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

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

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

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

---

В соответствии с приведенными выше требованиями к учету документов смоделирована предметная область с объектами и связями между ними.

• 1. Обоснование выбора СУБД MySQL

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

Поэтому в качестве СУБД в данной работе выбрана СУБД MySQL.

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

MySQL имеет ряд преимуществ перед другими СУБД. Например, можно сравнить MySQL с наиболее распространенной СУБД MS Access и проанализировать их преимущества и недостатки. Сравнение приведено в таблице 2.1.

Таблица 2.1 – Сравнение MS Access и MySQL

Характеристика	MS Access	MySQL
Число объектов в базе данных	32768	До 5 млрд.
Максимальный размер таблицы	1 Гбайт	По умолчанию – 4 Гбайт, но размер лимитируется операционной системой
Число таблиц	2048	До 60000
Язык запросов	SQL	SQL
Язык интерфейса	Русский	Английский
Интерфейс	Windows	DOS
Уровень безопасности	Низкий	Высокий
Основное назначение	Создание некоммерческих приложений	Создание коммерческих приложений
Поддержка ODBC	Да	Да

---