Проектирование системы электронного документооборота для гимназии (стр. 3 из 6)
2. РАЗРАБОТКА КОНЦЕПТУАЛЬНОЙ МОДЕЛИ СИСТЕМЫ УПРАВЛЕНИЯ ДОКУМЕНТООБОРОТОМ
Во главе гимназии стоит директор, а в его непосредственном подчинении находится остальной персонал гимназии. Основная часть работы, касающейся ведения документооборота ложится на плечи административно – управленческого персонала и учителей – предметников(подробно структура организации рассматривалась в первом разделе курсового проекта).
Рассмотрим логическую модель управления документооборотом более подробно. Контекстная диаграмма представлена на рисунке 1
Рис.1 "Контекстная диаграмма"
Контекстная диаграмма отражает основные входящие и исходящие документы, используемые в работе гимназии.
Входящие документы:
1. заявление о приеме на работу;
2. трудовую книжку;
3. анкетно-биографические данные учителей и учащихся;
4. заявление о зачислении в первый класс;
5. медицинскую карту ребенка;
6. прочие входные документы.
На основе первых пяти видов входящих документов в гимназии осуществляется прием сотрудников на работу, а также прием новых учащихся. Прочие документы – это вид документов, используемых школой в повседневной работе.
Исходящие документы:
1. журнал успеваемости – в этом документе фиксируется успеваемость и посещаемость учащихся.У каждого класса есть свой журнал успеваемости;
2. табель – документ, где указывается количество рабочих дней персонала, табель составляется ежемесячно завучем и подписывается директором;
3. расписание занятий- составляется завучем ;
4. личные дела сотрудников и учащихся – формируются и изменяются секретарем- делопроизводителем. Он же отвечает за их хранение;
5. приказы и распоряжения директора- также формируются секретарем-делопроизводителем по устному распоряжению директора;
6. трудовую книжку сотрудника – так как трудовая книжка применяется при кадровом учете сотрудников, то за ее оформление, изменение и хранение отвечает также секретарь - делопроизводитель;
7. списки первоклассников – формируются секретарем по распоряжению директора;
8. отчет по форме Д-4 – указываются сведения о составе основных средств, находящихся на балансе образовательного учреждения;
9. отчет по форме ОШ-1 – указываются сведения по количественному составу учащихся в параллелях классов;
10. отчеты по формам РИК-76, РИК-83- в форме РИК-76 указываются сведения об учащихся. В форме РИК-83 указываются сведения по кадровому составу.
Управление:
1. КЗОТ;
2. устав школы;
3. САНПИНЫ;
4. приказы ГУНО;
5. должностные инструкции.
Механизмы:
1. Директор;
2. Учитель;
3. Завуч;
4. Секретарь;
5. Классный руководитель.
Рис.2 "Первый уровень декомпозиции"
Первый уровень декомпозиции представляет собой три блока: обработка входящих документов, обработка внутренних документов и формирование обработанных документов. В процессе обработки входящих документов образуется ряд внутренних, а также исходящих документов, которые подвергаются дальнейшей обработке в следующих блоках. Следует отметить, что декомпозиция системы выполнена в нотациях IDEF0 и DFD. В нотации IDEF0 выполнена первый уровень декомпозиции Остальные уровни декомпозиции выполнены в нотации DFD, которая предназначена для описания информационных потоков предприятия. Блок "Обработка входящих документов" включает в себя следующие работы:
- регистрация входящих документов;
- передача документов на подпись директору и их подписание;
- создание копий документов;
- передача и обработка копий;
- контроль исполнения входящих документов;
- занесение подлинников документов в БД.
Функциональный блок "Обработка внутренних документов" включает в себя следующие виды работ:
- регистрация внутренних документов;
- передача документов на исполнение;
- контроль исполнения внутренних документов.
Функциональный блок "Формирование исходящих документов" включает в себя следующие виды работ:
- регистрация исходящих документов;
- передача документов на подпись и их подписание;
- отправка документов по месту назначения.
Графическая интерпретация второго уровня декомпозиции представлена в приложении 2. Дерево узлов, проектируемой системы, представлено в приложении 3.
3. РАЗРАБОТКА ЛОГИЧЕСКОЙ МОДЕЛИ УПРАВЛЕНИЯ ДОКУМЕНТООБОРОТОМ
На основе функциональной модели была построена логическая модель. В логической модели выделено 10 сущностей:
1) Vnutr_documents –содержит сведения обо всех внутренних документах, используемых организацией;
2) ishod_documents – содержит сведения об исходящих документах гимназии ;
3) vid_documenta – содержит справочную информацию о видах документов, используемых в школе ;
4) vhod_documents - содержит сведения о входящих документах гимназии;
5) potoki_dokumentov – содержит сведения о потоках документов, характеризующих документооборот организации;
6) podpischik - содержит сведения, касающиеся подписчиков документов;
7) dolgnosty – содержит справочную информацию о штатных должностях гимназии;
8) ispolnitely – содержит сведения, касающиеся исполнителей ;
9) podrazdeleniya – содержит сведения о структурных подразделениях организации; 10)sotrudniki – содержит информацию о сотрудниках.
Каждая из сущностей имеет свой набор атрибутов и первичных ключей, которые отражены на ER-диаграмме. Таким образом, идентифицируется хранящаяся информация в конкретной сущности и в конкретном атрибуте, что обеспечивает полную информационную поддержку для выполнения всех функций, заложенных в разрабатываемую систему. Более детально структура БД будет рассмотрена в 4-5 разделах курсового проекта.
4. РАЗРАБОТКА МОДЕЛИ ПРЕДМЕТНОГО ВОПЛОЩЕНИЯ СИСТЕМЫ УПРАВЛЕНИЯ ДОКУМЕНТООБОРОТОМ
4.1 Физическая модель, структура Базы Данных
На основе логической модели данных была разработана физическая модель данных, показанная на рисунке 3.
Рис.3 "Физическая модель данных"
База данных имеет следующую структуру:
Vnutr_documents:
vnutr_reg_number(текст) – внутренний регистрационный номер
Date_registr(дата) – дата регистрации документа
Soderzhanie(текст) – содержание документа
Srok_ispolneniya(дата) – срок исполнения документа
Status_documenta(текст) – статусдокумента
ishod_documents:
ishod_number(текст) – номер исходящего документа
Date_registr(дата) – дата регистрации исходящего документа
Soderzhanie(текст) – содержание документа
Srok_ispolneniya(дата) – срок исполнения документа
Status_documenta(текст) – статусдокумента
vhod_documents:
vhod_number – номер входящего документа
Date_registr(дата) – дата регистрации исходящего документа
Soderzhanie(текст) – содержание документа
Srok_ispolneniya(дата) – срок исполнения документа
Status_documenta(текст) – статусдокумента
vid_documenta:
Code_vida_documenta (текст) – код вида документа
Vid _documenta(текст) – вид документа
Tip_documenta(текст) – тип документа
potoki_dokumentov:
Code_potoka(текст) – код потока документов
Naimenovanie_potoka(текст) - наименование потока документов
Podpischik:
Code_podpischika(текст) – код подписчика
Podpischik(текст) – ФИО подписчика
Code_dolgnosty – код должности
Ispolnitely:
Code_ispolnitelya(текст) – код исполнителя
Ispolnitely(текст) – ФИО исполнителя
Code_dolgnosty – код должности
Podrazdelenie:
Code_podrazdeleniya(текст) – код подразделения
Nazvanie_podradeleniya(текст) – название подразделения
Dolgnosty:
Code_dolgnosty(текст) – код должности
Dolgnosty (текст) – должность
Sotrudniki:
Sotrudnik(текст) – ФИО сотрудника
Login(текст) – системное имя
Password(текст) - пароль
Kabinet(текст) - № кабинета сотрудника
Telephone(текст) - № телефона сотрудника
e-mail(текст) – адрес электронной почты сотрудника
AS(логический) – администрирование системы
AD(логический) – администрирование документооборота
RK(логический) – расширенный контроль
KIZ(логический) – контроль исполнения задания
CR(логический) – создание отчетов
SRF(логический) – создание регистрационных форм.
В логических полях БД фиксируются права пользователей ИСУД.
После создания физической модели данных, была произведена генерация схемы БД в СУБД Microsoft Access. Ниже представлена схема данных.
Рис.4 "Схема данных"
4.2 Архитектурная функциональность
В основе разрабатываемой ИСУД лежит модульная структура ее функциональных элементов, позволяющая разработчику сформировать тот или иной тип архитектуры ИСУД в зависимости от требований заказчика.
Безусловно, основным видом архитектуры для ИСУД является архитектура "клиент-сервер" (рис. 5.).
Рис. 5. Клиент-серверная архитектура СУД
Однако проектируемая система поддерживает архитектуру "файл-сервер" (рис. 6). В дальнейшем будет осуществлен переход к архитектуре "Клиент- Сервер".
Рис. 6. Файл-серверная архитектура СУД
Благодаря модульной структуре программного обеспечения СУД и неизменной структуре БД переход от одной архитектуры к другой будет сделан без снижения производственных и технических показателей.
Сравнительная характеристика "клиент-серверной" и "файл-серверной" архитектур представлена в таблице 1.