Автоматизация учета и контроля принятых решений в ВУЗе

Введение

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

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

В высших учебных заведениях наряду с иерархической системой управления существует сеть коллегиальных органов управления, призванных решать поставленные задачи, вырабатывать направления деятельности для совершенствования, принимать определенные решения и назначать ответственных за их исполнение. К таким органам управления в университете относятся: Ученый Совет, Научно-методический Совет, Ректорат, Советы факультетов, Заседания деканатов и т.д. На каждом из заседаний перечисленных органов принимается, как правило, ни одно, а несколько решений по ряду рассматриваемых вопросов. Каждое решение должно быть доведено до лица, ответственного за его исполнения. По окончании учебного года необходимо предоставлять отчеты об исполнении принятых решений. Большое количество принятых решений, многообразие ответственных исполнителей зачастую затрудняет осуществлять мониторинг выполнения принятых решений. Поэтому автоматизация процесса учета и контроля принятых решений позволит повысить эффективность управления как вузом в целом, так и на каждом факультете и кафедре в отдельности.[2] Что и определяет актуальность данной темы дипломной работы.

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

Данный программный  продукт должен обеспечивать:

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

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

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

• обосновать выбор средств разработки приложения;
• спроектировать и внедрить приложение.

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

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

1 Техническое задание

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

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

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

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

Хранение - Централизованное хранилище данных позволяет решить целый ряд проблем:

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

Атрибутивный и контекстный поиск (См. Таблица 1).

Таблица 1 – Требования к программному продукту

1.2 Теоретические аспекты контроля исполнения принятых решений в университете

Одним из многочисленных методов управления в университете является метод вовлечения сотрудников в управление, который подразумевает создание в вузе коллегиальных органов управления, уполномоченных принимать решения по определенным сферам деятельности учебного заведения. В КГУ на уровне университета такими органами являются Ученый Совет,  Ректорат и Научно-методический совет. На факультетах функционируют Деканат, Совет факультета и Методический совет факультета.

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

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

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

Таким образом, все решения, принимаемые в университете, можно  классифицировать по ряду признаков (См. Таблица 2).

Таблица 2 – Обобщенная классификация принимаемых решений в вузе

Для того чтобы решения не «зависали в воздухе» необходимо систематически осуществлять контроль за их исполнением. Одним из элементов контроля, существующих в университете на сегодняшний день,  является отчет о выполнении принятых решений. Деканаты факультетов отчитываются за выполнение решений Ректората, Ученого Совета и НМС.  Также на Советах факультета ежегодно рассматривается вопрос о выполнении решений коллегиальных органов управления факультетом. Единой утвержденной формы отчета в университет нет, поэтому этот документ делается произвольно. Безусловно, отчетность за исполнение принятых решений является одним из элементов, способствующих результативности системы менеджмента вуза. Но отчеты отражают свершившиеся уже факты, либо не свершившиеся по каким-либо причинам и не способствуют выполнению в процессе деятельности подразделений.

На наш взгляд эффективность  выполнения принятых решений можно  повысить, если внедрить на факультетах  университета автоматизированную систему, которая позволит:

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

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

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

Формировать различные  виды отчетов по исполнению принятых решений:

• Отчет о выполненных/не выполненных решениях указанного коллегиального органа управления за указанный период времени;
• Отчет о выполненных/не выполненных решениях ответственного исполнителя за указанный период времени.

Рассчитывать процент выполненных/не выполненных решений указанного органа управления за указанный период времени;

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

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

Заполнение базы принятых решений  ведется следующим образом:

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

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

Поставленные задачи будут решаться следующим образом:

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

Преимущество данной системы в  том, что многозвенные распределенные приложения обеспечивают эффективный доступ удаленных клиентов к базе данных, так как в них для управления доступом к данным применяется специализированное программное обеспечение промежуточного слоя. В качестве промежуточного слоя выбран Microsoft SQL Server 2000. В данном трехзвенном приложении (См. Рисунок 1) будут выполняться следующие функции:

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

Рисунок 1 - Схема обмена данными

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

Сервер БД обрабатывает список клиентов, которые зарегестрировались в системе и если данный пользователь активен и ему было поручено выполнение какой-либо задачи то он мгновенно получает сообщение от администратора системы. Если данный пользователь не активен, то он получает сообщение в тот момент когда он станет активным.

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

1.3 Требования к программному продукту и системе

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

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

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

Необходимо, чтобы на персональном компьютере была установлена операционная система Windows XP/NT. Размер занимаемой памяти для установки программы на винчестер компьютера необходимо около 100 Мбайт свободного места. Программа рассчитана на разрешение экрана 1024 на 768 точек или выше, глубина цвета должна быть 32 бита. При более больших разрешениях программа будет занимать немного меньше  площади экрана, а при меньших разрешениях могут быть неудобства, например некоторые части окон с навигационными элементами, могут оказаться за пределами видимости. Так же для работы программы необходимо установить Microsoft SQL Server на одном компьютере (сервере) для создания распределенной базы данных. При работе с клиентской частью программы для создания отчетов и хранения документов в формате *.xls необходим Microsoft Office.

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

2 Описание программного продукта

2.1 Среда разработки  программного продукта

Реляционная база данных (РБД) отличается способом представления информации, находящейся в ней. Данные в такой базе хранятся в плоских таблицах. Каждая таблица имеет собственный, заранее определенный набор именованных колонок (полей). Поля таблицы обычно соответствуют атрибутам сущностей, которые необходимо хранить в базе. Количество строк (записей) в таблице неограниченно, и каждая запись соответствует отдельной сущности. Каждая таблица должна иметь первичный ключ (ПК) — поле или набор полей, содержимое которых однозначно определяет запись в таблице и отличает ее от других. Связь между двумя таблицами обычно образуется при добавлении в первую таблицу поля, содержащего значение первичного ключа второй таблицы. Реляционные СУБД (РСУБД) предоставляют средства для всевозможных пересечений и объединений любых таблиц, отбора записей по разнообразным условиям, группировки и сортировки результатов. Реляционная база данных сочетает наглядность представления информации с простотой (относительной) реализации своей концепции и является наиболее популярной структурой для хранения данных на сегодняшний день. Общепринятым стандартом языка для обработки данных в реляционных БД является язык SQL.[3]

SQL (Structured Query Language) — язык  структурированных запросов) является  стандартным языком для работы с реляционными БД. Кроме стандартных реляционных операций, этот язык предоставляет возможности для изменений структуры таблиц. Различные варианты SQL используются во всех, как серверных, так и в настольных реляционных СУБД.

Он разделяется на две основные части: DDL (Data Definition Language — язык определения данных) и DML (Data Manipulation Language — язык обработки данных).

DDL предоставляет средства для  создания и изменения структуры  хранения данных (БД, таблиц, процедур, типов данных и т.п.). DML предназначен для чтения и изменения данных.

Сервер для управления реляционными БД обычно называют SQL-сервером. Существует общий стандарт SQL для серверов - ANSI SQL 92, однако поддержка его у производителей СУБД сильно отличается. Причем дело с этим настолько плохо, что может различаться даже синтаксис основных операторов DML, не говоря уже о функциях, триггерах и прочих особенностях SQL. Поэтому о совместимости говорить сложно, хотя кое-какие сдвиги в этом направлении имеются. Наиболее близки к стандарту: Borland InterBase, Microsoft SQL Server, IBM DB2 Universal Database. Исходя из этого, было принято решение исследовать особенности реляционных баз данных в Microsoft SQL Server, как в самом доступном и распространенном приложении для управления реляционными БД.[4]

Для подключения к Microsoft SQL Server из практически  любого языка программирования используются так называемые ODBC драйвера. ODBC является одним из самых старых выпущенных средств разработки приложений для работы с базами данных. Основной причиной разработки ODBC была необходимость предоставить программистам простой способ доступа к содержимому баз данных с минимальной зависимостью от какого-либо конкретного языка. Основные принципы ODBC стандартны для Windows – для работы используются соответствующие драйвера, которые содержаться в DLL (Dynamic Link Library – динамически подключаемые библиотеки). Эти драйверы можно получить непосредственно от поставщика базы данных – чаще всего прямо в пакете программ.

Также Microsoft SQL Server обеспечивает защиту данных от несанкционированного доступа. Эта задача решается при помощи идентификации пользователей внутри СУБД, раздачи этим пользователям соответствующих прав доступа на объекты внутри СУБД, а также при помощи аудита доступа к объектам. Идентификация решается при помощи присвоения пользователю соответствующего регистрационного имени, а аутентификация, т.е. подтверждение того, что пользователь является именно тем лицом, за которое он себя выдает, решается при помощи пароля.[5]

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

Объекты БД (баз данных) в Delphi основаны на SQL и включают в себя полную мощь Borland Database Engine (BDE). В состав Delphi также включен Borland SQL Link, поэтому доступ к СУБД (Система Управления Базой Данных) происходит с высокой эффективностью.[6]

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

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

Приложения Delphi связываются с серверами баз данных через BDE . Все функции доступа к данным выполняются в контексте одной или нескольких сессий связи BDE. Так как Delphi является объектно-ориентированной средой разработки, механизм доступа реализован в виде двух компонентов – TADOQuery и TADOTable. Обращение к данным осуществляется через особую систему управления – программный комплекс, называемый сервером баз данных. Клиентское приложение отправляет серверу запрос, выполненный на языке SQL, а сервер производит с данными необходимые манипуляции. В частности, если клиент передал запрос на выборку данных, то сервер возвращает набор данных, с которым и работает клиентское приложение.[7] Таким образом, клиентское приложение должно выполнять следующие операции:

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

Клиент и сервер иногда взаимодействуют через посредника. Так BDE- ориентированные Delphi-клиенты соединяются с сервером баз данных посредством драйверов SQL Links.

Так же Borland Delphi 7 – это общепризнанный лидер среди инструментов для создания приложений и систем, функционирующих на платформе Windows. Передовая объектно-ориентированная технология визуального проектирования позволяет отдельным программистам и коллективам разработчиков  почувствовать уверенность в возможности полного удовлетворения запросов самых требовательных пользователей и устойчивость своего положения на рынке высоких технологий. Сочетание возможностей быстрого прототипирования приложений с технологиями уровня предприятия обеспечивает плавное и предсказуемое развитие проектов любого масштаба.[8]

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

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

Borland Delphi 7 - это комбинация нескольких важнейших технологий:

• Высокопроизводительный компилятор в машинный код;
• Объектно-ориентированная модель компонент;
• Визуальное построение приложений из программных прототипов;
• Масштабируемые средства для построения баз данных.[9]

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

Для разработки базы данных была выбрана  система управления базами данных Microsoft SQL Server 2000, являющаяся одним из самых популярных приложений в семействе настольных СУБД и способная функционировать под управлением любой операционной системы семейства Windows. SQL Server имеет в своем арсенале средства для контроля целостности и защиты       данных [10].

В процессе разработки базы данных для программы «Автоматизация учета и контроля принятых решений в ВУЗе» было создано 3 таблицы (См. Рисунок 2).

Рисунок 2 – Схема базы данных

Таблица Login служит для хранения данных пользователя. Состоит из следующих полей:

• Fam – хранит информацию о фамилии пользователя, тип поля Char, размер 10 символов;
• Name – имя пользователя, тип поля Char, размер 10 символов;
• Otch – отчество пользователя, тип поля Char, размер 10 символов;
• Kafedra – название кафедры, к которой относится сотрудник, тип поля Char, размер 10 символов;
• Dolzhnost – занимаемая должность, которое связано с полем Login в таблице opisanie, тип поля Char, размер 45 символов;
• Stepen – ученная степень сотрудника, тип поля Char, размер 10 символов;
• Login – имя учетной записи, тип поля Char, размер 10 символов;
• Password – пароль, для подтверждения учетной записи, тип поля Char, размер 10 символов.