Модуль документооборота локальной вычислительной сети производственного предприятия

Содержание
стр.
Введение
1 Исследовательский раздел
1.1 Анализ деятельности предприятия и существующей локальной сети
1.2 Анализ существующих автоматизированных систем
1.2 Обоснование выбора аппаратно-программных средств
1.3 Техническое задание на проектирование
2 Специальный раздел
2.1 Разработка структурной схемы модуля
2.2 Разработка схемы информационных потоков
2.3 Разработка входных и выходных форм документов
2.4 Разработка интерфейса пользователя
3 Технологический раздел
3.1 Технология проектирования модуля
3.2 Технология разработки интерфейса
4 Безопасность жизнедеятельности
4.1 Анализ параметров микроклимата, действующих на пользователя при работе на ПЭВМ
4.2 Оснащение помещения системой кондиционирования
4.3 Экологическая оценка материалов, используемых при изготовлении ПЭВМ
4.4 Экологический баланс компьютерной техники
5 Экономический раздел
5.1 Планирование разработки программного модуля с построением графика выполнения работ
5.2. Расчет затрат на разработку
5.3 Оценка экономической эффективности проекта
6 Перечень графического
6.1 Схема ЛВС организации
6.2 Структурная схема модуля
6.3 Схема информационных потоков
6.4 Структура входных и выходных данных
6.5 Интерфейс пользователя
6.6 Экономические показатели
Заключение
Список использованных источников
ПриложениеА :.Исходный код программы
Приложение Б:. Графический материал Графический материал

Модуль документооборота локальной вычислительной сети производственного предприятия

В области организации доступа к информации:
обеспечение централизованного хранения текстов документов, подготовленных в электронной форме, а также всех поступающих документов с возможностью организации логического связывания документов, относящихся к одному вопросу;
обеспечение оперативного поиска документов
2 Специальный раздел
2.1 Разработка структурной схемы модуля
Первым шагом в процессе разработки программного обеспечения от спецификации потребностей, могут сосредоточиться на определении архитектуры программного обеспечения.
Этап разработки структурной схемы программного модуля в целом позволяет рассматривать несколько вариантов решения проблемы и изучит возможностей их реализации.
Мы выбираем решение, которое наилучшим образом удовлетворяет потребности, сохраняется нужные функциональности.
Мы можем сделать прототипов различных подходов рассматриваются в общий дизайн для их проверки.
Структура программного обеспечения можно рассматривать с двух различных точек зрения:
- статической точки зрения,
- динамической точки зрения.
В современных условиях, объем организационно-распорядительной документации, который необходимо обрабатывать, растёт огромными темпами и наиболее удобным способом анализа информации является документирование деятельности. Это позволяет оценить динамику и относительные изменения интересующих нас величин. При этом мы вполне можем организовать работу с документами, включая их создание, регистрацию, продвижение, контроль, , хранение и систематизацию. Возможность оценивать динамику огромных объёмов документов позволяет оперативно принимать решения или делать соответствующие выводы.
Также важной возможностью является представление одной и той же информации в различном виде:
Сопроводительное письмо
Письмо-просьба
Письмо-запрос
Письмо-ответ
Письмо-сообщение
Письмо-подтверждение
Информационное письмо
Гарантийное письмо
Письмо-извещение
Письмо-приглашение
Письмо-предложение
Письмо-напоминание
Письмо-требование
Письмо-благодарность
Письмо-поздравление
Телеграмма
Телекс
Поэтому первое требование к системе — возможность обрабатывать входящие документы и должна включать регистрацию в журнале.
Необходимо иметь возможность по расширению возможностей системы следит за движение документов в организации с момента их создания или получения до завершения исполнения.
В современном мире часто возникает необходимость оценивать информацию, полученную различными людьми, например, группами исследователей или бизнес-аналитиков, работающих над одним и тем же проектом в разных городах или странах.
При этом может потребоваться как предоставить результат обработки одной и той же информации (документ поступает из одного источника и, после обработки, предоставляется в одинаковом или разном виде) всем заинтересованным лицам, так и предоставить возможность просмотра обработанных данных разных групп исследователей на одной странице (информация из разных источников отображается в виде нескольких документов, для удобного сравнения результатов работы, при этом каждая группа может использовать свой формат хранения данных).
Отсюда вытекает следующее требование к системе – работа в распределённой среде, с возможностью доступа к информации всех заинтересованных лиц, независимо от местоположения.
В процессе исследований (биохимических, экономических или любых других) часто приходится работать с новым оборудованием, выдающим данные в собственном формате, использовать новое или, наоборот, старое, программное обеспечение, хранящее информацию в собственном формате.
Документы могут быть уже получены в определённом, малораспространённом формате. Возможна также ситуация с созданием исследователями нового стандарта, позволяющего более полно отражать необходимые им особенности обрабатываемой информации, обеспечивать надёжность, компактность, обратную совместимость или защищённость хранимых данных.
При этом часто необходимо оперативно обрабатывать такие документы, а временные и/или финансовые затраты на преобразование уже имеющихся данных в более универсальный формат недопустимо велики, что затрудняет использование уже существующих на рынке программных средств.
Следовательно, система должна обеспечивать лёгкую расширяемость.
Мы должны иметь возможность добавления новых блоков, позволяющих нам получать и обрабатывать документы, хранящуюся в любом формате (мы должны, конечно, позаботиться обо всех нюансах обработки в случае использования малораспространённых источников данных, но для работы со стандартными источниками можем использовать известные и проверенные встроенные компоненты, модифицируя их нужным нам образом).
Информация, получаемая в результате работы многих людей, очень быстро увеличивается в объёмах, а также изменяется. Система не должна требовать каких-либо вмешательств для поддержания работы после первоначального указания источника данных.
Система должна представлять информацию по запросу пользователя в реальном времени.
Поскольку документ может иметь определённую ценность, мы должны обеспечить разграничение доступа к ней.
Также необходимо ограничить права пользователей системы на создание новых компонентов и модификацию или удаление уже существующих, а также на изменение запросов к источникам информации.
Пользователь, принадлежащий к роли администраторов, должен иметь возможность в любой момент удалить пользователя из системы, лишить его прав на модификацию или создание объектов системы. Ограничить возможности пользователя по подключению к источникам данных и просмотру информации из них. Остальные пользователи не должны получать доступ к механизмам администрирования системы.
Таким образом, важным требованием к системе является возможность ограничения доступа пользователей к информации и изменению компонентов системы в зависимости от принадлежности пользователя к определённой группе или роли. Предоставление механизмов администрирования (сохранения информации о принадлежности пользователя определённой роли).
Ограничение прав доступа к системе также позволит нам использовать её в коммерческих целях, то есть контролировать возможность доступа пользователя к системе. Создание новых компонентов и просмотр информации в зависимости от факта оплаты.
Управление любыми компаниями является информационный процесс, в котором информации приняты, обработаны, затем вырабатывается решение, решение доводится до исполнителей, действия которых контролируются (рис.2.1.1).
Рис. 2.1.1. Структурная схема программного модуля
Документооборот - главная организационная проблема деятельности службы делопроизводства и проблема технологии документационных процессов, поэтому занимает место узлового звена любой системы делопроизводства.
Документы, доставлены в организацию, должны быть зарегистрированы и обработаны. Обработки входящих документов включают регистрацию в журнале. Зарегистрированные документы рассматривают руководителем и передаются исполнителям. Документы находятся у исполнителя до окончательного решения вопроса.
Рис. 2.1.2. Документооборот на предприятии
Организация документооборота имеет много общего с организацией механического конвейера (рис. 2.1.2).
Входящие документации являются документации, поступающие на предприятие от других организаций. Исходящая документация является документация, которая компания отправляет другим предприятиям. Исходящая документация - это документ, который несёт в себе информацию, выработанную на предприятии в целях передачи информации в другие компании: письма, приказы ,справки, отчеты и телеграммы.
Рис.2.1.3.Схема документооборота
В случае, когда документ создается в самой компании, то может возникать внутренний этап прохождения документа (инициация - исполнение - согласование - утверждение - регистрация). Именно на внутреннем этапе прохождения документа часто возникает создание документа в разных версиях. Например, на этапе согласования, когда появляются замечания от разных лиц.
Каждый документ в процессе движения проходить обязательно три основные: операции: регистрация, контроль, направление в дело.
2.2 Разработка схемы информационных потоков
База данных приложения работает под управлением СУБД MySQL и может располагаться на отдельном сервере. Путь к базе данных определяется в конфигурационном файле приложения (mysql.init) и может динамически изменяться при работе приложения.
В базе данных приложения хранится информация о зарегистрированных пользователях, объектах приложения, а также доступности для пользователя определённых операций и доступных каждому пользователю объектах. База данных приложения включает три основных набора таблиц:
Таблицы, хранящие информацию о зарегистрированных пользователях и их правах доступа
Таблицы, хранящие информацию о документах и архивах системы
Таблицы, определяющие список рассылок системы, доступных пользователю
Приложение использует две учётные записи для работы с базой данных – queryInformer для получения данных и dataWriter для модификации, вставки и удаления данных.
Структура базы данных показана на рисунке 2.1.
Рис. 2.1. Обобщённая схема структуры базы данных приложения.
Операции модификации базы данных осуществляются с помощью хранимых процедур, право на исполнение которых имеет только пользователь dataWriter. Это позволяет жёстче контролировать переданные параметры, не допускать нарушения целостности данных или их удаления и даёт возможность журналирования всех операций с указанием пользователя, выполнившего текущую операцию. Информация аудита записывается в таблицы t_archive.
Данные о пользователях включены в таблицы t_logins и t_users. Таблица Logins содержит идентификационный номер пользователя, его учётное имя и пароль в зашифрованном виде, а в таблице t_users хранятся такие данные как фамилия, имя, адрес электронной почты.
В таблице t_document перечислены имеющиеся в приложении на данный момент документы. Информация о шаблонах, предоставленных данной системе хранится в таблице t_templates. Таблица t_users содержит ссылки на таблицы t_document, хранящей список определённых нами документов и архивов, хранящей список документов которые мы можем предоставить на конкретный пользователь. Таким образом, мы можем гибко изменять систему управления документов, как вводя новые возможности сохранения и регистрируя их в таблице t_template, так и определяя новые архивы документов и регистрируя их в таблице t_archive.
Принадлежность архива к определённому пользователю определяется записями в таблице t_archive_user, связанной внешними ключами с таблицами t_archives и t_users.
Каждому пользователю выделяются следующие права на работу с системой:
Создание/удаление/модификация документов
Создание/удаление/модификация шаблонов
Создание/ уведомления
Создание/ рассылки
Описание структуры базы данных представлено в таблице 2.1.
Таблица 2.1 – Структура базы данных
Название таблицы
Описание
t_document
Содержит данные о документах
t_users
Содержит данные о пользователях
t_document_users
Делает привязку документ- пользователь
t_archive
Содержит архивы
t_mailing_list
Список рассылки
t_template
Содержит шаблоны
t_archive_user
Делает привязку архив-пользователь
t_notification
Уведомление
Далее представлено описание всех таблиц базы данных и пояснения к полям в этих таблицах.
Таблица 2.2 – Таблица данных «t_document»
Поле
Тип
Описание
id_document
Числовой
Номер документа (индекс)
name
Символьный
Название документа
Current_station
Символьный
Текущая станция
Number_of_days
Числовой
Количество дней в работе
Send_date
Дата
Дата отправки
id_group
Числовой
Индекс группы
sender
Символьный
Отправитель
progress
Числовой
Прогресс обработки документа
Таблица 2.3 – Таблица данных «t_archive»
Поле
Тип
Описание
id
Числовой
Индекс
archive_name
Символьный
Имя архива
send_date
Дата
Дата отправки
sender
Символьный
Отправитель
Таблица 2.4 – Таблица данных «t_mailing_list»
Поле
Тип
Описание
id
Числовой
Индекс
name
Символьный
Название рассылки
Template_name
Символьный
Индекc шаблона
Таблица 2.5 – Таблица данных «t_template»
Поле
Тип
Описание
id
Числовой
Индекс
Name
Символьный
Название шаблона
Таблица 2.6 – Таблица данных «t_archive_user»
Поле
Тип
Описание
id
Числовой
Индекс
id_user
Числовой
Номер пользователя
id_archive
Числовой
Номер архива
Таблица 2.7 – Таблица данных «t_users»
Поле
Тип
Описание
id_user
Числовой
индекс
surname
Символьный
Фамилия
name
Символьный
Имя
User_name
Символьный
Имя пользователей
status
Числовой
В сети
Email_address
Символьный
Адрес e-mail
role
Символьный
роль
occupation
Символьный
должность
Таблица 2.8 – Таблица данных «t_notification »
Поле
Тип
Описание
id
Числовой
Индекс
theme
Числовой
Тема
message
Числовой
сообщение