Повышение эффективности предприятия на основе систем электронного документооборота

Повышение эффективности предприятия на основе систем электронного документооборота

САНКТ-ПЕТЕРБУРГСКИЙ ГУМАНИТАРНЫЙ УНИВЕРСИТЕТ ПРОФСОЮЗОВ

Факультет культуры

Кафедра информатики и математики

Выпускная квалификационная работа

Повышение эффективности предприятия на основе систем электронного документооборота

Оглавление

Введение

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

1.1 Характеристика потребностей рынка

1.2 Аппаратное, сетевое, программное обеспечение предприятия     

1.3 Сравнительный анализ систем электронного документооборота

1.4 Анализ существующей системы документооборота

1.5 Требования к внедряемой информационной системе

Выводы по первому разделу

2. Моделирование бизнес-процессов

2.1 Характеристика предприятия

2.2 Нотация IDEF0

2.3 Нотация IDEF3

2.4 Нотация DFD        

2.5 Проектирование логической и физической модели

Выводы по второму разделу

3. Разработка системы электронного документооборота

3.1 Особенности разрабатываемой информационной системы

3.2 Выбор технологии проектирования

2.3 Последовательность создания и технология построения информационной системы

3.4 Организация работы в области автоматизации

3.5 Основные технологические решения при построении информационной системы

3.6 Выбор системы управления базами данных

3.7 Выбор среды разработки приложения     

3.8 Разработка системы взаимодействия с SQL-Server

3.9 Создание базы данных

3.10 Разработка основной экранной формы

3.11 Разработка диалоговых экранных форм

3.12 Внутренняя организация информационной системы

3.13 Обоснование экономической эффективности

Выводы по третьему разделу       

Заключение

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

Приложение

Введение

электронный документооборот информационный данный

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

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

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

Объектом исследования является государственное бюджетное образовательное учреждение детский сад №2278 (ГБОУ д/с №2278). Основной деятельностью предприятия является первичная социализация детей, обучения их навыкам общения со сверстниками, а так же решения проблемы занятости их родителей. Предметом исследования стала база данных о воспитанниках детского сада, где каждому из них соответствует определенный обязательный набор документов.

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

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

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

Провести анализ деятельности предприятия.

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

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

Спроектировать систему электронного документооборота, удовлетворяющую потребностям предприятия.

Создать информационно-логическую модель предприятия.

Создать физическую модель данных на основе информационной модели.

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

Создать систему электронного документооборота.

Выпускная работа состоит из введения, трех разделов, заключения, списка литературы и приложения.

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

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

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

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

1.1 Характеристика потребностей рынка

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

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

Рынок СЭД в последние годы является одним из самых динамично развивающихся сегментов отечественной ИТ-индустрии. В 2009 году, по данным IDC, на фоне практически 50-процентного сокращения объемов общего рынка программного обеспечения в России, данный сегмент показал высокую устойчивость. Его спад по данным за 2009 год составил не более 20-25%. В численном выражении объем рынка СЭД на сегодня, по данным CNews Analytics, составляет около 220-250 млн. долл.

Потребителями технологий электронного документооборота являются различные по масштабу и специфике деятельности организации. Традиционно ключевым потребителем СЭД остается государственный сектор. По данным экспертов, порядка 30% проектов по внедрению технологий электронного документооборота приходится на государственные учреждения. При этом важно, что именно интерес со стороны государства стал основой устойчивости рынка СЭД, который даже в условиях кризиса получил существенный импульс развития. Электронный документооборот был назван ключевым элементом концепции «электронного правительства», реализация которой должна способствовать устранению бюрократических препон при взаимодействии государства, населения и бизнеса, а также снижению коррупции. В качестве особенности реализации проектов в органах государственной власти и крупных государственных институтах стоит отметить повышенные требования к информационной безопасности. Речь идет о построении (разработке) на базе тиражируемых программных продуктов защищенных систем электронного документооборота.

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

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

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

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

1.2 Аппаратное, сетевое, программное обеспечение предприятия

Технический парк предприятия, от которого во многом зависит выбор каких-либо программных решений, представляет собой 17 стационарных рабочих мест, объединенных в сеть. Сеть представляет собой одноранговую сеть топологии «звезда», где центральными узлами являются несколько сетевых коммуникаторов типа switch. Основной задаче, стоящей при работе с сетью - является доступ в Интернет, ресурсы которого активно используются для производственных нужд, таких как использование электронной почты, участие в вебинарах, либо использование информационных ресурсов. Отсутствие каких-либо серверных решений приводит к весьма ожидаемым результатам - отсутствию единой доменной сети, и, как следствие, набора правил для создания общих сетевых ресурсов, что изолирует рабочие станции от взаимодействия друг с другом. Техническое оснащение каждого рабочего места отличается друг от друга. Это связано с тем, что компьютерная техника покупается по мере необходимости в связи с введением новых правил вышестоящей организацией. Переход на электронную систему отчетов был не однородным и производился по мере требования отказа от рукописных отчетов. Согласно постановлению Правительства РФ от 1 января 2002 г. №1 "О Классификации основных средств, включаемых в амортизационные группы", срок службы составляет от 3 до 5 лет. В связи с этим мощность каждого рабочего места индивидуальна и варьируется в зависимости от сроков постановки техники на учет. На данный момент, наиболее мощная конфигурация компьютера - это:

Процессор - Intel Celeron G530 (Sandy Bridge, 2.4 ГГц, L3 2Мб, LGA1155);

Оперативная память - 4 Гб DDR3 1333 МГц;

Жесткий диск - 500 Гб (SATA III);

Видеокарта - интегрированная в процессор;

Операционная система Windows 7 Home Premium.

Компьютер подобной мощности хорошо подходит для решения стандартных офисных задач (работа с электронной почтой, документами Microsoft Word, Microsoft Excel, участие в вебинарах), и, исходя из данных характеристик, следует выбирать программное обеспечение.

.3 Сравнительный анализ систем электронного документооборота

Анализ проведен по девяти наиболее распространенным в России системам электронного докментооборота: Directum (Directum), DocsVision (DocsVision), Globus Professional (Проминфосистемы), PayDox (Paybot), 1С:Документооборот (1С), Босс-референт (БОСС - Референт, ГК АйТи), ДЕЛО (ЭОС), ЕВФРАТ (Cognitive Technologies), МОТИВ (Мотив).

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

регистрация и ввод документов;

работа с документами;

поиск и анализ информации;

поддержка бумажного документооборота;

стандартные средства настройки.

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

Основные характеристики систем электронного документооборота

Условные обозначения: «+» - возможность реализации; «-» - Возможность не реализована; «+/-» - Возможность реализована частично.

Для работы каждой из систем, необходимо взаимодействие с определенной СУБД. Расчет стоимости использования СУБД не входит в основную стоимость продукции (за исключением системы ЕВФРАТ, использующую собственную СУБД) и лицензии на нее приобретаются отдельно. Расчетная стоимость использования каждой из возможных СУБД предусматривается из предполагаемого объема базы данных. Так, например, компания Microsoft предоставляет бесплатное использование ресурсов MS SQL Server, в случае если общий объем всех используемых на предприятии баз данных не превышает 5Гб.

Расчетная стоимость СУБД для предприятия:

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

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

1.4 Анализ существующей системы документооборота

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

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

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

Передача любой информации осуществляется с помощью внешних носителей (floppy-диски, USB-носители), либо по электронной почте, основанной на сети Интернет и электронных ящиков известных провайдеров (Mail.ru, Yandex.ru, Google.ru), без использования ресурсов внутренней локальной сети.

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

1.5 Требования к внедряемой информационной системе

В данный момент выделены следующие пользователи информационной системы:

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

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

Медицинский работник - внесение информации, связанной с состоянием здоровья воспитанника.

К системе предъявляются следующие требования:

Поддержка основных операций связанных с документооборотом;

Реализация создания отчетов на основе созданных запросов;

Реализация должна происходить на с использованием программно-аппаратной части учреждения.

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

Добавление и корректировка данных в личных делах воспитанников;

Хранение файлов и документов, имеющих непосредственное отношение к личным делам воспитанников;

Составление отчетов по заранее заданным параметрам.

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

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

Выводы по первому разделу

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

. Моделирование бизнес-процессов

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

2.1 Характеристика предприятия

Государственное Бюджетное Образовательное Учреждение детский сад представляет собой предприятие, целью которого является первоначальное развитие и социализация детей в возрасте от 2 до 6 лет. На территории учреждения проходят постоянное обучение сотни учеников, разбитые на разные группы, в зависимости от возраста и уровня подготовки. Каждый из учащихся - это уникальная личность, для которой учреждение подготавливает отдельное личное дело. В личном деле учащегося хранится вся информация, связанная с ним, начиная от даты рождения и заканчивая характеристикой, предоставляемой по итогам выпуска. Основная часть информации проходит в виде бумажных документов (свидетельство о рождении, медицинские справки и т.д.), предоставляемых учебному заведению родителями или опекунами. Часть информации учебное заведение собирает самостоятельно, благодаря работе педагогов, и предоставляется в распоряжении администрации, для последующего внесения в личное дело.

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

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

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

2.2 Нотация IDEF0

Набор стандартов IDEF (ICAM DEFinition) был разработан специально для моделирования автоматизированного предприятия. Одним из стандартов набора является нотация функционального моделирования под кодовым названием IDEF0 [3].

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

Бизнес-модель опирается на следующие принципы:

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

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

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

)        Описание элементарной бизнес-операции осуществляется посредством задания алгоритма ее выполнения [4].

Поэтому для эффективного построения модели необходимо выполнение следующих действий:

•        Сбор информации об объекте, определение его границ;

•        Определение цели и точки зрения модели;

•        Построение, обобщение и декомпозиция диаграмм;

•        Критическая оценка, рецензирование и комментирование.

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

В нашем случае задачу можно сформулировать следующим образом: «Функционирование деятельности детского сада».

Первым шагом является определение исходных данных и материалов, то есть входных данных (Input), а также определение целей бизнес-процесса, то есть выходных данных (Output).

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

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

Правильное выполнение процесса должно обязательно контролироваться (какими-то стандартами, методиками, технологиями и прочее). В нотации IDEF0 это называется «управлением» (control) и обязательно должно отображаться на функциональной диаграмме [4].

Организация для своей работы руководствуется Уставом дошкольного учреждения, Законом об образовании РФ, Правилами внутреннего трудового распорядка, Конвенцией о правах ребенка, Трудовым кодексом РФ.

Сведем всю полученную информацию в контекстную диаграмму (рис. 1).

Рис. 1 - Контекстная диаграмма

Основной блок состоит из трех дочерних блоков. Все блоки декомпозиции имеют свои входные и выходные данные, правила и механизмы:

Организовать учет воспитанников

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

Подготовить отчет

В результате декомпозиции контекстной диаграммы получим диаграмму, как показано на рис. 2.

Рис. 2 - Диаграмма декомпозиции первого уровня

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

Рассмотрим более подробно:

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

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

Блок «Подготовить отчет». Происходит составление комплексно-тематического плана на основании собранных данных.

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

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

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

2.3 Нотация IDEF3

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

Работы, которые находятся на диаграмме IDEF0, необходимо рассмотреть детально с помощью методологии IDEF3.

Проведем декомпозицию работы «Организовать учет воспитанников» (рис. 3). Данная работа начинает выполняться, когда поступают заявки от родителей на прием воспитанников в детский сад. В том числе предъявляются документы на воспитанника для проверки. После проверки происходит прием воспитанников в детский сад, что подразумевает регистрацию нового воспитанника в базе и определение его в группу. Последним действием составляется отчет о проделанной работе.

Рис. 3 - Декомпозиция блока «Организовать учет воспитанников»

Проведем декомпозицию работы «Организовать кадровый учет, управление персоналом» (рис. 4). Данная работа начинает выполняться, когда поступают заявки о приеме на работу в детский сад. Вместе с заявкой поступает документация на нового сотрудника. Вся документация проходит проверку, после чего принимается решение о приеме на работу нового сотрудника. В случае положительного решения происходит прием нового сотрудника, что подразумевает регистрацию его в базе, распределение нагрузки и установка графика работы. Последним действием составляется отчет о проделанной работе.

Рис. 4 - Декомпозиция блока «Организовать кадровый учет, управление персоналом»

Проведем декомпозицию работы «Подготовить отчет» (рис. 5). Данная работа начинает выполняться, когда заканчивает сбор необходимой информации о воспитанниках и работниках детского сада. Последним действием составляется комплексно-тематический план.

Рис. 5 - Декомпозиция блока «Подготовить отчет»

.4 Нотация DFD

Диаграммы потоков данных (Data flow diagram, DFD) используются для описания документооборота и обработки информации. Наряду с IDEF0, DFD описывает моделируемую систему как сеть взаимосвязанных работ. Такие диаграммы используют в виде дополнения к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. Основная цель DFD - показать, как каждая работа преобразует свои входные данные в выходные, а также выявить отношения между этими работами [5].

Каждая DFD-диаграмма может содержать работы, внешние сущности, стрелки (потоки данных) и хранилища данных.

Проведем декомпозицию работы «Организовать учет воспитанников». DFD-диаграмма блока будет иметь вид, представленный на рис. 6.

Рис. 6 - Диаграмма потоков данных для функционального блока

«Организовать учет воспитанников»

Проведем декомпозицию работы «Организовать кадровый учет, управление персоналом». DFD-диаграмма блока будет иметь вид, представленный на рис. 7.

Рис. 7 - Диаграмма потоков данных для функционального блока

«Организовать кадровый учет, управление персоналом»

Проведем декомпозицию работы «Подготовить отчет». DFD-диаграмма блока будет иметь вид, представленный на рис. 8.

Рис. 8 - Диаграмма потоков данных для функционального блока

«Подготовить отчет»

2.5 Проектирование логической и физической модели

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

Инструментальное средство Erwin позволяет создавать ER-модели для описания объектов и связей между ними.имеет два уровня моделирования: логический и физический. На логическом уровне данные представляются так, как они выглядят в реальном мире. Объектами логического уровня являются сущности и атрибуты.

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

Исходными сведениями об объектах моделирования являются хранилища данных, полученные на предыдущем этапе проектирования диаграмм потоков данных [2].

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

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

2.5.1 Создание логической модели данных

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

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

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

После определения сущностей, связей между сущностями и атрибутов сущностей можно спроектировать локальные концептуальные модели [2].

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

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

         второй нормальной форме (сущность находится во 2НФ, если она находится в 1НФ и каждый неключевой атрибут полностью зависит от ПК (не должно быть зависимости от части ключа); 2НФ имеет смысл только для сущностей, имеющих сложный ПК);

         третьей нормальной форме (сущность находится в ЗНФ, если она находится во 2НФ и никакой неключевой атрибут не зависит от другого неключевого атрибута (не должно быть взаимосвязи между неключевыми атрибутами)).

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

Проанализируем разработанные DFD-диаграммы и построим логическую модель.

На основании разработанных DFD-диаграмм были выявлены следующие сущности («хранилища»):

Воспитанники.

Работники.

Должности.

Группы.

Занятия.

Нагрузка работников.

Следующий шаг - определение отношений между сущностями (рис. 9-11).

Рис. 9 - Локальная логическая модель «Организовать учет воспитанников»

Рис. 10 - Локальная логическая модель «Организовать кадровый учет, управление персоналом»

Рис. 11 - Локальная логическая модель «Подготовить отчет»

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

Слияние сущностей с одинаковыми именами и одинаковыми первичными ключами.

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

Сущность «Занятия» содержится в двух локальных логических моделях. Они имеют одинаковые имена и совпадающие первичные ключи. Все атрибуты в обеих сущностях являются общими. Следовательно, при объединении данная сущность будет включать в себя все атрибуты, которые присутствовали в каждой из сущностей. Точно так же объединяются другие сущности из рассматриваемых локальных моделей с одинаковыми именами и одинаковыми первичными ключами.

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

. Слияние общих связей из отдельных локальных моделей.

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

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

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

Рис. 12 - Глобальная логическая модель данных

2.5.2 Создание физической модели данных

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

На физическом уровне объекты базы данных (таблицы, колонки и так далее) должны называться, как этого требуют ограничения выбранной системы управления базой данных (СУБД). Физическая модель зависит от конкретной СУБД, поэтому одной и той же логической модели может соответствовать несколько физических моделей.

Так как логическая модель данных уже была создана, то для просмотра физической модели можно воспользоваться списком выбора, расположенным в правой части панели инструментов ERwin (вместо Logical выбрать Phisical).

Построение физической модели на основе логической предполагает ряд действий:

. Задание правил валидации и значений по умолчанию для значений колонок таблиц.

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

. Создание генераторов, триггеров и хранимых процедур. Тексты созданных в проекте триггеров и процедур можно просмотреть в меню Trigger Editor и Table Editor \ Stored Procedure соответственно.

. Существуют также триггеры ссылочной целостности для поддержания целостности между двумя связанными таблицами. Если в данной таблице выполняется вставка (Insert), изменение (Update) или удаление (Delete), то триггер ссылочной целостности сообщает СУБД, что нужно делать с теми строками у других таблиц, у которых значения внешнего ключа совпадают со значениями первичного ключа вставляемой, изменяемой или удаляемой строки. автоматически присваивает каждой связи значение ссылочной целостности, устанавливаемой по умолчанию, прежде чем добавить ее в диаграмму. Режимы RI, присваиваемые ERwin по умолчанию, могут быть изменены в редакторе Referent Integrity Default который вызывается, если щелкнуть по кнопке RI Defaults диалога Target Server.

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

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

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

Правила ссылочной целостности - это логические конструкции, которые выражают бизнес-правила использования данных. Они определяют, какие действия должна выполнить СУБД при удалении, вставке или изменении строки таблицы (экземпляра сущности). Заданные таким образом действия используются впоследствии при автоматической генерации триггеров, поддерживающих целостность данных [2].

Существуют следующие виды действий или правил, определяемых в логической модели:

         RESTRICT - запрет удаления, вставки или изменения экземпляра сущности.

         CASCADE - при удалении экземпляра родительской сущности удаление всех экземпляров дочерней сущности, ссылающихся на удаляемый родительский экземпляр.

         SET NULL - при удалении экземпляра родительской сущности атрибутам внешнего ключа всех экземпляров дочерней сущности присваивается значение NULL.

         SET DEFAULT - то же самое, что и в предыдущем случае, только вместо значения NULL присваивается значение по умолчанию.

         NONE - никаких действий не предпринимается.

         Эти правила задаются на вставку, удаление и изменение экземпляра как родительской, так и дочерней сущности. Таким образом, каждая связь должна обладать набором из шести правил, которые вводятся в поля, объединенные общим заголовком «RI Actions». При добавлении связи в диаграмму Erwin по умолчанию устанавливает для нее набор правил, которые можно редактировать.

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

         Erwin отмечает повторное использование имени сущности и атрибута;

         запрещает присвоение неуникальных имен атрибутов внутри одной модели (при соответствующей установке опции Unique Name), соблюдая правило «в одном месте - один факт». При создании физической модели необходимо задать название сущностей и их атрибутов только латинскими буквами, так как иначе при последующей передаче в базу данных возможно возникновение ошибок. Поэтому все сущности логической модели при переходе на физическую модель были переименованы.

Физическая модель данных представлена на рис. 13.

Рис. 13 - Физическая модель данных

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

Выводы по второму разделу

В данном разделе были созданы и описаны бизнес-процессы, которые протекают на предприятии.

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

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

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

. Разработка системы электронного документооборота

3.1 Особенности разрабатываемой информационной системы

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

Будущая информационная система будет решать следующие задачи:

хранение всей информации о воспитанниках в единой базе данных;

учет поступающих документов, связанных с личными делами воспитанников;

осуществление контроля дублирования документов;

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

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

необходимость хранения большого объема данных;

учет входящей документации;

контроль актуальности документации;

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

Параметры, на улучшение которых направлена разработка информационной системы:

достоверность информации, используемой для принятия решений;

уровень управляемости документооборотом;

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

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

упрощение процесса ведения документации;

обеспечение контроля над входящей информацией;

анализ информации в принятии управленческих решений;

исключения дублирования данных;

сокращение временных затрат на обработку необходимой документации;

сокращения числа ошибок в основных документах;

исключения использования неактуальной документации;

использование единой базы данных, для хранения всей информации

3.2 Выбор технологии проектирования

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

Выделяют два основных класса технологий проектирования: каноническая и индустриальная технология. Индустриальная технология включает два подкласса: автоматизированное (использование CASE-технологий) и типовое проектирование.

В процессе создания информационной системы применяется индивидуальная автоматизированная технология, поскольку применяются автоматизированные средства проектирования (языки программирования, CASE-средства, пакеты прикладных программ и т.д.) [2].

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

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

В настоящее время выделяют две основных методологии проектирования:

функциональное (структурно-ориентированное моделирование);

объектно-ориентированное моделирование.

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

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

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

3.3 Последовательность создания и технология построения информационной системы

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

В наиболее общем плане можно выделить следующие стадии:

планирование и анализ требований. Происходит исследование и анализ существующей информационной системы, и определение требований к создаваемой системе.

Проектирование. Разработка информационной системы, согласно сформулированным требованиям.

Реализация. Разработка и настройка программы, наполнение базы данных.

Следующей стадией является внедрение и непосредственная эксплуатация системы.

3.4 Организация работы в области автоматизации

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

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

Обучение сотрудников производится сотрудником обслуживающей компании.

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

3.5 Основные технологические решения при построении информационной системы

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

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

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

К основным достоинства архитектуры «клиент-сервер»:

повышение производительности, за счет использования параллельных систем;

оперативный доступ к информации;

возможность сокращения сетевого трафика;

снижение стоимости аппаратного обеспечения;

повышение уровня непротиворечивости данных.

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

3.6 Выбор системы управления базами данных

В рамках разрабатываемой информационной системы, были выдвинуты следующие требования:

поддержка операционной системы Windows;

средняя частота транзакций, умеренно высокое быстродействие;

большой объем поддерживаемых данных;

возможность использования системы несколькими пользователями;

невысокая стоимость программного продукта;

защищенность данных;

масштабируемость системы;

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

управляемость, т.е. простота администрирования и конфигурирования, вследствие отсутствия штатного специалиста по системе;

минимальная вероятность сбоев.

Поскольку в рамках данного проекта предполагается наличие нескольких пользователей на различных рабочих местах с возможностью единовременного доступа к хранимым данным, в качестве основной СУБД будет использоваться СУБД с клиент-серверной архитектурой. В соответствии с этим в качестве СУБД будет использоваться Microsoft SQL Server 2012.SQL Server 2012 Это первый серьезный апдейт системы с момента выхода SQL Server 2008 R2 в 2010 году. Что касается улучшений, то вендор делает упор на трех моментах: более высокая готовность к критическим миссиям, улучшенные возможности BI и большее соответствие модели cloud computing.

В СУБД появился BISM (Business Intelligence Semantic Model) - новый семантический поход к обработке информации. За счет более простой, фактически табличной модели представления данных он позволяет формировать аналитические выборки гораздо быстрее, чем при использовании UDM (Unified Dimensional Model). В результате не только аналитики, но и бизнес-пользователи получили возможность самостоятельно строить многофакторные запросы и репортинги без необходимости изучения механизмов формирования многомерных моделей данных на глубинном уровне.

В СУБД <#"656198.files/image013.gif">

Рис. 14 - основной вид окна программы

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

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

При смене таблицы, автоматически обновляется основное окно с данными, выводя записи из БД. Количество поддерживаемых таблиц ограничено только SQL-Server.

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

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

Кнопка «Обновить» служит для обновления данных в рабочем пространстве и проверке подключения к серверу базы данных. В случае отключения сервера - произойдет блокировка кнопок. При возобновлении подключения кнопки снова станут активны.

Кнопка «Открыть» служит для создания и открытия каталога Windows, соответствующего выделенной в рабочем поле строки таблицы. Ряд информации и файлов, необходимых для хранения в БД удобнее хранить в сетевом каталоге, который централизованно открывается с помощью данной кнопки. Если в процессе работы с базой данных для данной записи ни разу не требовалось создать собственный каталог с файлами - произойдет генерация каталога со следующим путем:

имя_хранилища\имя_таблицы\ID_строки

После чего произойдет открытие данного каталога в проводнике Windows. Каталог имеет унаследованные права от старшего каталога имя_хранилища, т.е. доступен для изменения по сети. Данная система предназначена для хранения файлов различных форматов в пределах классификации одной базы данных, тем самым создавая банк актуальной информации и исключая вариант использования документов разных версий.

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

3.11 Разработка диалоговых экранных форм

Для взаимодействия с внутренней структурой базы данных в программе существуют еще две кнопки «Добавить» и «Изменить». Они предназначены для вывода формы с мастером работы со строками.

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

Рис. 15 - Форма создания новой записи в таблице

Использование кнопок «Далее» и «Назад» позволяет свободно перемещаться по данным формы, не боясь потерять ранее введенные данные. Вся информация, ранее внесенная в форму, фиксируется, и запоминается до момента закрытия формы.

Кнопка «Готово» активируется в случае заполнения всех ключевых полей, при нажатии на которую, происходит создание подключения и генерация sql-запроса и последующее закрытие формы.

Кнопка «Отмена» активна всегда. В случае заполнения хотя бы одного поля формы, при нажатии на нее появляется предупреждение о закрытии формы и потере внесенных данных.

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

Рис. 16 - Форма изменения существующей записи в таблице

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

В случае прерывания через клавишу «Отмена» внесений изменений в таблицу не происходит.

.12 Внутренняя организация информационной системы

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

Все регулярно повторяющиеся функции вынесены в отдельные методы (см. Приложение), такие как:

Учет точного времени системы;

Создание лог-записей;

Создания списка таблиц;

Обновление данных в таблицах, проверка подключения в sql-серверу;

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

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

3.13 Обоснование экономической эффективности

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

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

Выводы по третьему разделу

В данном разделе была проведена разработка и описание системы электронного документооборота на предприятии.

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

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

Заключение

В завершении работы над выпускной квалификационной работы удалось достичь всех поставленных целей и задач.

Был выполнен анализ деятельности предприятия ГБОУ ДОУ д\с №2278 и проанализированы виды и направления деятельности.

Проведен анализ бизнес-процессов, отражающих взаимодействие ГБОУ ДОУ д\с №2278 как с точки зрения внутреннего взаимодействия. Так и с точки зрения взаимодействия с внешней средой. Основная часть бизнес-процессов на предприятии связана с организацией кадровой политики и ведению внутренней документации по своим воспитанникам, т.е. с информацией, составляющей личные дела воспитанников и сотрудников.

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

Для создания собственно информационной системы было решено использовать такие продукты, как SQL Server 2012 и Visual Studio 2010 от корпорации Microsoft, т.к. они наиболее полно позволяли реализовать стоящие перед проектом требования. Информационная система позволяет вести электронную базу данных по воспитанникам и сотрудникам учреждения, создать единое хранилище документации, позволяя избегать дублирования и потери данных, а так же формировать единое представление о состоянии дел на предприятии. Переход на данный программный продукт существенно сократит затрат времени на формирование и учет документации по воспитанникам учреждения, а так же позволит экономить денежные средства предприятия.

Были сформированы требования ГБОУ ДОУ д\с №2278, предъявляемые к проектированию и разработке программного продукта.

Для реализации процесса проектирования были использованы такие case-редакторы как BPWin и ERWin.

Реализация самой разработки была выполнена с использованием программных средств среды Visual Studio 2010, на языке разработки C# 4.0 с использованием библиотек для взаимодействия со средой SQL-Server. Было проведено создание пользовательского интерфейса. Проведена отладка программного продукта и готовая программа была представлена для использования в исследуемой организации.

Можно сделать вывод, что предложенная разработка является эффективной системой электронного документооборота для повышения эффективности работы предприятия ГБОУ ДОУ д\с №2278.

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

Карпова, Т. С. Базы данных: модели, разработка, реализация / Т. С. Карпова. - СПб. : Питер, 2011.

Маклаков, С. В. BPwin и ERwin. CASE - средства разработки информационных систем / С. В. Маклаков. - М.: Диалог-МИФИ, 2000.

Черемных, С.В. Моделирование и анализ систем. IDEF-технологии: практикум / С.В.Черемных, И.О. Семенов, B.C. Ручкин. - М. : Финансы и статистика, 2006.

Федорова, Д.Э. CASE-технологии / Д. Э. Федорова, Ю.Д. Сесенов, К.Н. Чижик. - М.: Горячая линия Телеком, Радио и связь, 2005.

Шилдт Г. Полное руководство С#4.0 / Вильямс, Москва, Санкт-Петербург, 2001.

Роберт Виейра - Программирование баз данных MS SQL Server 2005. Базовый курс . / Вильямс, Москва, Санкт-Петербург, 2001.

Чубукова С.Г. Элькин В.Д. Основы правовой информатики / Диалог-МИФИ, 2004

Приложение

Глобальные переменные:static string[] inf; //информация о названии столбцов в таблицеstatic string[] query; //информация о содержании столбцов в таблицеstatic string ID; //информация о выбраннной в dataGridView1 строкеstatic bool Wquery; //информация о типе запроса. Добавление или изменениеstatic string Time; //информация о времени

public static string Message = ""; //информация о записи в лог static string Table;

Метод учета времени:void Vremya()

{

//Создаем переменную, содержащую точное время(Data.Message != "")

{ThToday = DateTime.Now;(ThToday.Hour > 10).Time = ThToday.Hour.ToString() + ":";.Time = "0"+ThToday.Hour.ToString() + ":";(ThToday.Minute > 10).Time += ThToday.Minute.ToString() + ":";.Time += "0" + ThToday.Minute.ToString() + ":";(ThToday.Second > 10).Time += ThToday.Second.ToString() + " ";.Time += "0" + ThToday.Second.ToString() + " ";

//Вписываем в лог значение времени + текст ошибки из глобальной переменной. Переходим на следующую строку.Text += Data.Time + Data.Message + Environment.NewLine;

//Автоматическая прокрутка лога.SelectionStart = txtLog.Text.Length;.ScrollToCaret();

}

Метод выбора таблицvoid setTable()

{

//Заполняем ComboBoxconn = new SqlConnection(Data.connStr);

{.Open();

}

{;

}

//Заполняем dataGridView2 cmd = new SqlCommand("SELECT name FROM sysobjects WHERE type = 'U'", conn);DA = new SqlDataAdapter(cmd);qw = new DataSet();.Fill(qw);.DataSource = qw.Tables[0];.Close();

conn.Dispose();

//Заполнение ComboBox списком таблиц

for (int i = 0; i < dataGridView2.RowCount - 1; i++).Items.Add(dataGridView2[0, i].Value.ToString().Trim());.SelectedIndex = 0;

}

Метод обновления информацииvoid Reset()

{

//Обновляем данные в видимой таблице dataGridView1

SqlConnection conn = new SqlConnection(Data.connStr);

{.Open();

}(SqlException se)

{

//Если подключение отсутсвует, блокирует кнопки работы с базой.Message = "Ошибка подключения к базе: " + se.Message;

btnAdd.Enabled = false;.Enabled = false;.Enabled = false; ;

}query = "Select * From "+ cmBoxTable.Text;cmd = new SqlCommand(query, conn);DA = new SqlDataAdapter(cmd);qw = new DataSet();.Fill(qw);.DataSource = qw.Tables[0];

//Обновляем массив с содержанием заголовков= "Select * From " + cmBoxTable.Text;= new SqlCommand(query, conn);(SqlDataReader dr = cmd.ExecuteReader(CommandBehavior.CloseConnection))

{.inf = new string[dr.FieldCount - 1];(int i = 1; i < dr.FieldCount; i++).inf[i - 1] = dr.GetName(i).ToString().Trim();

}.Close();.Dispose();

//Скрываем первый столбец, содержащий ID строк.Columns[0].Visible = false;

}

Информация о подключении к базе данных

public static string connStr = @"Data Source=(local)\SQLEXPRESS;Catalog=DS_BD;Security=True";

Инициализация приложения:Osnova()

{();

//Создает первое подключение к базе данных

SqlConnection conn = new SqlConnection(Data.connStr);

try

{.Open();.Message = "Соединение с базой успешно установлено";

//Создаем список таблиц();

}(SqlException se)

{

//Если соединение отсутвует - блокирует кнопки работы с базой.Message = "Ошибка подключения к базе: "+ se.Message;

btnAdd.Enabled = false;.Enabled = false;.Enabled = false;();;

}

//Создает массив, содержащий имена всех столбцов, кроме первого

string query = "Select * From " + cmBoxTable.Text;cmd = new SqlCommand(query, conn);(SqlDataReader dr = cmd.ExecuteReader(CommandBehavior.CloseConnection))

{.inf = new string[dr.FieldCount - 1];(int i = 1; i < dr.FieldCount; i++).inf[i - 1] = dr.GetName(i).ToString().Trim();

}();

//Обновляем информацию в dataGridView1DA = new SqlDataAdapter(cmd);qw = new DataSet();.Fill(qw);.DataSource = qw.Tables[0];.Close();

conn.Dispose();

//Скрываем первый столбец, содержащий ID.Columns[0].Visible = false;

}

Метод создания мастера добавления записи

private void btnTest2_Click(object sender, EventArgs e)

{.Message = ""; //отчищаем переменную с сообщением.Wquery = false; //Устанавливаем значение, определяющее тип запроса.query = new string[Data.inf.Length]; //Создаем массив, содержащий все значения будущего запросаfrm = new AddTask();.lblName.Text = "Мастер добавления новой записи"; //Корекктируем лэйблы.lblInf.Text = "Введите " + Data.inf[0];

Data.Table = cmBoxTable.Text;.ShowDialog();

frm.Dispose(); (); //Вставляем в лог запись об успешном добавлении\содержащую код ошибки(); //Обновляем значения полей

}

Метод удаления записи

private void btnDel_Click(object sender, EventArgs e)

{

//Открываем подключениеconn = new SqlConnection(Data.connStr);

{.Open();

}(SqlException se)

{.Message = "Ошибка подключения к базе: " + se.Message;

MessageBox.Show("Ошибка подключения к базе");();;

}

//Формируем запрос на удаление строки, условие удаление ID строки в базе

string qw = "Delete From "+cmBoxTable.Text+" Where ID = " + dataGridView1[0, dataGridView1.CurrentRow.Index].Value.ToString();

DialogResult result = MessageBox.Show("Запись и все свяанные с ней документы будет удалены без возможности восстановления! Вы уверены, что хотите ее удалить?", "Внимание!", MessageBoxButtons.YesNo, MessageBoxIcon.Warning, MessageBoxDefaultButton.Button2);(result == DialogResult.Yes) //Вставляем результат диалога. В случае положительного ответа, удаляем запись

{cmd = new SqlCommand(qw, conn);

{ .ExecuteNonQuery();.Message = "Запись успешно удалена";

}(SqlException se)

{.Message = "Ошибка удаления записи: " + se.Message;

MessageBox.Show("Ошибка удаления записи!");

return;

}DataDirectory = dataGridView1[0, dataGridView1.CurrentRow.Index].Value.ToString().Trim();= "\\\\Astral\\тест\\" + cmBoxTable.Text+"\\" +DataDirectory;dd = new DirectoryInfo(DataDirectory); //теперь мы в папке \Astral\тест\база(dd.Exists == true).Delete(); //Удаляем дирректорию с файлами

};.Close();.Dispose();

Vremya(); //Вставляем запись из лога();

Метод открытия индивидуальной папкиvoid btnOpen_Click(object sender, EventArgs e)

{

//Открывает директорию, заведеную по ID в базе.

string DataDirectory = dataGridView1[0, dataGridView1.CurrentRow.Index].Value.ToString().Trim();= "\\\\Astral\\тест\\"+cmBoxTable.Text+"\\" + DataDirectory;dd = new DirectoryInfo(DataDirectory); //теперь мы в папке \Astral\тест\база

if (dd.Exists == false).Create(); //если папки нет то создадим

Process.Start(DataDirectory);

}