Разработка автоматизированной системы "Расписание" и её внедрение в работу учебного отдела ВУЗа

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рис.8. Связь "много-ко-многим"

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

В отличие от других рассматриваемых средств разработки, СУБД Access имеет русифицированный интерфейс и частично переведенный на русский язык файл контекстной помощи [34].

Перечисленные факторы определили выбор СУБД Access в качестве среды разработки автоматизированной системы "Расписание". В следующем параграфе мы рассмотрим этапы реализации базы данных.

2.2 Структурный подход к проектированию автоматизированной системы "Расписание" и построение моделей данных

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

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

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

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

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

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

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

принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

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

SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы. Данный метод предназначен для построения функциональной модели какого-либо объекта предметной области и представляет собой совокупность методов, средств и процедур.

DFD (Data Flow Diagrams) диаграммы потоков данных. В основе данной методологии лежит построение модели анализируемой ИС, проектируемой или реально существующей в соответствии с методологией. В соответствии с данным методом модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю.

ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь". Предназначена для формализации информации о сущностях и их отношениях.

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

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

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

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рис.9. Функциональный блок и интерфейсные дуги

Построение SADT модели начинается с представления всей системы в виде простейшей компоненты - одного блока и дуг, изображающих интерфейсы с функциями вне системы, т.к блок представляет всю систему, как единое целое. Имя указанное в блоке является общим. Это справедливо и для интерфейсных дуг. Они также представляют полный набор внешних интерфейсов системы в целом (рис.10).

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

Рис.10. Контекстная диаграмма АС "Расписание"

Рис.11. Диаграмма декомпозиции второго уровня АС "Расписание"

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

Таким образом, построена концептуальная модель предметной области, с помощью средств проектирования ИС BPWin.

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

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

определение типов сущностей;

определение типов связей;

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

определение доменов атрибутов;

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

определение ограничений целостности.

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

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

Входную информацию принято делить на условно-постоянную и оперативно-учетная информация.

К условно-постоянной информации относятся:

план учебного расписания;

списки отделений и факультетов;

списки преподавателей;

перечень дисциплин, аудиторий;

время пары.

К оперативно-учетной информации относятся:

списки курсов и групп;

дата;

количество студентов в группах.

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

Таблица 1.

Перечень первичных документов с реквизитами

№ п/п	Наименование документа	Реквизиты
1.	План расписания	Отделение Факультет Курс Дата Время Группы Дисциплина ФИО преподавателя Аудитория
2.	Списки преподавателей	№ преподавателя ФИО преподавателя Должность Кафедра
3.	Перечень дисциплин	№ дисциплины Наименование дисциплины Вид занятия
4.	Списки отделений и факультетов	№ отделения Наименование отделения Наименование факультета
5.	Списки курсов и групп	№ курса № группы Количество студентов
6.	Списки аудиторий	№ аудитории Вместимость
7.	Номер пары	№ пары Начало занятий Конец занятий

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

№ преподавателя, ФИО преподавателя, должность, кафедра, № дисциплины, наименование дисциплины, вид занятия, № отделения, наименование отделения, наименование факультета, № курса, № группы, количество студентов, № аудитории, вместимость, № пары, начало занятий, конец занятий.

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

Получается следующие зависимости:

№ преподавателя, ФИО преподавателя, должность, кафедра - отражает сведения о преподавателе.

№ дисциплины, наименование дисциплины, вид занятия - отражает сведенья о преподаваемых дисциплинах.

№ отделения, наименование отделения, наименование факультета - отражает сведенья об отделениях и соответствующих им факультетах.

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

№ аудитории, вместимость - отражает сведенья об аудиториях.

№ пары, начало занятий, конец занятий - отражает сведения о длительности пары.

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

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

Таблица 2.

Информационные объекты и их реквизиты

Информационные объекты	Ключ	Реквизиты
Отделение	*	1. ID отделения 2. Наименование отделения
Факультет	*	1. ID факультета 2. ID отделения 3. Наименование факультета
Курс	*	1. ID курса 2. ID факультета
Группы	*	1. ИД группы 2. ИД 3. ИД дисциплины 4. Код группы 5. № группы 6. Количество студентов
Преподаватель	*	1. ID преподаватель 2. ФИО 3. Кафедра 4. Должность
Дисциплины	*	1. ID дисциплины 2. ID преподаватель 3. Наименование дисциплины
Вид занятий	*	1. ID вида 2. ID дисциплины 3. Вид занятия
Аудитория	*	1. ID аудитории 2. Вместимость
Время	*	1. ID пары 2. Начало занятий 3. Конец занятий
Дата	*	1. ID ДН 2. ДН
Расписание		1. Отделение 2. Факультет 3. ДН 4. Дата 5. Курс 6. Группа 7. Пара 8. Дисциплина 9. Преподаватель Аудитория

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

"Отделение", "Факультет", "Курс", "Группы", "Преподаватель", "Расписание", "Вид занятий", "Аудитория", "Дата", "Время", "Дисциплины".

Следующим этапом разработки будет определение связей между сущностями [13, c.18].

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

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

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

Тип связи один-ко-многим, т.к каждая дисциплина может иметь свой вид. Так же как вид может относиться к любой дисциплине.

Связь между сущностями организована благодаря реквизиту "ID дисциплина".

Тип связи один-к-одному, т. к к сущности "Расписание" относится индивидуальные атрибуты "Аудитория", "Группа", "Время", "ДН"., а так же "Курс", "Преподаватель", "Дисциплина". Связь с сущностями осуществляется с помощью индивидуальных реквизитов.

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

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

CASE система ERWIN предназначена для моделирования и создания баз данных на основе ER - диаграмм "сущность - связь".

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

При построении ER - модели присваивается каждой сущности свое уникальное имя (идентификатор).

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

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

Связь проводится от родительской сущности к сущности потомка. Она изображается в виде линии с точкой на конце (рис.18).

Рис.12. Графическое изображение связи

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

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

Сущности могут иметь также внешние ключи (Foreign Key). Внешний ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK в скобках [8, c.148].

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

Построим логическую модель, основываясь на вышесказанном (рис.13):

Рис.13. Логическая модель данных

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

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

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

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

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

При построении физической модели данных указываются типы данных, которые используются в процессе разработки АС. Приведём указанные типы в таблице 3.

Таблица 3.

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

AutoNumber (счетчик)	используется для автоматической нумерации записей.
Text (текстовый)	произвольная последовательность символов длиной до 255. Используется для текста и чисел, не участвующих в вычислениях.
Byte (числовой)	принимает значения от 0 до 255, не может быть отрицательным.
Long Integer (числовой)	любое число, используется для числовых данных, используемых для проведения расчетов.
Date/Time (дата/время)	используется для дат (в диапазоне лет от 100 до 9999) и времени суток.
Memo (поле MEMO)	специальный тип данных для хранения больших объемов текста (до 65 535 символов), комбинация текста и чисел.
Мастер подстановок	создает поле, в котором предлагается выбор значений из списка, или из поля со списком, содержащего набор постоянных значений или значений из другой таблицы

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

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

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

2.3 Преобразование моделей в реляционную базу данных и технология разработки системы

На основе построенных логической и физической моделях можно приступить к построению схемы реляционной базы данных. Её реализация будет происходит непосредственно в выбранной ранее системе управления базами данных MS Access 2007.

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

1. Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы.

2. Каждый атрибут становится возможным столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут. Если атрибут является множественным, то для него строится отдельное отношение.

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

В результате реляционная база данным будет состоять из 11 таблиц: "Отделение", "Факультет", "Курс", "Группы", "Преподаватель", "Расписание", "Вид занятий", "Аудитория", "Дата", "Время", "Дисциплины".

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

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

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

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

Рис.21. Реляционная модель данных

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

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

Форму можно создать тремя различными способами:

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

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

Вручную в режиме конструктора. Сначала создается базовая форма, которая затем изменяется в соответствии с требованиями в режиме конструктора.

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

Все используемые формы наглядно приведены в приложении 2.

Перечислим все формы в таблице 4:

Таблица 5. Перечень разработанных пользовательских форм АС "Расписание"

Наименование формы	Входные/выходные данные	Назначение
Кнопочная форма		Главная форма для начала работы.
" Преподаватели"	Таблица "Преподаватели"	Работа с данными по преподавателям, возможность добавления, удаления, сохранения преподавательского состава.
"Дисциплины"	Таблица "Дисциплины"	Ввод, поиск, удаление и модификация данных по перечню преподаваемых дисциплин.
"Отделения и факультеты"	Таблицы "Отделения", "Факультеты"	Работа с данными по отделениям, факультетам, ввод, поиск и удаление.
"Группы"	Таблица "Группы"	Работа с данными по группам, удаление и модификация данных.
"Аудитории"	Таблица "Аудитории"	Работа с данными по аудиториям, добавление, удаление.
"Время занятий"	Таблица "Время"	Ввод, удаление и модификация времени занятий
"Расписание"	Таблицы "Отделение", "Факультет", "Курс","ДН", "Группа", "Аудитория", "Время", "Дисциплина", "Преподаватель"	Составление расписания и добавление его в базу данных.
"БД Расписание"	Таблица "Расписание"	Работа с расписанием, возможность просмотра, редактирования.
"Отчёты"		Выдача данных на печать.

Запросы в Microsoft Access можно создать либо автоматически, с помощью мастеров, либо самостоятельно, в окне конструктора запросов. Доработать и оптимизировать инструкцию запроса можно в режиме SQL.

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

Пример формирования запросов представлен в приложении 3.

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

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

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

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

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

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

Цельность и связь между формами осуществляется благодаря использованию макросов. Макрос позволяет добавлять функциональные возможности в формы, отчеты без необходимости написания кода в модуле Visual Basic для приложений (VBA) [23, c.96].

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

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

Выводы по главе 2

В практической главе дипломного проекта осуществляется описание процессов разработки, а так же выбор средства проектирования MS Access.

Он обладает всеми чертами классической СУБД и предоставляет дополнительные возможности. С помощью Access можно создать приложение, работающее в среде Windows и полностью соответствующее нашим потребностям по управлению данными.

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

В данной главе была спроектирована и реализована автоматизированная система "Расписание" средствами Access, следовательно, главная задача решена.

Глава 3. Обоснование экономической эффективности и внедрение автоматизированной системы "Расписание"

3.1 Расчет экономической эффективности разработки и внедрения автоматизированной системы "Расписание"

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

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

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

Экономические оценки внедрения АС:

Эффективность - выполнение требуемых функций при минимальных затратах [19].

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

Срок окупаемости - период времени, в течение которого окупаются затраты.

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

Для расчета экономической эффективности разработки используются следующие основные показатели [19]:

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

годовая экономическая эффективность;

срок окупаемости.

Разрабатываемая АС позволяет снизить трудоемкость и затрачиваемое время на обработку данных. В следствии годовая экономия (рост прибыли) рассчитывается за счет экономии живого труда. А другие показатели эффективности (повышение точности, оперативности расчетов) учитываются на качественном уровне. Экономическая целесообразность разработки АС "Расписание" заключается в экономии трудозатрат по сравнению с ручной обработкой и получении более достоверной информации за более короткое время [40]. В нашем проекте задействованы следующие специалисты: руководитель проекта, специалист по информационному обеспечению (ИО) и проектировщик. Матричная организационная структура демонстрирует принцип организации работы над автоматизированной системой (рис.22).

Рис.22. Организационная структура проектной группы

Рассмотрим календарный план работы над ИС.

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

Этапы жизненного цикла:

Этап работы над проектом составил около трех месяцев.

Этап внедрения ИС составил один месяц.

Этап зрелости: переход к автоматизированной системе - один месяц.

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

Составим календарный график работ над проектом (рис.23).

Рис.23. Календарный график работы над проектом

Подробно опишем данные в таблице: Затраты времени на разработку программы (табл.5).

Таблица 5.

Затрат времени на разработку программы

Наименование этапов	Исполнители	Период (дни)
Предпроектное исследование (анализ предметной области)	Руководитель проекта Специалист по ИО	7
Техническое задание (формулирование требований к программе)	Руководитель проекта Специалист по ИО	9
Разработка и отладка ИС (разработка архитектуры и структуры про граммы, алгоритма, разработка интерфейса пользователя)	Руководитель проекта Специалист по ИО Проектировщик	30
Тестирование (проверка и анализ результатов при реальных возможностях внешней среды)	Руководитель проекта Специалист по ИО Проектировщик	7
Техническая отчетность (оформление программной документации)	Руководитель проекта Специалист по ИО Проектировщик	10
Внедрение системы	Руководитель проекта Специалист по ИО	3

По выше указанным подсчетам срок разработки системы составляет 66 дней (чуть больше 2-х месяцев).

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

Таблица 6.

Затраты на расходные материалы

Наименование материала	Расход, шт.	Цена, руб. /шт.	Сумма, руб.
Флеш - накопитель	1	600	600
Вспомогательная литература	4	90	360
Канцтовары	-	-	200
Итого:	1 160

Расчет заработной платы разработчиков представлен в таблице 7. Учитывая 22-х рабочих дней в месяц.

Таблица 7.

Заработная плата разработчиков

Наименование этапов	Исполнители	Трудоемкость чел. дн.	Дневная з/п, руб.
Предпроектное исследование (анализ предметной области)	Руководитель проекта	1	382,35
	Специалист по ИО	3	492
	Проектировщик	8	236,67
Техническое задание (формулирование требований к программе)	Руководитель проекта	2	382,35
	Специалист по ИО	5	492
Разработка и отладка ИС (разработка архитектуры и структуры про граммы, алгоритма, разработка интерфейса пользователя)	Руководитель проекта	5	382,35
	Специалист по ИО	6	492
	Проектировщик	10	236,67
Тестирование (проверка и анализ результатов при реальных возможностях внешней среды)	Руководитель проекта	2	382,35
	Специалист по ИО	3	492
	Проектировщик	2	236,67
Техническая отчетность (оформление программной документации)	Руководитель проекта	6	382,35
	Специалист по ИО	6	492
	Проектировщик	10	236,67
Внедрение системы	Руководитель проекта	1	382,35
	Специалист по ИО	2	492

Скомпоновав данные, находящиеся в таблице, в результате получаем (табл.8):

Таблица 8

Основная заработная плата разработчиков

Исполнители	Рабочие дни	Дневная з/п, руб	Оклад, руб
Руководитель проекта	17	382,35	6 500
Специалист по ИО	25	492	12 300
Проектировщик	30	236,67	7 100
Итого:	25 900

Проведем расчет заработной платы с учетом отчисления в фонд единого социального налога (ЕСН), он составляет 26% с 01.01.2005 года.

ОЗПЧ0,26 = отчисления в фонд ЕСН

Итоги расчета внесем в таблицу (табл.9).

Таблица 9.

Отчисление в фонд ЕСН

Исполнители	Оклад, руб.	ЕСН	Зарплата
Руководитель проекта	6 500	1 690	8 190
Специалист по ИО	12 300	3 198	15 498
Учебный отдел	7 100	1 846	8 946
Итого:	6 734	32 634

Дополнительная заработная плата разработчиков ИС составляет 20% от основной заработной платы: 25 900 Ч 0,2 = 5 180 руб.

Фонд заработной платы представляет собой сумму основной и дополнительной заработной платы:

?_фзп = 25 900 + 5 180 = 31 080 (руб)

Итак, расходы по оплате труда разработчикам составили 31 080 рублей.

Отчисления на социальные нужды составляют 35% от фонда оплаты труда: 31 080 Ч 0,35= 10 878 (руб)

Накладные расходы составляют 250% от величины от величины основной заработной платы: 25 900 Ч 2,5 = 64 750 (руб)

Прочие расходы состоят из показателей на машинное время (порядка 2 - месяцев на разработку, отладку и тестирование программы: учитывая 8 часовой рабочий день - 576 часов стоимостью 5 руб. /час): 576 Ч 5 = 2 880 (руб)

На основании данных результатов можно составить таблицу: "Калькуляции темы" (табл.10).

Таблица 10.

Калькуляции темы

Наименование статей расходов	Затраты, руб.
Расходные материалы	1 160
Основная заработная плата разработчиков	25 900
Дополнительная заработная плата разработчиков	5 180
Отчисления на социальное страхование	10 878
Накладные расходы	64 750
Прочие расходы	2 880
Итого затрат:	110 748

В итоге мы получаем, расходы по оплате труда разработчикам в сумме:

110 748 рублей.

Рассчитаем общехозяйственные расходы.

Фонд времени, выделяемый на ремонт оборудования:

Ф_{рем. об.} = Ф_дн + Ф_мес

где Ф_дн - дневной фонд времени на ремонт оборудования

Фонд рабочего времени, выделяемый на ежедневные профилактические работы:

Ф_дн=t^см_проф Ч ₍Д_к - Д_в - Д_п),

где

t^см_проф - это количество часов, выделяемых на ежедневные профилактические работы:

Д_к = 62 - дни календарные (2 месяца);

Д_в = 18 - дни выходные;

Д_п = 2 - дни праздничные

Ф_дн = 0,5 Ч (62 - 18 - 2) = 21 (час)

Фонд рабочего времени, выделяемый на месячные профилактические работы:

Ф_мес = t^мес_проф Ч 12,

где

t^мес_проф = 2 часа (количество часов выделенное на ежемесячные профилактические работы)

Ф_мес = 2 Ч 2 = 4 (час)

Действительный фонд времени работы оборудования:

Ф_действ = (Д_к - Д_в - Д_п) Ч t_см Ч С,

где

С = 1 (количество смен)

t_см = 8 (часов в день)

Ф_действ = (62 - 18 - 2) Ч 8 Ч 1 = 336 (час)

Затраты на электроэнергию рассчитывается в основном на потребление энергии компьютером.

Затраты на освещение одного рабочего места:

З_осв= Ц_1КВт Ч N_л Ч N_осв Ч Ф_{действ,}

где

Ц_1КВт/ч = 3,08 (цена 1 КВт/ч в)

N_л = 2 (количество осветительных приборов)

N_осв = 0,06 (мощность одного осветительного прибора)

З_осв=3,08 Ч 2 Ч 0,06 Ч 336 = 124,2 (руб)

Затраты на электроэнергию для монитора:

З_эл^мон = Ц_КВт/ч Ч N_мон Ч Ф_{действ,}

где

N_мон = 0,4 (мощность монитора)

З_эл^мон = 3,08 Ч 0,4 Ч 336 = 414 (руб)

Затраты на электроэнергию системного блока:

З_эл^{сист. бл} = Ц_КВт/ч Ч N_{сист. бл} Ч Ф_{действ,}

где

N_{сист. бл} = 0,3 (мощность системного блока)

З_эл^{сист. бл} = 3,08 Ч 0,3 Ч 336 = 310,5 (руб)

Общая сумма затрат на электроэнергию

?З_эл=З_осв + З_эл^мон + З_эл^{сист. бл}

?З_эл= 124,2 + 414 + 310,5 = 848,7 (руб)

Итак, затраты на электроэнергию составляет сумма в 848,7 рублей

Нельзя не отметить и затраты на услуги интернет - ресурса. Ежемесячная оплата составляет 700 рублей. А так как разработка ИС потребовала 2 месяца, то расходы составили 1400 рублей.

Рассчитаем амортизацию оборудования:

А_об = Цоб Ч Нп. в/об,

Где Н_{п. в/об} = 24% (норма амортизации по оборудованию)

Ц_об = 20 000 руб. (стоимость использованного оборудования)

А_об = 20 000 Ч 0,24= 4 800 (руб)

Полученная сумма в 4 800 рублей - амортизация оборудования в течении года.

А_об1 = А_об/Ч_рд,

где

Ч_рд = 251 (рабочие дни в течении года)

А_об1 = 4 800/ 251 = 19,1 ? 19 (руб) - дневная сумма амортизации.

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

Проведем расчеты по обслуживанию оборудования, они составляют 25% амортизационных отчислений. Получаем 1 254 Ч 0,25 = 313,5 рублей.

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

Таблица 11.

Общие затраты на разработку программы.

Статьи затрат	Числовое значение (руб)
Расходы по оплате труда разработчика программы	32 634
Затраты на расходные материалы	1 160
Затраты на электроэнергию	848,7
Затраты на интернет-трафик	1 400
Затраты на амортизацию оборудования	1 254
Затраты на обслуживание оборудования	313,5
Итого:	37 610,2

Таким образом на разработку проекта потребуется затратить 37 610,2 рубля. Итак, на основании полученных данных рассчитаем экономическую эффективность разработки программного продукта (ПП).

Все наилучшие результаты, показываемый ПП и есть показатель эффекта. Экономический эффект от использования ПП за расчётный период Т определяется по формуле, руб. [40]:

Э_Т = Р_Т - З_Т

где Р_Т - стоимостная оценка результатов применения ПП в течение периода Т, руб.;

З_Т - стоимостная оценка затрат на создание и сопровождение ПП, руб. (используем З_к).

Стоимостная оценка результатов применения ПП за расчётный период Т определяется по формуле:

Т - расчётный период;

Р_t - стоимостная оценка результатов года t расчётного периода, руб.;

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

Дисконтирующая функция имеет вид:

_t = 1/ (1 + p) ^t,

p - коэффициент дисконтирования (p = E_н = 0.2, Е_н - нормативный коэффициент эффективности капитальных вложений).

Таким образом, разработанная нами ИС заменяет ручной труд, следовательно, набор полезных результатов в не меняется. В качестве оценки результатов применения ИС в год берётся разница (экономия) издержек, возникающая в результате использования ИС, т.е. P_t = Э_у.

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

Э_у = З_р - З_а

З_р - затраты на ручную обработку информации, руб.;

З_а - затраты на автоматизированную обработку информации, руб.

Затраты на ручную обработку информации определяются по формуле:

З_р = О_и Ц Г_д / Н_в

О_и - объём информации, обрабатываемой вручную, Мбайт;

Ц - стоимость одного часа работы, руб. /час;

Г_д - коэффициент, учитывающий дополнительные затраты времени на логические операции при ручной обработке информации;

Н_в - норма выработки, Мбайт/час.

В данном случае: О_и = 50 Мбайт (общий размер обрабатываемых данных, вводимых для регистрации за год с последующим подсчетом статистики),

Ц = 450/22/8 2,55 руб. /час,

Г_д = 2,5 (установлен экспериментально),

Н_в = 0,004 Мбайт/час.

Выходит, затраты на ручную обработку информации будут равны:

З_р =50 2,55 2,5/0,004 = 79 687,5 руб.

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

З_а = t_a Ц_м + t_о (Ц_м + Ц_о)

t_a - время автоматической обработки, ч.;

Ц_м - стоимость одного часа машинного времени, руб. /час;

t_о - время работы оператора, ч.;

Ц_о - стоимость одного часа работы оператора, руб. /час.

Для нашей автоматизированной системы "Расписание":

t_a = 18 ч.,

Ц_м = 2 руб.,

t_о = 83,3 ч.,

Ц_о = 450/22/8 2,55 руб.

(Для ввода данных оператором в систему понадобится: (1000 случаев) * (5мин. регистрации 1 случая) = 5000 мин. = 83.3 часа; Для автоматической обработки введенных данных, если получать по 10 отчетов в неделю (время получения одного отчета 2 мин) понадобится 1080 мин. = 18 часов в год).

Следовательно, затраты на автоматизированную обработку информации будут равны:

З_а = 18 2 + 83,3 (2 + 2,55) = 415,02 руб.

Таким образом, годовая экономия от внедрения АС равна:

Э_у = 79 687,5 - 415,02 = 79 272,48 руб.

Экономический эффект от использования ИС за год определяется по формуле, руб.:

Э_г = Э_у - Е_н З_к.

Э_г = 79 272,48 - 0.2 37 610,2 71 750,44 руб.

Эффективность разработки может быть оценена по формуле:

Э_р = Э_г 0.4/З_к.

Э_р = 71 750,44 0.4/37 610,2 0.76

Поскольку Э_р > 0.20, разработка АС "Расписание" является экономически целесообразной.

Осуществим стоимостную оценку результатов применения АС (экономия) за расчётный период T = 3 года (при условии отсутствия вносимых в программу доработок и изменений):

Экономический эффект от использования АС за расчётный период T = 5 лет составит:

Э_Т = 200 383.18 - 37 610,2 = 162 772,98 руб.

Таким образом, поставленная задача доказательство экономической эффективности разработанной АС полностью подтвердилось.

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

Затраты на разработку, полученные методом калькуляции, составляют 37 610,2 руб.

Экономический эффект от использования данного ПП за расчётный период (3 года) составит 162 772,98 руб.

Следовательно, можно сделать вывод, что полученные показатели дают достаточно оснований для внедрения АС "Расписание" в учебный отдел ЕФ МГГУ им. М.А. Шолохова.

3.2 Анализ внедрения автоматизированной системы "Расписание"

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

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

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

Следует выделить три этапа внедрения информационной системы:

Исследование. Изначально проводится исследование предметной области и бизнес процессов.

Доработка системы. Программисты настраивают или дорабатывают требуемую функциональность системы.

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

На этапе исследования бизнес процессов отводится определённое время. Здесь необходимо как можно более точно описать, какие процессы необходимо улучшить.

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

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

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

На этапе доработки системы целесообразно контролировать процесс реализации требуемых функций в информационной системе. Разумно, чтобы со стороны заказчика выступал человек, хорошо знакомый с задачами компании и её бизнес процессами.

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

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

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

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

Процесс внедрения информационной системы занимает как минимум несколько месяцев. На протяжении этого времени важно фокусироваться на целях, которые компания хочет достигнуть, внедряя систему. Логично помнить о возможных рисках и финансовых издержках [38].

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

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

В целом, создание и внедрение автоматизированной системы "Расписание" в учебный отдел ВУЗа обеспечит эффективное решение следующих управленческих задач:

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

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

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

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

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

автоматизировать процесс формирования отчетности и формировать оперативные отчеты.

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

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

о факультетах;

об отделениях;

о преподавателях;

о группах;

о дисциплинах;

об аудиториях.

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

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

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

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

Для успешной работы с автоматизированной системой "Расписание" необходимо иметь в распоряжении следующие устройства.

Системные требования:

операционная система: Windows 2000, Windows XP, Windows 2003, Vista, Windows 7 и пакетом программ MS Office;

процессор: Pentium 800 МГц;

оперативная память: не менее 512 Мб;

свободное место на жёстком диске: не менее 200 Мб;

манипулятор типа "мышь";

CD (DVD) - привод;

принтер.

Успешно прошла испытания и готова к эксплуатации автоматизированная система "Расписание".

Выводы по главе 3

В данной главе был произведён расчет экономической эффективности автоматизированной системы "Расписание" и анализ ее внедрения.

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

Следовательно, последнюю задачу, поставленную в дипломе, можно считать успешно разрешенной.

Заключение

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

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