Ирина Эланс

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

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

Зарегистрировано «___»_____20___г.

________ __________________________

Подпись (расшифровка подписи)

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

БЕЛГОРОДСКИЙ ГОСУДАРСТВЕННЫЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

(НИУ «БелГУ»)

ФАКУЛЬТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И ПРИКЛАДНОЙ МАТЕМАТИКИ

КАФЕДРА ПРИКЛАДНОЙ МАТЕМАТИКИ ИНФОРМАТИКИ

АВТОМАТИЗИРОВАННАЯ СИСТЕМА

МОНИТОРИНГА ОСНАЩЕННОСТИ ОБРАЗОВАТЕЛЬНЫХ УЧРЕЖДЕНИЙ КОМПЬЮТЕРНОЙ ТЕХНИКОЙ

Курсовая работа

студентки дневного отделения 4 курса группы 83001004

Лисицыной Юлии Дмитриевны

Научный руководитель:

кандидат технических наук,

доцент Гахов Р.П.

БЕЛГОРОД 2013

Содержание

Введение

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

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

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

В данном курсовом проекте была поставлена цель: разработать автоматизированную систему мониторинга оснащенности образовательных учреждений компьютерной техникой. Для ее проектирования использовались такие программные средства как AllFusion Process Modeler r7 и AllFusion ERwin Data Modeler r7.

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

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

К задачам курсовой работы можно отнести следующее:

изучение предметной области;
разработка функциональных моделей;
разработка базы данных в СУБД Firebird;
создание приложения, основанного на клиент-серверной технологии;

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

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

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

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

Курсовая работа написана на 58 страницах печатного текста. Из них 41 страница – основной текст курсовой работы, 17 страниц содержит код программы и базы данных, который вынесен в приложение. Курсовая работа содержит 29 рисунков.

Теоретические сведения

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

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

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

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

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

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

1.2 Используемые при проектировании программные средства

Рассмотрим подробнее используемые нами программные средства:

CASE средство ERwin – средство разработки структуры базы данных (БД). ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных. С помощью ERwin можно создавать или проводить обратное проектирование (реинжениринг) баз данных.

Семейство продуктов ERwin представляет собой набор средств концептуального моделирования данных, использующих метод IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (Oracle, Informix, Sybase, DB2, Microsoft SQL Server и др.) и реверсный инжиниринг существующей БД. Выпускается в нескольких конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Интегрируется с популярными средствами разработки клиентской части приложений PowerBuilder, Visual Basic, Delphi, что позволяет автоматически генерировать код приложений.

CASE средство Process Modeler r7 является мощным инструментом для создания моделей, позволяющих анализировать, документировать и планировать изменения бизнес-процессов. Process Modeler r7 предлагает средство для сбора всей необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели. Целостность и непротиворечивость модели-рисунка гарантируются рядом методологий и нотаций. Process Modeler r7 поддерживает три таких методологии: IDEF0, IDEF3 и DFD [5].

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

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

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

Сценарием называется описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса. Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса и документов, отображающих ход его выполнения [1].

Методология DFD (DFD - Data Flow Diagrams) или диаграмм потоков данных это методология описания системы позволяющая отражать такие характеристики, как движение объектов (потоки данных), хранение объектов (хранилища данных), источники и потребители объектов (внешние сущности).

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

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

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

Используемые инструментальные средства для создания Windows-приложения

Для разработки используются программные средства Borland C++ Builder6, СУБД Firebird и утилита IBExpert.

FireВird — это СУБД, основанная на ядре Borland InterBase. Она предназначена для хранения и обработки больших объемов информации, в условиях работы нескольких пользователей. Для управления базой данных сервер FireВird использует домены, просмотры, хранимые процедуры, триггеры, генераторы, транзакции, а также пользовательские функции. Для работы с FireBird используют утилиту IBExpert, которая позволяет не только полностью управлять структурами баз данных, но также создавать механизмы управления базой данных и отлаживать их [2].

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

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

С++ Builder 6 не является системой управления базами данных (СУБД), строго ориентированной на разработку приложений для работы с ними. Тем не менее её возможности практически ни в чём не уступают возможностям таких СУБД, как Visual FoxPro или Access. Она позволяет создавать приложения с помощью инструментальных программных средств, визуально подготавливать, а также непосредственно писать SQL-запросы к базам данных. С её помощью можно создавать приложения для работы с локальными и удалёнными базами данных.

Несмотря на относительную простоту построения приложений в среде C++ Builder, имеются определённые трудности в правильном использовании свойств и методов компонентов системы [1].

2. Разработка технического задания к программе

2.1 Основание для разработки

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

2.2 Назначение разработки

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

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

2.3 Требования к программе

2.3.1 Требования к функциональным характеристикам и надежности

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

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

код образовательного учреждения;

наименование;
адрес;
город.

Ввод, вывод, редактирование, хранение, просмотр информации о графике проверок:

код проверки;
код образовательного учреждения;
дата.

Ввод, вывод, редактирование, хранение, просмотр информации о результатах проверок:

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

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

код сотрудника;
ФИО;
должность;
город.

Ввод, вывод, редактирование, хранение, просмотр информации о потребности в компьютерной технике:

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

Ввод, вывод, редактирование, хранение, просмотр информации об ответственных лицах:

код ответственного лица;
код образовательного учреждения;
ФИО;
должность.

Ввод, вывод, редактирование, хранение, просмотр информации о оснащенности:

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

Ввод, вывод, редактирование, хранение, просмотр информации о компьютерной технике:

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

Ввод, вывод, редактирование, хранение, просмотр информации о программном обеспечении:

код программного обеспечения;
дата установки;
ОС;
дата истечения лицензии;
№ лицензии.

Ввод, вывод, редактирование, хранение, просмотр информации о виде компьютерной техники:

код вида;
наименование;

2.3.2 Условия эксплуатации

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

2.3.3 Требования к составу и параметрам технических средств

Для работы программы должен быть выделен ответственный оператор.

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

оперативную память объемом не менее 64 Мб;
не менее 100 Мб свободного пространства на жестком диске;
операционную систему Windows ХР и выше;
видеокарта 64Мb;
клавиатура и мышь.

2.3.4 Требования к информационной и программной совместимости

Система должна работать под управлением ОС семейства Windows Windows XP, Vista, 7. Для работы приложения клиенту необходимы: СУБД Firebird и IBExpert.

2.4 Требования к маркировке и упаковке

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

2.5 Требования к транспортированию и хранению

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

2.6 Требования к программной документации

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

1.Программные документы:

Спецификация (ГОСТ 19.202-78);
Текст программы (ГОСТ 19.401-78);
Описание программы (ГОСТ 19.402-78);
Пояснительная записка (ГОСТ 19.404-79);

2.Эксплуатационные документы:

Ведомость эксплуатационных документов (ГОСТ 19.507-79);
Описание применения (ГОСТ 19.502-78);
Руководство программиста (ГОСТ 19.504-79);

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

2.7 Технико-экономические показатели

Данное программное обеспечение требует постоянного контроля за работой: необходим человек, следящий за правильностью использования и эксплуатирования - администратор. Основные экономические затраты необходимы на закупку и установку специальных средств для работы с этим программным обеспечением: СУБД Firebird и C++ Builder. Программное обеспечение позволяет упразднить работу, так как обслуживающему персоналу открывается доступ ко всей информации в электронном виде, что исключает бумажные рутинные работы, экономит время и увеличивает скорость и производительность работы.

2.8 Стадии и этапы разработки

Общая продолжительность разработки и внедрения системы составляет 4 месяца. График реализации проекта представлен в таблице 1.

Таблица 1 – График реализации проекта

	Сентябрь	Октябрь	Ноябрь	Декабрь
Функциональное моделирование IDEF0, IDEF3
Моделирование потоков данных
Информационное моделирование
Разработка объектной модели
Проектирование базы данных
Разработать бизнес-логику
Разработать программное обеспечение

2.9 Порядок контроля и приемки

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

3. Разработка функциональных моделей автоматизированной системы

Инструментом, который мы будем использовать для построения моделей, выберем AllFusion Process Modeler r7 [3].

В данной курсовой работе на основе нотации IDEF0 была разработана контекстная диаграмма, которая показывает входные и выходные ресурсы, правила управления и механизм управления (Рисунок 1).

Рисунок 1 - Контекстная диаграмма системы (IDEF0)

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

(Рисунок 2):

«Ведение справочника компьютерной техники»;
«Ведение журнала оснащенности»;
«Регистрация ответственного лица»;
«Составление графика проверок»;
«Проведение проверки образовательных учреждений»

Рисунок 2 - Диаграмма декомпозиции контекстной диаграммы (IDEF0)

Далее декомпозирую сущность «Регистрация ответственного лица» на три действия (Рисунок 3):

«Заполнение личных данных»;
«Указание образовательного учреждения»;
«Вывод ответственных лиц».

Рисунок 3 - Декомпозиция функционального блока «Регистрация ответственного лица» (IDEF0)

Декомпозируем функциональный блок «Ведение журнала оснащенности» на три действия (Рисунок 4):

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

Рисунок 4 - Декомпозиция функционального блока «Ведение журнала оснащенности» (IDEF0)

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

Декомпозируем функциональный блок «Составление графика проверок» на восемь действий (Рисунок 5):

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

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

Автоматизированная система мониторинга оснащенности образовательных учреждений компьютерной техникой 📙 Курсовая → 🆔 2335