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

 

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

 

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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)