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

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

Глава 3. Постановка задачи проектирования

1.5Выделение «узких мест» и описание процесса создания системы

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

Проанализировав модель можно выделить следующие «узкие места»:

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

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

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

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

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

Данная система будет:

1. Внешней. Данные будут использоваться не только для внутреннего учета и сверки с «Горторгом», но так же для просмотра отчетов родителями;

2. загружать документы от банка, содержащие информацию об оплате;

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

4. прозрачной для родителей и учеников;

5. автоматически составлять ежедневные отчеты о суммах задолженностей;

6. составлять автоматически итоговые отчеты для «Горторга» и отчеты по транзакциям для «Родителей».

Система не будет:

1. вести учет питающихся в буфете, а так же на бесплатной основе;

2. использовать данные наличного расчета за питание;

3. предоставлять выбор меню (это делают работники столовой).

Система будет использовать следующие входные документы:

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

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

Документы на выходе:

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

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

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

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

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

Система разрабатывается в целях:

1. повышения оперативности в обработке документов;

2. отказ от бумажной формы ведения учета;

3. повышения качества (полноты, точности, достоверности, своевременности, согласованности) информации;

4. упрощения поступления денежных средств;

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

Основные функции АС:

1. добавление, изменение, блокирование, удаление записей по запросу пользователя;

2. создание отчетов;

3. предоставление доступа к функционалу авторизированному пользователю;

4. создание полных копий всей базы;

5. произведение полного или частичного восстановления данных с резервной копии;

6. обеспечение непрерывности функционирования.

К квалификации и режиму работы персонала эксплуатирующего АС предъявляются следующие требования:

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

2. администратор СУОП - знания методологии проектирования хранилищ данных, знание СУБД, знание языка запросов SQL, опыт администрирования СУБД, знания и навыки операций архивирования и восстановления данных, знание процесса установки и настройки Web-сервера и т.д., свободный рабочий график.

Система должна эксплуатироваться на уже имеющемся в Лицее аппаратно-техническом комплексе.

Таблица 3 – Перечень функций, подлежащих автоматизации

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

Создание прототипов – это важный этап разработки АИС. К прототипам, завершающим процесс формулировки требований, относятся модели TO-BE. Данная модель представлена на рисунке 5 в нотации IDEF3.

Описание данной модели представлено в Приложении Е.

Допущения и ограничения

Допущения:

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

2. критически важный персонал не покинет Лицей;

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

Ограничения

• Окружение проекта

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

1. изменениями в договоре с банком;

2. организационной структурой Лицея;

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

4. государственными стандартами и законодательством;

5. существующими процедурами управления персоналом;

6. существующими человеческими ресурсами (навыки, знания, специализации).

• Технологии

Для реализации подсистемы хранения данных должна использоваться СУБД MySQL.

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

Для стадии «Проектирования» должны быть использованы методологии ARIS, IDEF1x, IDEF3.

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

• Временные ресурсы

Проект не должен выполняться более 5 месяцев.

• Денежные ресурсы

На разработку проекта не должно быть потрачено более 76 тыс. р.

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

Прямые пользователи:

1. ответственный за питание;

2. администратор системы.

Косвенные пользователи:

1. родители;

2. «Горторг»;

3. банк.

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

Рисунок 5 – Модель TO-BE в нотации IDEF3

На диаграмме вариантов использования Use Case (рисунок 6) наглядно представлено, как происходит взаимодействие всех пользователей в системе.

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

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

Рисунок 6 – Взаимодействие пользователей в системе

Из плана проекта видно, что длительность проекта составит 103 дня, а затрачено на него будет 62161,67 руб.

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

Таблица 4 – Затраты на техническое и программное обеспечение

Наименование затрат на программные средства	Сумма затрат
Затраты на предпроектное обследование	6294,17 р.
Затраты на составление технического задания	8730 р.
Затраты на покупку программных средств	19000 р.
Затраты на установку и настройку программных средств	7000 р.
Затраты на аттестацию рабочего места	6000 р.
Итого	47024,17 р.

Таблица 5 – Изменение некоторых показателей после разработки и тестирования системы

Показатель	До внедрения АИС	После внедрения АИС
Примерная з/пл сотрудника в час	57,6 р.	57,6 р.
Время на обработку одного класса	0,66 часа или 40 минут	0,2 часа или 12 минут
Количество дней работы в месяц	26	26
Количество обрабатываемых классов в день	25	25
Итого	24710,4 р.	7410 р.
Потери денег за питание в месяц	600	0

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

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

Рассмотрим логическую и физическую модели данных на рисунках 7 и 8.

Рисунок 7 – Логическая модель

Рисунок 8 – Физическая модель

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

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

Визуальное представление интерфейса продемонстрировано в Приложении И.