Текст диплома в PDF - Иркутский государственный университет

Федеральное агентство железнодорожного транспорта
ГОУ ВПО
Иркутский государственный университет путей сообщения
к защите допускаю
зав. кафедрой ИС
__________Ермаков А.А.
«__»________2005 г.
РЕИНЖИНИРИНГ ПОДСИСТЕМЫ АБИТУРИЕНТ ДЛЯ ИРГУПС
Пояснительная записка к дипломному проекту
ДП ИС 017900 ПЗ
Содержание
Введение .................................................................................................................................................3
1. Анализ предметной области и постановка задачи...........................................................................4
1.1. Краткое описание единой информационной системы.............................................................4
1.2. Цели и задачи подсистемы «Абитуриент»................................................................................5
1.3. Обзор аналогов подсистемы «Абитуриент» (плюсы, минусы)...............................................8
1.4. Реинжиниринг............................................................................................................................15
1.5. Необходимые изменения в подсистеме «Абитуриент» и постановка
задачи в
...................................................................................................................................17
2. Разработка и описание структуры подсистемы «Абитуриент» .................................................21
2.1. Разработка структуры подсистемы «Абитуриент»................................................................21
2.2. Описание подсистемы «Оператор ПК»...................................................................................22
2.3. Описание подсистемы «Секретарь ПК» .................................................................................25
2.4. Описание подсистемы «Оператор по договорам»..................................................................28
2.5. Описание подсистемы «Общий доступ».................................................................................29
2.6. Разработка структуры базы данных........................................................................................31
3. Программная реализация.................................................................................................................40
3.1. Разработка физической структуры подсистемы «Абитуриент»...........................................40
3.2. Выбор языков программирования ...........................................................................................41
3.3. Описание используемых алгоритмов.......................................................................................45
4. Экономическая часть........................................................................................................................49
5. Безопасность и экологичность проекта .........................................................................................58
Заключение............................................................................................................................................69
Приложение А
Приложение Б
Приложение В
Приложение Г
Приложение Д
Приложение Е
Список литературы
Введение
В эру глобальной информатизации, когда каждая организация имеет
собственную систему автоматизации рабочего процесса, особенно актуально
встает
проблема
реинжиниринга.
компьютеризации,
программное
В
последние
совершенствуются
обеспечение.
Как
годы
растут
информационные
следствие
темпы
технологий
и
системы
на
информационные
предприятиях быстро устаревают, перестают удовлетворять возрастающим
требованиям и требуют существенной модернизации либо полного пересмотра
бизнес-процессов
и
концепции
построения
информационной
системы
–
реинжиниринга.
В последние годы в нашем университете ведется работа по разработке и
внедрению единой информационной системы (ЕИС). Это
просто жизненно
необходимо для обеспечения согласованной работы всех отделов нашего вуза.
Раньше каждый из отделов имел свою собственную информационную систему,
некоторые из которых в свою очередь по ряду причин просто не имели
возможности взаимодействовать не только с ИС других, но и смежных отделов, а
при переносе информации возникали случаи ее утраты или отсутствовала
возможность переноса данных. Использование ЕИС позволяет устранить эти и
ряд других недостатков. В рамках данного проекта и производились работы по
интеграции подсистемы «Абитуриент» в ЕИС. Система «Абитуриент» была
полностью реализована на базе технологий 1С. Для связи ее с единой базой
данных, которая находилась на Oracle, были реализованы соответствующие
модули. Также был реализован web-интерфейс для оперативного формирования и
представления различных статистик и сводок, как для общего просмотра, так и
для высшего руководства университета. Но в ходе эксплуатации система
показала, что сама технология, на которой она была реализована, устарела и
дальнейшее ее сопровождение и модернизация не имеют смысла.
Было принято решение начать работы по реинжинирингу подсистемы
«Абитуриент».
1. Анализ предметной области и постановка задачи
1.1. Краткое описание единой информационной системы
Вуз состоит из множества согласующихся между собой отделов, каждый
из которых
ежедневно обрабатывает огромное количество информации,
естественно это просто не возможно себе представить без полной или
частичной компьютеризации рабочего процесса. Каждый отдел выполняет
строго определенный круг задач
и имеет собственную информационную
систему (ИС) приложение А, например:
В деканате используется ИС «Деканат».
Задачи деканата сводятся к ведению личных дел студентов, подготовка,
печать и проведение соответствующих приказов, контроль успеваемости
студентов. Часть рабочего процесса ИС «Деканат» выполняет полностью
автоматически, часть приходится делать вручную, но система постоянно
совершенствуется, документооборот автоматизируется, облегчая тем самым
труд секретарей деканатов.
Приемная комиссия использует ИС «Абитуриент».
Основной задачей приемной комиссии
является прием документов от
абитуриентов, организация и проведение вступительных испытаний. ИС
«Абитуриент» призвана максимально упростить рабочий процесс операторов
приемной комиссии, то, что раньше делалось часами, теперь выполняется в
считанные
минуты,
повышается
качество
и
скорость
обслуживания
абитуриентов. Все эти системы хоть и являются вполне самостоятельными
программными продуктами, все же входят в состав единой информационной
системы, их взаимодействие является одной из составляющих результативной
работы вуза в целом. Для обеспечения их продуктивного взаимодействия и
предназначена единая информационная система, ее сущность составляют:
единая база данных, алгоритмы обеспечения целостности и сохранности данных,
стандарты хранения данных.
1.2. Цели и задачи подсистемы «Абитуриент»
Целью подсистемы
«Абитуриент» является повышение качества
обслуживания абитуриентов, усовершенствования механизма подачи заявлений,
снижение нагрузки и трудозатрат операторов приемной комиссии, тем самым,
снижая вероятность появления ошибок при работе с системой. Так же
необходимо привести документооборот к единому стандарту, чтобы обеспечить
взаимодействие с другими подсистемами и, что не маловажно, необходимо
создание единой базы согласованной с филиалами нашего вуза.
Спектр задач приемной комиссии, несмотря на кажущуюся узкую
специализацию, очень широк, и предпочтительней сгруппировать их
по
следующим критериям: прием документов, проведение экзаменов и зачисление.
а) Прием документов.
1.
Необходимо обеспечить абитуриента всей необходимой
информации по выбранной специальности, такой как рабочий план,
конкурс да данную специальность, список специальностей, на
которые он тоже может подать документы, стоимость коммерческого
обучения, расписание экзаменов.
2.
Заполнение
и
дальнейшее
ведение
личных
карточек
абитуриента.
Заполнение
личной
карточки
может
осуществляться
2
способами.
- Заполнение личной карточки самим абитуриентом через
Интернет, при этом абитуриенту присваивается и сообщается
уникальный номер, с которым он может прийти к оператору
приемной комиссии и при проверке на достоверность
внесенных данных анкета активируется в системе, что
значительно ускоряет работу оператора.
- Заполнение личной карточки производится
операторами
приемной комиссии, либо оператором по договорам, в этом
случае алгоритм заполнения карточки аналогичен первому
способу.
Для
обеспечения
ввода
корректной
и
необходимой
информации в системе должен быть предусмотрен ряд фильтров и
алгоритмов блокировки, которые не должны позволять активировать
анкету, пока данные не будут соответствовать требуемым стандартам,
при этом необходимо предусмотреть подсказки, указывающие на
поле, которое не корректно заполнено или не заполнено вовсе.
3.
Формирование и печать необходимого пакета документов.
При активации анкеты в системе должны формироваться
следующие документы:
 Расписка о приеме документов.
 Временный пропуск.
 Заявление от абитуриента.
 Экзаменационный лист.
 Расписание экзаменов.
4.
Перевод абитуриента на другую специальность.
В данном случае в анкете будет ставиться галочка о том, что
абитуриент забрал документы с данной специальности и анкета будет
активироваться на той специальности, на которую он подает
документы вновь. Но данная операция будет доступна лишь до
проведения
вступительных испытаний, с началом вступительных
испытание абитуриента могут перевести только с разрешения
ответственного секретаря приемной комиссии.
5.
Динамическое формирование статистики подачи заявлений.
Динамическое формирование позволяет в реальном времени
получать данные о конкурсе на ту или иную специальность.
6.
Печать журнала регистрации.
Печать журнала должна осуществляется в конце рабочего дня
оператором приемной комиссии.
б) Проведение экзаменов.
1. Обеспечение
абитуриента
информацией
о
расписании
консультаций и экзаменов.
2. Формирование и печать необходимого пакета документов для
сдачи экзаменов.
3. Занесение и ведение экзаменационных оценок абитуриента.
Должен формироваться список экзаменующихся абитуриентов
для соответствующих специальностей, предмета и потока, где
каждому абитуриенту будет проставляться полученная им оценка. В
случае некорректного ввода оценки,
либо ее изменения после
апелляции предусмотрено два режима редактирования. Первый
режим - это полный вывод списка абитуриентов сдававших данный
экзамен с возможностью его редактирования. Второй режим - это
поиск конкретного абитуриента с последующим формированием
полного
списка
сдаваемых
экзаменов
с
возможностью
редактирования.
4. Перевод абитуриента на другую специальность (после проведения
экзаменов).
Алгоритм операции аналогичен ранее описанному алгоритму.
5. Формирование и печать экзаменационной ведомости.
Предусматривается формирование и печать экзаменационная
ведомость, в которой содержатся минимальные первичные данные –
это название специальности, предмет, поток, шифр абитуриента и
порядковый номер абитуриента.
6. Формирование и печать отчетной документации.
Система
должна
формировать
и
производить
печать
результатов экзаменов.
в) Проведение зачисления.
Предусматривается
формирование
списка
абитуриентов
рекомендуемых к зачислению, по результатам вступительных испытаний,
в дальнейшем при формировании приказа на зачисление в приказ будут
добавляться
абитуриенты
из
списка
рекомендуемых.
Список
рекомендуемых
абитуриентов
должен
формироваться
секретарем
приемной комиссии.
г) Необходимые вспомогательные функции.
К необходимым вспомогательным функциям относятся заполнение
и
редактирование
необходимых
справочников,
заполнение
и
редактирование расписания экзаменов.
1.3. Обзор аналогов подсистемы «Абитуриент» (плюсы, минусы)
Чтобы определиться с тем, какой должна быть новая система был
произведен анализ ряда аналогичных разработок по области и стране в целом.
Разработка Иркутского государственного университета путей сообщения
ИС «Абитуриент» на основе 1С – технологии.
Общие сведения.
Разработка и сопровождение подсистемы «Абитуриент»
лабораторией
АСУ велись на протяжении нескольких лет. Система целиком и полностью
базировалась на технологии 1С, но впоследствии была переработана и уже
представляла собой комплекс из трех частей:
1.Клиентская часть 1С – технология.
2.Серверная часть СУБД Oracle.
3.Независимая часть WEB – технология.
это значительно расширило ее технические характеристики.
Программная среда разработки.
Клиентская часть реализована с помощью 1С – технологии средствами
встроенного языка программирования и устанавливается на платформу под
управлением ОС семейства Windows. Серверная часть находится под
управлением СУБД Oracle, устанавливается на платформу под управлением ОС
семейства Linux. Независимая часть реализована на WEB – технологии под
управлением Web – сервера Apache с поддержкой PHP и HTML, работает на
платформе под управлением ОС семейства Linux.
Аппаратная часть.
Сервер не ниже Pentium III, с объемом оперативной памяти не меньше 256
Мб и объемом дискового пространства не менее 20 Гб. Клиент не ниже Pentium
II, с объемом оперативной памяти не меньше 64 Мб, 8Мб видео карта и
объемом дискового пространства не менее 5 Гб.
Краткий обзор системы.
Система реализована по классической схеме «Клиент – Сервер».
Надежность хранения информации обеспечивает фактическое дублирование
данных, так как 1С работала только с MS SQL сервером, были разработаны
специальные модули для связи ее с Oracle, которые обеспечивали обмен
информацией с единой базой данных. Независимый модуль, реализованный на
WEB – технологии, обеспечивал динамическое отображение необходимой
информации, в частности статистику подачи заявлений, ведомости по оценкам,
результаты экзаменов. В ходе эксплуатации система хорошие результаты
работы, но клиентская часть нуждается в существенной доработке.
Разработка Забайкальского института инженеров железнодорожного
транспорта.
ИС «Абитуриент» на основе Web – технологии.
Общие сведения.
Система «Абитуриент» разработана в ЦИТе ЗабИЖТа и полностью
базируется на Web-технологии.
Программная среда разработки.
Клиентская часть отсутствует как таковая, так как все ее функции
выполняет браузер, вследствие чего, система не привязана к какой-либо
конкретной платформе. В качестве Web – сервера используется Apache с
поддержкой языка Perl и HTML, работает на платформе под управлением ОС
семейства Linux.
Аппаратная часть.
Сервер не ниже Pentium III, с объемом оперативной памяти не меньше 256
Мб и объемом дискового пространства не менее 20 Гб. Клиент не ниже Pentium
II, с объемом оперативной памяти не меньше 64 Мб, 8Мб видео карта и
объемом дискового пространства не менее 5 Гб.
Краткий обзор системы.
Система
имеет
хороший
потенциал
и
полностью
проработанный
пользовательский интерфейс, также следует отметить то, что система может
формировать и печатать весь необходимый пакет документов (от заявления
абитуриента до необходимой отчетной документации для высшего руководства).
Однако, не смотря на все плюсы, система имеет ряд существенных недостатков,
в частности система аутентификации была реализована внутренними скриптами,
где четко прописывался пароль и логин, что существенно снижало ее
защищенность, также не был реализован многопользовательский интерфейс.
В целом же система удовлетворяет всем потребностям приемной комиссии
и успешно эксплуатировалась на протяжении 4 лет в ЗабИЖТе, к сожалению,
для более крупного вуза, без дополнительной модернизации, она мало
пригодна.
Разработка Кемеровского государственного университета.
Программная среда разработки.
Подсистема "Приемная комиссия" сформирована путем интеграции трех
программных сред: Oracle 7 Server - хранение и обработка данных, Visual Basic
5.0 - интерфейс пользователя для ввода, просмотра и корректировки
информации, хранящейся на сервере баз данных, MS Excel + VBA формирование и печать сводок, ведомостей и других документов [14].
Программно-аппаратные требования.
Программная часть подсистемы "Приемная комиссия" делится на две
части: серверная и клиентская. Сервером для подсистемы является Oracle 7
Server, работающий на платформе не ниже Pentium-200 /64 Mb RAM / 6Gb HDD,
операционная система Unix. Для работы клиентской части необходимы
персональные ЭВМ в конфигурации не ниже 486 DX4-100, 8 Mb RAM, HDD,
операционная система Windows 9x/NT.
Рисунок 1.1 Логическая структура ПО
Краткий обзор системы.
Система имеет классическую архитектуру «Клиент – Сервер», на
серверной стороне для обработки и хранения данных используется СУБД Oracle,
клиентская часть системы написана на Visual Basic а для формировании отчетов
и других документов используется
особенностью
содержащего
данной
серии
системы
и
номера
MS Excel + VBA . Отличительной
является
использование
недействительных
справочника,
аттестатов,
которые
министерство образования РФ ежегодно доводит до сведения руководителей
органов образования. Эти данные ежегодно накапливаются в системе, для этого
предусмотрен ввод номеров аттестатов как единичных, так и диапазона. После
ввода всех данных система проверяет номер и серию аттестата о среднем
образовании
на
соответствие
недействительным
аттестатам.
В
случае
совпадения выдается предупреждающее сообщение. Во всех сомнительных
случаях вопрос о допуске абитуриента к вступительным испытаниям решается
на заседании приемной комиссии КемГУ. К недостаткам системы можно
отнести то, что не предусмотрена возможность хранения фотографий, система
не
рассчитана
на
многопользовательский
интерфейс,
нет
никакого
разграничения в доступе, следовательно, ни о какой политике безопасности
говорить не приходится. В целом же система удовлетворяет всем требованием,
которые предъявляет приемная комиссия и может использоваться в рамках ВУЗа
с небольшим контингентом студентов, в боле крупных ВУЗах данная система
для эксплуатации не подходит.
Разработка Московского государственного университета.
Программная среда разработки.
При разработке системы использовались СУБД Oracle, http сервер Apache
с поддержкой языка web-программирования Perl, HTML, OC Linux
с
поддержкой Tcl/Tk-приложений, язык структурированных запросов SQL.
Программно-аппаратная часть.
Программная часть делится на две части: серверная и клиентская.
Серверная часть системы работает под управлением СУБД Oracle, работающей
на платформе не ниже Pentium III /256 Mb RAM / 6Gb HDD, операционная
система Linux. Для работы клиентской части необходимы персональные ЭВМ в
конфигурации не ниже Pentium II/64Mb , 8 Mb RAM, HDD, операционная
система Linux [11].
Краткий обзор системы.
Построение информационной системы основано на применении Интернет
технологий. Web-браузеры, поддерживающие распределенные гипертекстовые
структуры, предоставляют удобный и легко осваиваемый интерфейс. Базовый
язык
разработки
web-страниц
HTML
в
совокупности
с
протоколом
взаимодействия web-сервера и web-клиента HTTPS обеспечивают, в частности,
возможности заполнения форм на стороне клиента и безопасной передачи
заполненных форм серверу. В большей части интерфейса информационной
системы реализована возможность доступа к информации, хранящейся в базе
данных через интерфейс WWW. Это было достигнуто путем использования CGIскриптов, написанных на языке Perl, на стороне web-сервера. В остальной части,
где представилось невозможным использование языка HTML из-за его
нединамичности, а также недостатка в нем графических форм и объектов,
которые
бы
позволяли
пользователям
быстро
и
эффективно
вносить
информацию, используются Tcl/Tk-приложения, выполняемые на стороне
клиента, но в свою очередь это ограничивает использование системы, так как
эти приложения поддерживаются только ОС Linux. Структура базы данных
реализована в виде реляционных таблиц на языке SQL/SQL*Plus под
управлением СУБД Oracle. Реляционная модель на данный момент является
наиболее распространенной моделью данных. Система защиты данных
информационной системы от несанкционированного доступа включает в себя
три уровня:
 на уровне операционной системы;
 на уровне приложения;
 на уровне базы данных.
Для восстановления данных в случае их утери в информационной системе
организован процесс резервного копирования. С его помощью вся информация,
находящаяся в базе данных, периодически архивируется и копируется на
резервный
компьютер.
Интерфейс
информационной
системы
приемной
комиссии состоит из отдельных, перекрывающих друг друга окон. В каждом из
окон оператор выполняет одну из стандартных операций. Такая организация
работы позволяет быстро и без потерь переключаться с одного вида работы на
другой.
Рисунок 1.2 Ввод шифров работ
Рисунок 1.3. Личная карточка абитуриента (печать свидетельств)
Разработанная система автоматизирует следующий перечень работ
сотрудников приемной комиссии:
- прием предварительных тестирований абитуриентов и вступительных
экзаменов;
-
выдача свидетельств о сдаче экзаменов для поступления в вуз и
обучения на коммерческой основе;
-
распределение абитуриентов на бюджетные места по специальностям и
формирование коммерческих групп;
-
прием документов, заполнение личной карточки студента и передача
личных дел в деканаты.
Разработка Тольяттинского государственного университета.
Программная среда разработки.
При разработке системы использовались sql-сервер PostgreSQL, http
сервер Apache с поддержкой языка web-программирования Python, HTML, OC
Linux. Язык структурированных запросов SQL. Клиент - любой просмотрщик
интернет страниц, допускающий работу с формами и JavaScript [14].
Требования к оборудованию.
Cервер Celeron 800 с 512 Mб оперативной памяти. Клиент не ниже
PentiumII c 64 Мб оперативно памяти и 8 Мб VGA.
Краткий обзор системы.
Система работает в виде специализированного Web-сервера и управляется
с помощью стандартных средств доступа к интернет. Это свойство системы
делает ее кроссплатформенной и независимой от конкретной операционной
системы и не требует каких либо установок на клиентской стороне, достаточно
просто открыть любой браузер ввести http – адрес системы и можно работать. К
минусам данной системы можно отнести то, что не смотря на web-интерфеийс
она не имеет многопользовательского режима, разграничения прав доступа, что
в свою очередь делает систему уязвимой. Так же к минусам системы можно
отнести низкий уровень проработки интерфейса. В целом же система
реализована на достаточно высоком уровне и может занимать достойное место в
ряду своих аналогов.
Анализ показал, каждая система имеет свои плюсы и минусы, каждая из
систем уникальна и может эксплуатироваться только в рамках учебного
заведения, для которого оно разрабатывалось. Были отмечены и приняты на
заметку некоторые оригинальные решения. Был начат новый этап по
реинжинирингу подсистемы «Абитуриент».
1.4. Реинжиниринг
Результаты
исследований состояния информатизации
в различных
организациях позволяют сделать вывод, что в настоящий момент большинство
из них уже имеет некоторые информационные системы. Эти ИС в различной
степени автоматизируют процессы, протекающие в организациях. Исследования
проектов информатизации и, в первую очередь, проектов разработки ИС так же
показывают, что создание новой информационной системы в большинстве
случаев предусматривает изменение состояния существующих ИС. Типичными
стали проекты:
 по разработке новых ИС и их интеграции с существующими ИС;
 по разработке новых ИС с целью замены существующих ИС;
 по
модернизации
(наращиванию
функциональности,
развитию)
существующих ИС.
По сути, сегодня можно говорить, что эра, когда разработчики ИС
приходили в организацию и начинали проекты информатизации «с нуля»,
прошла. Наступает время проектов по систематической трансформации
существующих ИС или эра реинжиниринга ИС. Следствием сложившейся
ситуации становится объективная потребность в исследовании, пересмотре и
переосмыслении
существующих
подходов,
методологий
и
технологий
разработки ИС, что, в свою очередь, может потребовать их модернизации, а
возможно, и разработки новых решений. Ситуация осложняется тем, что в
настоящий момент различными исследователями и практиками понятие
реинжиниринга ИС трактуется по-разному. Во многом это обусловлено
необычайно широким спектром задач по реинжинирингу, с которыми
приходится сталкиваться в реальных проектах. Сегодня в мире существует
большое количество подходов, методов и технологических решений, напрямую
или косвенно соотносимых с деятельностью по реинжинирингу ИС. Однако они
не интегрированы на уровне методологий (процессов разработки). Как
результат, можно наблюдать наличие огромного количества методологий, где
основной акцент сделан на разработку ИС «с нуля», и практическое отсутствие
«стройных» методологий, целью создания которых являлось бы комплексное,
целостное решение задач реинжиниринга ИС. Сразу следует признать, что в
настоящий момент понятие «реинжиниринг ИС» не является повсеместно
устоявшимся.
Как
следствие,
довольно
часто
возникает
определенная
терминологическая путаница. Авторами исследуются одни и те же проблемы,
подходы, методы и технологии их решения, однако в качестве базовых понятий,
наряду с «реинжинирингом ИС» употребляются «эволюция ИС», «миграция
ИС», «модернизация ИС», «реструктуризация ИС». Нельзя отрицать, что
деятельность по миграции ИС имеет определенную специфику (окраску) по
отношению к деятельности по модернизации ИС. Однако, принимая во
внимание определение реинжиниринга ИС: «Реинжиниринг представляет собой
систематическую трансформацию существующей системы с целью улучшения
ее характеристик качества, поддерживаемой ею функциональности, понижения
стоимости ее сопровождения, вероятности возникновения значимых для
заказчика рисков, уменьшения сроков работ по сопровождению системы»,
становится очевидным, что и миграция, и модернизация ИС являются частью
деятельности по реинжинирингу ИС. Как результат, подходы, методы и
технологии миграции, модернизации, эволюции ИС, следует считать частью
методологического
и
инструментально
-
технологического
обеспечения
процесса реинжиниринга ИС [10].
1.5. Необходимые изменения в подсистеме «Абитуриент» и постановка
задачи в
В процессе реинжиниринга бизнес процессов системы «Абитуриент»
были
сформулированы
основные
направления
работы
по
дальнейшей
модернизации системы. Необходимо пересмотреть архитектуру построения
системы, детально проработать многопользовательский интерфейс системы.
Прежде всего, необходимо определиться с пользователями, которые будут
работать в системе, их можно условно разделить на четыре группы: Операторы
приемной комиссии, секретари приемной комиссии, операторы по договорам,
простые пользователи, ниже рассмотрим требования к системе с точки зрения
каждой из представленных групп.
а) Оператор приемной комиссии.
1. Заведение анкеты абитуриента (с занесением ее в единую базу).
2. Подтверждение анкеты абитуриента (ранее заведенной
абитуриентом).
3. Прием документов (аттестат, сертификат ЕГЭ).
4. Занесение фотографии в БД (либо фотографирование).
5. Печать расписки о приеме документов.
6. Выдача временного пропуска.
7. Печать экзаменационного листа.
8. Перевод абитуриента на другую специальность (до экзаменов).
9. Предоставление учебного плана.
10.Возврат всех документов абитуриенту (по требованию
абитуриента).
11.Заведение и заполнение личного дела (до экзаменов).
12.Печать заявления абитуриента (до экзаменов).
13.Печать мед. карты (до экзаменов).
14.Печать выписки из приказа о зачислении (только после
зачисления).
15.Печать справки о зачислении (только после зачисления).
16.Печать журнала регистрации.
Ограничения: Оператор приемной комиссии имеет доступ на
редактирование данных только на период подачи заявлений, после это
срока ему возможен доступ только на просмотр данных, проставление
пометке о заборе документов и дополнение льгот.
б) Секретари.
1. Печать экзаменационной ведомости.
2. Получает данные от экзаменаторов.
3. Внесение данных по оценкам в базу.
4. Формирование списка на зачисление.
5. Формирование приказа на зачисление.
6. Сводка о подаче документов за период.
7. Просмотр и печать данных об абитуриентах – расширение (за день,
за период).
8. Перевод абитуриента на другую специальность (после проведения
экзаменов) с перенесением оценок по экзаменам.
9. Печать результатов экзаменов.
в) Операторы по договорам.
1. Заключение договоров и их печать.
2. Ведение договоров.
3. Подтверждение оплаты за обучение.
4. Частичное заполнение анкетных данных (на уровне
самостоятельной регистрации).
Ограничения: должны иметь ограниченный доступ к личным делам
абитуриента. При формировании договоров получает все необходимые
данные автоматически.
г) Простые пользователи.
1. Первичное заведение личного дела (и получение номера личного
дела).
2. Просмотр статистики подачи заявлений.
3. Просмотр результатов по экзаменам.
4. Просмотр списка зачисленных абитуриентов.
Ограничения: Простые пользователи имею доступ только к
информации общего назначения.
Исходя из выше перечисленных требований, было установлено, что
требуется мощная многофункциональная, кроссплатформенная система, которая
бы обеспечивала.
 Оперативный доступ к базе данных (личных дел).
 Сохранность, целостность и достоверность данных.
 Заведение и сопровождение анкет абитуриентов.
 Формирование пакета документов необходимого для подачи заявления
прохождения
вступительных
экзаменов
и
зачисления
(расписка,
экзаменационный лист и т.д.).
 Оперативный доступ к справочной информации (рабочие планы,
конкурс на специальность, стоимость коммерческого обучения).
 Динамическое формирование статистики подачи заявлений.
 Динамическое
формирование
экзаменационной
ведомости
(по
вступительным экзаменам).
 Фундамент
для
дальнейшего
наращивания
функциональных
возможностей.
Были начаты работы по разработке структуры для новой информационной
системы.
2. Разработка и описание структуры подсистемы «Абитуриент»
2.1. Разработка структуры подсистемы «Абитуриент»
Для
описания
Унифицированный
структуры
язык
системы
моделирования
был
избран
(UML)
является
язык
UML.
стандартным
инструментом для создания "чертежей" программного обеспечения. С помощью
UML
можно
визуализировать,
документировать
моделирования
артефакты
любых
специфицировать,
программных
систем:
от
систем.
конструировать
UML
информационных
пригоден
систем
и
для
масштаба
предприятия до распределенных Web-приложений и даже встроенных систем
реального времени. Это очень выразительный язык, позволяющий рассмотреть
систему со всех точек зрения, имеющих отношение к ее разработке и
последующему
развертыванию.
Несмотря
на
обилие
выразительных
возможностей, этот язык прост для понимания и использования. UML не зависит
от моделируемой реальности, лучше всего применять его, когда процесс
моделирования основан на рассмотрении прецедентов использования, является
итеративным и пошаговым, а сама система имеет четко выраженную
архитектуру. Некоторые особенности системы лучше всего моделировать в виде
текста, другие - графически. На самом деле во всех интерфейсных системах
существуют структуры, которые невозможно представить с помощью одного
лишь языка программирования. UML - графический язык, это позволяет решить
проблему визуализации. Язык UML предназначен, прежде всего, для разработки
программных
систем.
Сфера
применения
UML
не
ограничивается
моделированием программного обеспечения. Его выразительность позволяет
моделировать, скажем, документооборот в юридических системах, структуру и
функционирование системы, осуществлять проектирование аппаратных средств
[5]. Система «Абитуриент» будет представлять собой комплекс из четырех
подсистем приложение Б, каждая из которых имеет свой интерфейс общения с
пользователем, при описании каждой из них язык UML использовался для
визуализации
бизнес
процессов
приложение
В,
построения
последовательности и проектирование внешнего вида системы.
диаграмм
2.2. Описание подсистемы «Оператор ПК»
Подсистема
«Оператор
ПК»
обеспечивает
практически
полную
автоматизацию рабочего процесса по приему документов, позволяет в несколько
раз повысить скорость и качество обслуживания абитуриента. Предоставление
абитуриенту полной справочной информации для выбранной специальности,
такой как конкурс на данную специальность, рабочий план специальности
(список изучаемых предметов), стоимость коммерческого обучения, условия
поступления на очную, заочную и коммерческую форму обучения, предлагается
список альтернативных специальностей.
На операторов возлагается большая часть работы приемной комиссии
заполнение и верификация анкетных данных абитуриента так же ведение
личных карточек. В случае некорректного ввода данных своевременное их
исправление, но после начала вступительных экзаменов права на изменение
анкетных данных у операторов изымаются,
так как необходимость в этом
отпадает и во избежание несанкционированного доступа к информации. Также к
обязанностям оператора относится заполнение и печать необходимого пакета
документов, но по большей части заполнение документов берет на себя система,
а оператору необходимо только проверить данные на корректность и, в случае
их несоответствия, принять меры по устранению ошибок. Подсистема
рассчитана на то, что абитуриент может подавать заявление на несколько
специальностей одновременно, применен механизм защиты от избыточности
данных, реализован механизм перевода абитуриента на другую специальность.
Более
подробно
информационные
процессы
отражены
на
диаграммах
последовательности рисунок 2.1, рисунок 2.2, рисунок 2.3, рисунок 2.4. Макет
пользовательского окна интерфейса представлен на рисунке 2.5.
абитуриент
оператор приемной комиссии
система "абитуриент"
журнал регистрации
аутентификация
номер анкеты
подтверждение
бланк анкеты
{OR}
анкета
заполнение анкеты
фотография
фотография
копия аттестата
сертификаты ЕГЭ
отметка о приеме документов
заявление
заявление
подпись
мед карта
расписка
пропуск
экзаменационная лист
подпись
экзаменационный лист
Рисунок 2.1. Регистрация абитуриента
абитуриент
оператор ПК
система "абитуриент"
журнал регистрации
аутентификация
запрос о переводе
удаление из списков по специальности
список переводящихся
новая специальность
статус "в процесе перевода "
внесение в списки по новой специяльности
отметка об изменении специальности
Рисунок 2.2. Изменение специальности абитуриента
абитуриент
оператор ПК
недостающие документы
система "абитуриент"
аутентификация
отметка, что абитуриент все документы сдал
Рисунок 2.3. Подача недостающих документов
абитуриент
оператор ПК
система "абитуриент"
журнал регистрации
аутентификация
продленный пропуск
списки зачислиних
{OR}
расписка
аттестат
фотографии
отметка о заборе документов
Рисунок 2.4. Продление пропуска либо возврат документов
Рисунок 2.5. Макет окна интерфейса
2.3. Описание подсистемы «Секретарь ПК»
Данная подсистема автоматизирует работу секретарей и зам. секретарей по
проставлению оценок вступительных испытаний. Заместители секретаря
приемной
комиссии
обеспечивают
заполнение
планов
приема
по
специальностям, занесение в базу экзаменационных предметов, экзаменаторов,
формирование расписания экзаменов (с указание временем проведения экзамена
и аудитории). Заместитель секретаря и секретарь производят шифрование
экзаменационных листов, после чего передают их экзаменаторам. После
проведения экзамена экзаменаторы возвращают экзаменационную ведомость,
после чего производится дешифровка данных, и оценки заносятся в базу данных.
По
завершении
всех
вступительных
испытаний
формируются
списки
рекомендованных на зачисление по специальностям. Далее формируется приказ
на
зачисление,
в
который
добавляются
абитуриенты
из
списков,
рекомендованных к зачислению по специальностям. Также формируются пакеты
документов со статистической информацией (журнал регистрации абитуриентов
за период времени) и отчетной документацией. Подробнее эти процессы
отражены в диаграммах последовательности рисунок 2.6, рисунок 2.7. Макет
окна интерфейса представлен на рисунке 2.5.
абитуриент
экзаменатор
зам секретаря ПК
секретарь ПК
система "абитуриент"
запрос на формирование экзаменационной ведомости
экзаменационная ведомость
шифрование списков
экзаменационный лист зашифрованные экзаменационные листы
согласовано
экзаменационный лист
проверка экзаменационных работ
результат собеседования
результат (математика)
результат (физика)
результат (русский)
результат (химия)
иностранный язык
ведомость
оценки
контроль оценок
Рисунок 2.6. Проведение вступительных испытаний
Зачисление
начальник ПК
система "абитуриент"
ректор
аутентификация
списки абитуриентов
приказ на зачисление
подписаный приказ
списки зачислиных
Рисунок 2.7. Зачисление
подписание приказа
2.4. Описание подсистемы «Оператор по договорам»
Подсистема «Оператор по договорам» впервые интегрируется в рабочий
процесс приемной комиссии и с единой базой данных, ранее она использовалась
как самостоятельная система. Подсистема автоматизирует
оператора по договорам,
рабочий процесс
предоставляет доступ к единой БД. Обеспечивает
интерфейс редактирования всех необходимых справочников.
Позволяет
самостоятельно заводить анкету абитуриента для заполнения договора, но не
позволяет
активировать
ее
в
системе.
Обеспечивает
автоматическое
формирование договоров абитуриента с последующим его сопровождением уже
для студента и печать отчетной документации.
На рисунке
2.8 приведена
диаграмма последовательности заключения договоров. Макет интерфейса
представлен на рисунке 2.5.
Абитуриент
Оператор по договорам
Направление
система "Абитуриент"
Поиск по базе
Акетные данные
{OR}
Заведение анкеты
Номер анкеты
форма договора
Дговор
Копия договора
Размер оплаты
Оплата
Чек
Копия договора
{OR}
Отметка об оплате
Рисунок 2.8. Заключение договоров
2.5. Описание подсистемы «Общий доступ»
В нашем вузе подобная подсистема не использовалась и это первый опыт
ее разработки. Подсистема
позволяет абитуриенту, имеющему доступ в
Интернет, самому заполнить анкету для поступления, при этом ему
присваивается и выдается личный уникальный номер. Придя к нам в вуз, он
называет свой номер оператору, который средствами поиска находит анкету
этого абитуриента и после верификации
активирует ее. Данная подсистема
позволяет ускорить работу операторов приемной комиссии. Также система
предоставляет доступ ко
всей
справочной
информации. Предоставляет
возможность просмотреть в реальном времени статистику подачи заявлений,
проходной бал, стоимость коммерческого обучения, учебные планы по
специальности.
На рисунке
2.9 показа диаграмма последовательности
самостоятельной регистрации . Макет интерфейса представлен на рисунке 2.5.
абитуриент
регистрация заявки
специальность
бланк анкеты
анкета
номер анкеты
система "Абитуриент"
Рисунок 2.9. Самостоятельная регистрация
2.6. Разработка структуры базы данных
База данных является неотъемлемой частью практически
любой
информационной системы, а от грамотного ее проектирования и от выбора
мощной и надежной СУБД напрямую зависит производительность системы.
Существующая база данных была сориентирована на использование старой
системы
и
поэтому
нуждалась
в
существенной
переработке.
Были
сформулированы новые требования к информации, которую необходимо
хранить в базе данных.
Руководствуясь выше изложенными требованиями, структура БД была
полностью перепроектирована. В таблице 2.1 приведено описание объектов,
которые содержит наша база данных.
Таблица 2.1. Объекты и атрибуты базы данных
Имя объекта
1
Абитуриент
Атрибут
2
Тип
3
Роль атрибута
4
3
4
Продолжение таблицы 2.1.
1
Абитуриент
2
Продолжение таблицы 2.1.
1
Абитуриент
2
Тип департамента
Продолжение таблицы 2.1.
3
4
1
Список
2
3
4
id
name
int(10)
varchar(100)
Код
Льгота
3
4
зачисленных
Перечень
предметов по ЕГЭ
Результаты
абитуриента по
ЕГЭ
Подразделения
Справочник
Иностранных
языков
Справочник льгот
Продолжение таблицы 2.1.
1
Список льгот
абитуриента
Направление с
линии
Справочник
видов
образований
Справочник
Основ обучения
2
Приказы на
зачисление
План приема
Продолжение таблицы 2.1.
1
Список
абитуриентов по
специальности
Специальности
Расписание
экзаменов
2
3
4
Справочник
видов ОУ
Продолжение таблицы 2.1.
1
Предметы
2
3
4
3
4
Экзаменаторы
Оценки
Договор
Продолжение таблицы 2.1.
1
Заказчик
2
Пользователи
Права
пользователей
Ресурсы
Продолжение таблицы 2.1.
1
Роли для ресурсов
Роли
Справочник полов
Сообщения
Форма договора
Справочник форм
обучения
2
3
4
Активность
пользователей
В приложении Г представлена физическая структура базы данных, в ней
описаны таблицы и связи между ними.
Для определения связей в проектируемой БД рассмотрим различные
способы представления основных типов связей:
 связь «один к одному» - в этой связи одному экземпляру каждого типа
сущности всегда соответствует не более одного экземпляра сущности
другого типа;
 связь «один ко многим» - в данном случае одному экземпляру первой
сущности может соответствовать любое число экземпляров второй
сущности;
 связь «многие ко многим» - в этом случае каждая из ассоциированных
сущностей может быть представлена любым количеством экземпляров.
В разрабатываемой базе данных используются связи только типа «один ко
многим».
3. Программная реализация
3.1. Разработка физической структуры подсистемы «Абитуриент»
Система абитуриент должна иметь многопользовательский интерфейс и
должна содержать следующие подсистемы: «Оператор ПК», «Секретарь ПК»,
«Оператор по договорам», «Общий доступ».
Подсистема «Оператор ПК» должна содержать модули:
- Анкета абитуриента.
- Добавление данных абитуриента.
- Печать пакета документов.
- Поиск абитуриента.
- Список абитуриентов.
- Список возможных специальностей.
- Список абитуриентов, несдавших документы.
- Статистика.
- Журнал регистрации.
Подсистема «Секретарь ПК» должна содержать модули:
- План набора.
- Список предметов.
- Список экзаменаторов.
- Расписание экзаменов.
- Занесение результатов экзаменов.
- Печать ведомостей.
- Печать приказов на зачисление.
Подсистема «Оператор по договорам» должна содержать модули:
- Добавление абитуриента.
- Печать договора.
- Добавление данных о заказчиках.
- Журнал регистрации.
Подсистема «Общий доступ» должна содержать модули:
- Статистика подачи заявлений.
- Статистика сдачи вступительных испытаний.
Система должна иметь трехуровневую архитектуру «Клиент - Сервер
приложений – Сервер базы данных». Все модули подсистем должны бать
реализованы в виде скриптов и обрабатываться Web-сервером, который будет
выступать выступает в роли сервера приложений. Физически скрипты каждой из
подсистем должны располагаются в отдельных папках. Вызываемые модули
должны находиться в отдельном каталоге и не должны обрабатываться Webсервером.
Данные должны храниться на сервере базы данных для обеспечения
надежности хранения информации, целостности данных, быстрого доступа к
данным. Подробнее физическая структура представлена в приложении Д.
3.2. Выбор языков программирования
В настоящее время прогрессивного развития информационных технологий
вопрос о выборе языка программирования для создания компьютерной модели
становится принципиальным. В рамках разработки данной информационной
системы выбор производится, исходя из обязательных требований:
 перспективность, то есть созданные приложения, должны отвечать
современным стандартам программного обеспечения и должна быть
возможность интеграции с различными информационных сервисов ;
 кроссплатформенность, то есть работоспособность программы не
должна
зависеть
от
платформы
компьютера
и
установленной
операционной системы;
 доступность,
то
есть
возможность
размещения
разработанного
программного продукта в пользование большому числу групп
пользователей;
 Открытость, то есть возможность оперативного изменения кода.
Рассмотрим два популярных языка Web-программирования с точки зрения
этих требований:
 PHP;
 Perl.
О языке PHP можно сказать, что это язык написания сценариев, который
был разработан специально под Web. Сценарии написанные на PHP
встраиваются непосредственно в гипертекстовые файлы и исполняются на Webсервере. Из истории известно что в 1994 году Р. Лердорф разработал набор
макросов, встраиваемых сервером www в генерируемые HTML-страницы, а в
1997 году программисты З. Сураски и Э. Гутманс полностью переписали код
ядра PHP и преобразовали его в полноценный язык программирования [2].
О
языке
Perl
можно
сказать,
что
это
высокоуровневый
интерпретированный язык программирования. Язык был создан в 1986 году как
инструмент для администрирования и конфигурирования системных ресурсов в
сети, состоящей из Unix-компьютеров. Затем он постепенно эволюционировал в
межплатформенный язык. В наибольшей степени Perl подходит для CGI
(Common Gateway Interface)-программирования, так как почти все связанные с
CGI задачи предполагают чтение, анализ и вывод текста [1].
Все вышеописанные языки программирования имеют схожие основные
свойства:
 простота - программа может состоять из 10 000 строк или из одной
строки, все зависит от специфики задачи. Если код имеет правильный
синтаксис, он исполняется в точности так, как указал программист;
 традиционность – все эти языки имеют схожий синтаксис. Многие
конструкции этих языков основаны на конструкциях языка С;
 эффективность - является исключительно важным фактором при
программировании для многопользовательских сред, к числу которых
относится WWW. По скорости работы программы, написанные на
перечисленных языках программирования, вполне соизмеримы;
 гибкость – работа на разных платформах, операционных системах, а
также возможность работы с СУБД различных видов;
 безопасность
–
языки
программирования
предоставляют
в
распоряжение разработчиков и администраторов гибкие и эффективные
средства безопасности, которые условно делятся на две категории:
средства системного уровня (настройки среды) и средства уровня
приложения (механизмы шифрования).
Обоснованием выбора языка Perl может служить то, что он наиболее
широко применяется для разработки задач подобного типа. Также можно
привести в положительные качества Perl – возможность использования
шаблонов,
что
означает
универсальность
его
использования
в
Web-
приложениях. Основним плюсом, определяющим выбор данного языка, стало
то, что он имеет модуль DBI, способный работать почти со всеми популярными
на сегодняшний день СУБД.
Необходимые требования для выбора системы управления базами данных
(СУБД):
 обеспечение санкционированного доступа к хранимым в базе данных
данным, то есть при доступе к данным запрашивается имя пользователя
и пароль;

поддержка различных платформ сервера, таких как Windows NT,
Linux;
 обеспечение одновременного доступа к данным большого количества
пользователей, то есть многопользовательской системы доступа;
 использование механизма транзакций, то есть при совершении каких
либо действий с данными из БД требуется подтверждение, иначе
происходит откат неподтвержденных действий;
 широкая техническая поддержка продукта фирмой-производителем.
Рассмотрим возможности использования СУБД с точки зрения этих
требований:
 MS-SQL;
 Oracle;
 MySQL.
Microsoft SQL – это законченное предложение в области баз данных и
анализа данных для быстрого создания масштабируемых решений электронной
коммерции,
бизнес-приложений
и
хранилищ
данных.
Оно
позволяет
значительно сократить время выхода этих решений на рынок, одновременно
обеспечивая масштабируемость, отвечающую самым высоким требованиям. В
сервер Microsoft SQL Server включена поддержка языка XML и протокола
HTTP, средства повышения быстродействия и доступности, позволяющие
распределить нагрузку и обеспечить бесперебойную работу, функции для
улучшения управления и настройки, снижающие совокупную стоимость
владения. Кроме того, Microsoft SQL Server полностью использует все
возможности операционной системы Microsoft Windows, включая поддержку до
32 процессоров и 64 ГБ ОЗУ [18].
Oracle – обеспечивает поддержку: баз данных сколь угодно большого
размера, большое число одновременно работающих пользователей, высокий
уровень производительности системы, работает 24 часа в сутки, не требуя
остановок на системные работы, избирательный контроль доступа к данным на
уровне базы данных, защиту данных от несанкционированного доступа и
некорректного использования, обеспечение целостности данных [6,13] .
MySQL – сервер баз данных. MySQL характеризуется большой скоростью,
устойчивостью и легкостью в использовании, является идеальным решением для
малых и средних приложений. Обеспечивает многопоточность, поддержку
нескольких одновременных запросов, оптимизацию связей, поддержку записей
фиксированной и переменной длины, гибкую систему привилегий и паролей, до
16 ключей в таблице, поддержку чисел длинной от 1 до 4 байт, интерфейс с
языками C и Perl, основанную на потоках, быстрая система памяти. Является
бесплатным
программным
продуктом
для
учебных
заведений
некоммерческого использования [1,7,8].
Все вышеописанные системы управления базами данных имеют схожие
основные свойства:
 поддержка различных операционных систем;
 многозадачность;
 высокая производительность;
 надёжность;
и
 безопасность.
Так как использование системы предполагается и в филиалах ИрГУПСа
где не требуется мощная СУБД и не требуется хранение и обработка большого
объёма информации, поэтому оптимальным выбором СУБД для филиалов будет
MySQL.
Для
ИрГУПСа
оптимальным
выбором
будет
СУБД
Oracle.
Обоснованием выбора СУБД MySQL и Oracle может служить и то, что и MySQL
и Oracle отвечают всем требованиям, поставленными перед информационной
системой, также отвечают стандарту языка структурированных запросов (SQL),
что положительно скажется при возможном переносе базы данных из одной
СУБД в другую.
3.3. Описание используемых алгоритмов
Алгоритмы, используемые в системе «Абитуриент», можно подразделить
на следующие типы: вызываемые модули, исполняемые модули и шаблоны.
Вызываемые модули содержат конфиденциальную информацию и напрямую
Web-сервер их не обрабатывает, чтобы в случае сбоя Web-сервера данные
скрипты не были доступны для просмотра. Исполняемые модули содержат
основной код, используемый программой. Для быстроты и удобства работы с
внешним видом системы был применен метод работы с шаблонами. Рассмотрим
некоторые основные модули из каждой группы.
Описание алгоритма работы вызываемых модулей.
Вызываемые модули содержат строки соединения с базой данных,
механизм аутентификации и функции различного общего назначения. При
настройке системы определятся, с какой СУБД она будет работать. Так как
система может использовать в качестве СУБД либо MySQL, либо Oracle, то
прописываются необходимые строки соединения. Пример:
$dbh = DBI->connect ("dbi:mysql:$db_db:$db_host",$db_user,$db_pass);
$dbh = DBI->connect ("dbi:Oracle:$db_host:$db_db:",$db_user ,$db_pass);
Механизм разграничения доступа реализован следующим образом:
пользователь при входе в систему вводит свой сетевой логин и пароль, по
протоколу LDAP делается запрос в NDS и обрабатывается ответ. Если такой
пользователь есть в NDS и его аутентификация прошла успешно, то происходит
проверка доступа к самой системе, имеет ли он доступ к текущему ресурсу
системы. При попытке пользователя зайти на недоступный ресурс ему выдается
сообщение о том, что он не имеет права на просмотр данного ресурса.
Пользователю предлагается либо обратиться к администратору системы для
получения доступа к ресурсу, либо продолжить работу с доступными ему
ресурсами.
К функциям общего назначения относятся часто используемые алгоритмы.
Такие как запросы к базе данных, функции прямого и обратного преобразования
дат, различные фильтры.
Описание алгоритмов используемых модулей.
Принцип
работы
модулей
«Анкета
абитуриента»
и
«Добавление
абитуриента». В модуле «Анкета абитуриента» подключаются вызываемые
модули, где происходит соединение с базой данных и проверка доступа
пользователя к ресурсу. Далее проверяется, добавляются данные на нового
абитуриента или выводим данные в анкету для редактирования. При добавлении
данных подключается шаблон анкеты, выполняются необходимые запросы к
справочникам базы данных, результаты запросов обрабатываются и передаются
в переменные шаблона. При редактировании анкетных данных также
подключается шаблон анкеты, выполняются необходимые запросы на выборку
анкетных данных абитуриента и к справочникам базы данных, результаты
запросов обрабатываются и передаются в переменные шаблона. После
заполнения анкеты данные предаются в модуль «Добавления данных». Далее в
модуле «Добавление абитуриента» также подключаются вызываемые модули,
где происходит соединение с базой данных и проверка доступа пользователя к
ресурсу, подключаются функции общего использования и фильтры. С помощью
соответствующих фильтров выполняется проверка данных на соответствие
необходимым требованиям. Если данные не проходят верификацию, они
передаются обратно в модуль «Анкета абитуриента» с указанием в каких именно
полях содержатся ошибки. Если данные проходят верификацию, то выполняется
проверка на, то добавляются данные или обновляются, и в соответствии с
результатом
выполняются
соответствующие
запросы
в
базе
данных.
Подключается соответствующий шаблон и в переменную шаблона выводится
результат запроса.
Опишем работу модуля «Печать пакета документов». Для работы модуля
необходимы внешние данные. В модуль передаются код абитуриента и перечень
документов,
которые
необходимо
вывести
на
печать.
Подключаются
вызываемые модули, где происходит соединение с базой данных и проверка
доступа пользователя к ресурсу. Производится выбор и подключение шаблонов
печатаемых документов. Для каждого шаблона выполняется запрос на выборку
необходимых данных. После обработки результаты передаются в переменные
шаблона, далее формируется страница печати документов.
Описание шаблонов используемых в системе.
Одной из частых задач стоящих перед Web-программистом является
отделение логики получения данных от формата представления данных. Для
решения такой задачи часто используют шаблоны html-документов, которые при
работе программ заполняются данными. Это позволяет выполнять верстку
страниц другому человеку, или изменять внешний вид страниц, не изменяя саму
программу.
Формирование шаблонов, используемых в системе, выполняется по
одному общему алгоритму. Вызываются шаблоны общего внешнего вида
системы
«заголовок»,
«горизонтальное
меню»,
«вертикальное
меню»,
«логотип». В зависимости от требований некоторые из шаблонов внешнего вида
могут не использоваться. Далее средствами языка HTML выполняется разметка
внешнего вида анкеты абитуриента и там, где необходимы данные, которые
получаем в результате работы программы, вставляются специальные теги,
описывающие
переменные,
циклы
либо
теги,
описывающие
отображения информации. Пример синтаксиса шаблона:
<TMPL_LOOP NAME="EGE">
<TR> <TD class="atbl1">Экзамен</TD>
условия
<TD><INPUT
type="hidden"
name='EGE_<TMPL_VAR
NAME="num">'
value='<TMPL_VAR NAME="id">'><TMPL_VAR NAME="name"></TD>
<TD class="atbl1">Баллы</TD>
<TD><INPUT type="text" name="EGE_<TMPL_VAR NAME="num">_mark"
value='<TMPL_VAR NAME="mark">' class="atbl" maxlength="2"
tabindex="80"></TD>
</TR></TMPL_LOOP>
4. Экономическая часть.
Целью данного раздела является определение затрат труда на
реинжиниринг подсистемы «Абитуриент» для ИрГУПС.
В начальный период появления автоматизированных систем управления
обоснование экономической целесообразности ее создания происходило по
схеме, предназначенной для расчета эффективности от внедрения новой
техники в производство. Однако практика внедрения информационных систем
показала, что для подобной оценки требуется своя методология и
специфические подходы.
Для расчета экономической части дипломного проектирования было
решено использовать метод функционально-ориентированных метрик [4].
Этот метод основан на предложенном в 1979 году Альхбертом
фундаментальном понятии – функционального размера (FP-functional point),
для измерения размера проекта не зависимо от проектирования. Метод
измерения функционального размера состоит в единообразном измерении
всех возможностей приложения и выражении размера приложения виде
единого числа. Это число можно далее использовать для оценивания числа
строк кода, стоимости и сроков проекта. Функциональный размер - весьма
привлекательное понятие, поскольку оно претендует на то, чтобы измерить
саму суть возможностей бедующей программы.
Определим функциональные модули:
 анкета абитуриента;
 поиск абитуриента;
 печать документов;
 списки абитуриентов;
 журнал регистрации;
 списки возможных специальностей;
 списки не сдавших оригиналы документов;
 расписание экзаменов;
 статистика.
Для
каждого
модуля
определим,
пять
видов
информационных
характеристик:
1) внешние вводы (вводы пользователей, по которым поступает
прикладная информация) – EI;
2) внешние выводы (выводы, по которым к пользователю поступает
результат, причем сам ввод не сохраняет и не требует каких-либо
вычислений) – ЕО;
3) внешние запросы (количество диалоговых вводов, приводящих к
немедленному ответу) – EIN;
4) внутренние логические файлы (количество логических файлов внутри
системы) – ILF;
5) внешние логические файлы (все логические файлы из внешних
приложений, с которыми работает система) – ELF.
Таблица
4.1.
Определение
информационных
характеристик
для
функционального модуля «Анкета абитуриента».
Таблица
Метрика
Значение
EI
6
EO
7
EIN
6
ILF
15
ELF
10
Сумма
44
4.2.
Определение
информационных
характеристик
функционального модуля «Поиск абитуриента».
Метрика
Значение
EI
4
EO
5
для
Таблица
Метрика
Значение
EIN
3
ILF
7
ELF
7
Сумма
26
4.3.
Определение
информационных
характеристик
для
функционального модуля «Печать документов».
Таблица
Метрика
Значение
EI
4
EO
7
EIN
6
ILF
15
ELF
10
Сумма
42
4.4.
Определение
информационных
характеристик
функционального модуля «Списки абитуриентов».
Метрика
Значение
EI
4
EO
5
EIN
3
ILF
7
ELF
7
Сумма
26
для
Таблица
4.5.
Определение
информационных
характеристик
для
функционального модуля «Журнал регистрации».
Таблица
Метрика
Значение
EI
4
EO
4
EIN
4
ILF
10
ELF
7
Сумма
29
4.6.
Определение
информационных
характеристик
для
функционального модуля «Списки возможных специальностей».
Таблица
Метрика
Значение
EI
3
EO
5
EIN
3
ILF
7
ELF
7
Сумма
25
4.7.
Определение
информационных
характеристик
функционального модуля «Списки не сдавших оригиналы документов».
Метрика
Значение
EI
4
EO
5
для
Таблица
Метрика
Значение
EIN
3
ILF
7
ELF
7
Сумма
26
4.8.
Определение
информационных
характеристик
для
функционального модуля «Расписание экзаменов».
Таблица
Метрика
Значение
EI
4
EO
5
EIN
3
ILF
7
ELF
7
Сумма
26
2.9.
Определение
информационных
характеристик
для
функционального модуля «Статистика».
Метрика
Значение
EI
4
EO
5
EIN
4
ILF
10
ELF
7
Сумма
30
Теперь приступим к расчету метрики – количества функциональных
указателей FP (Function Points) по формуле:
14
FP = Общее количество * (0,65 + 0,01 *
∑
i=14
F i ) (4.1.)
где Общее количество – общее количество значений информационных
характеристик;
Общее количество = 44+26+42+26+29+25+26+26+30=274;
Fi – коэффициент регулировки сложности.
Каждый коэффициент может принимать следующие значения:
- 0 – нет влияния;
- 1 – случайное влияние;
- 2 – небольшое влияние;
- 3 – среднее влияние;
- 4 – важное влияние;
- 5 – основное влияние.
Коэффициенты:
1. Передача данных F1 = 5.
2. Распределенная обработка данных F2 = 5.
3. Производительность F3 = 5.
4. Распространенность используемой конфигурации F4 = 0.
5. Скорость транзакций F5 = 3.
6. Оперативный ввод данных F6 = 5.
7. Эффективность работы конечного пользователя F7 = 4.
8. Оперативное наблюдение F8 = 3.
9. Сложность обработки F9 = 2.
10. Повторная используемость F10 = 4.
11. Легкость установки F11 = 0.
12. Легкость эксплуатации F12 = 4.
13. Разнообразные условия размещения F13 = 5.
14. Простота изменений F14 = 4.
14
∑
i=14
F i = 5 + 5 + 5 + 0 + 3 + 5 + 4 + 3 + 2 + 4 + 0 + 4 + 5 + 4 = 49
Итак, количество функциональных показателей равно:
FP = 274 * (0,65 + 0,01*49) = 274 * (0,65 + 0,49) = 274 * 1,14 = 312,36
Примерное количество строк программного кода LOC рассчитывается
по формуле:
LOC = FP * Kt (4.2.)
где
Kt
–
коэффициент
пересчета
для
определенного
языка
программирования, для perl Kt = 21.
LOC = 312,36 * 21 (Perl) ≈ 6559 (строк)
Реальное число строк – 5260.
Затраты на разработку проекта рассчитываем по формуле:
ЗАТРАТЫ = Кч * Км (4.3.)
где Кч – количество человек задействованных в разработке проекта, Кч
= 2 человека;
Км – время требуемое на разработку (в месяцах) Км = 6 месяца.
Таким образом:
ЗАТРАТЫ = 2 (чел) * 6 (мес) = 12 (чел. мес.)
Производительность разработки вычисляется по формуле:
FP
ПРОИЗВОДИТЕЛЬНОСТЬ = ЗАТРАТЫ (4.4.)
Подставив значения функциональных показателей и затрат, получаем:
312 , 36
ПРОИЗВОДИТЕЛЬНОСТЬ = 12
=26 , 03
Качество разработки вычисляется по формуле:
Ko
КАЧЕСТВО = FP (4.5.)
где Ко – приблизительное количество логических ошибок, которые
будут допущены при написании программного кода, Ко = 10.
10
КАЧЕСТВО = 312 , 36 =0,032
Удельная стоимость на разработку проекта вычисляется по формуле:
C
УДЕЛЬНАЯ СТОИМОСТЬ = FP (4.6.)
где С – стоимость разработки проекта.
Стоимость разработки определяется по формуле:
С = Сзп + Сотч + Снакл (4.7.)
где, Сзп – заработная плата разработчикам;
Сотч – отчисление с заработной платы;
Снакл - накладные расходаы.
Так как в разработке проекта задействовано два разработчика с
заработной платой 5000 рублей в месяц, то за 6 месяцев работы:
Сзп = 2 * 4000* 6 = 48000 рублей
Отчисления с заработной платы включают в себя: отчисление на
социальное страхование от суммы основной заработной платы и процент
отчислений на страхование от несчастных случаев на производстве и
профессиональных заболеваний. Таким образом:
Сотч = Сзп * Нсоц + Сзп * Нстрах (4.8.)
где Нсоц - отчисления с заработанной платы в виде единого социально
налога. Он составляет 26% от Сзп,
Нстрах - процент отчислений на страхование от несчастных случаев на
производстве и профессиональных заболеваний. Для рассматриваемого
проекта он будет составлять 0,2%. от Сзп.
Нсоц = 48000 * 0,26 = 12480 рублей
Нстрах = 48000 * 0,002 = 96 рублей
По формуле 4.9. получаем:
Сотч = 12480 + 96 = 12576 рублей
Расходы - затраты в процессе хозяйственной деятельности, приводящие
к уменьшению средств предприятия или увеличению его долговых
обязательств. Обычно это затраты, связанные с ресурсным обеспечением
производства, приобретением материалов, оборудования, оплатой труда
работников, ремонтом оборудования, выплатой процентов по кредитам,
арендной платой, уплатой налогов.
Накладные расходы определяются также в процентном отношении к
основной заработной плате. Этот коэффициент может отличаться на
различных предприятиях. Для предприятия ВСЖД они составят 20% от
основной заработной платы.
Снакл = 0,2 * (Сзп + Сотч) (4.9.)
Таким образом, накладные расходы равны:
Снакл = 0,2 * (48000 + 12480) = 12115,2 рублей
Находим стоимость разработки проекта по формуле 4.7.:
С = 48000 + 12480 +12115,2 = 72691,2 рублей
Итак, удельная стоимость проекта по формуле 4.6.:
72691 ,2
УДЕЛЬНАЯ СТОИМОСТЬ = 312 , 36 = 232,71
5. Безопасность и экологичность проекта
«Обоснование рациональной организации рабочего места пользователя
ПЭВМ»
При выполнении дипломного проекта возникла необходимость в
обосновании рационного размещения рабочего места пользователя ПЭВМ. Так
как при работе приемной комиссии специально оборудуются отдельные
аудитории и необходимо, чтобы размещение
только
рациональным, но
компьютерной техники было не
и соответствовало
всем
правилам и нормам
экологичной и безопасной работы с ПЭВМ. Обратимся к Санитарным правилам
и нормам СанПин 2.2.2/2.4.1340-03, нас интересуют пункты
9. Общие
требования к организации рабочих мест пользователей ПЭВМ и 10. Требования
к организации и оборудованию рабочих мест с ПЭВМ для взрослых
пользователей [12].
Общие требования к организации рабочих мест пользователей ПЭВМ.
1. При размещении рабочих мест с ПЭВМ расстояние между рабочими
столами с видеомониторами (в направлении тыла поверхности одного
видеомонитора и экрана другого видеомонитора), должно быть не менее
2,0 м, а расстояние между боковыми поверхностями видеомониторов - не
менее 1,2 м.
Рисунок 6.1. Размещение рабочих мест с ПЭВМ
Обоснование:
Все
электромагнитного поля, а
электроприборы
являются
источниками
видеомонитор является наиболее сильным
источником ЭМП. На рисунке 6.2. показаны и перечислены
воздействия монитора.
вредные
Рисунок 6.2. Вредные воздействия.
Электромагнитное излучение наиболее сильно с тыльной стороны
монитора и с боковых поверхностей. Исследования показывают, что
установка фильтров на экранах, уменьшая электрическую составляющую
электромагнитного поля в непосредственной близости от экрана, может,
вследствие перераспределения поля, привести к его увеличению на
расстояниях более 1,0-1,5 м от экрана по оси электронно-лучевой трубки и
по сторонам от нее. Так же уровень электромагнитного поля в
значительной степени зависти от типа и качества электропроводки. Так,
например,
во
многих
компьютерных
классах
отсутствует
общее
заземление, третий контакт вилки ПК оказывается «висящим» в воздухе,
что существенно увеличивает уровень электромагнитного поля. Кроме
того,
низкочастотные
поля
излучаются
и
электроприборами,
и
люминесцентными лампами, и жгутами проводов, нередко оплетающих
рабочие места. Снизить опасность для здоровья во многом можно с
помощью
нормального
заземления
аппаратуры
и
оптимальной
расстановки рабочих мест. В частности, прибегая к расположению
рабочих мест в соответствии с рисунком 6.1 и заземлению рисунок 6.3.
Рисунок 6.3 Заземление.
2. Рабочие места с ПЭВМ в помещениях с источниками вредных
производственных факторов должны размещаться в изолированных
кабинах с организованным воздухообменом.
Обоснование: При работе монитора электризуется не только его
экран, но и воздух в помещении. Причем он приобретает положительный
заряд.
Положительно
наэлектризованная
молекула
кислорода
не
воспринимается организмом как кислород, что вызывает у пользователя
кислородное голодание. Распространение принтером пыли – при работе в
тесном контакте с принтером пользователь рискует засорить свои
дыхательные пути обильно выбрасываемой принтером пылью. ТСО-99
предписывает ограничить максимальную концентрацию пыли в воздухе
вокруг работающего в обычном режиме принтера до 0, 150 мгм на
кубометр и рекомендует сократить этот придел до 0, 075 мгм. Выделение
озона – каждый, кто работал с лазерным принтером, знаком с характерным
запахом озона, образующемся при его работе. В больших количествах этот
газ может негативно сказываться на дыхательных органах пользователя,
поэтому максимальный объем эмиссии ограничен 0,02 мг на кубометр.
3. Рабочие места с ПЭВМ при выполнении творческой работы, требующей
значительного умственного напряжения или высокой концентрации
внимания, рекомендуется изолировать друг от друга перегородками
высотой 1,5 - 2,0 м.
Обоснование: Основным фактором, отвлекающим пользователя от
творческой работы или работы требующей значительного умственного
напряжения или высокой концентрации внимания, является шум, согласно
санитарным нормам СН 2.2.4/2.1.8.562-96. Для творческой деятельности,
руководящей
работы
с
повышенными
требованиями,
научной
деятельности, конструирования и проектирования, программирования,
преподавания и обучения, врачебной деятельности уровень звука не
должен превышать 50 дБА.
Для высококвалифицированной работы,
требующей сосредоточенности, административно-управленческой деятельности, измерительной и аналитической работы в лаборатории уровень
звука не должен превышать 60 дБА. Что бы обеспечить должные условия
работы
необходимо
использовать
специальные
звукопоглощающие
материалы и изолировать рабочее место посредством использования
перегородок.
4. Экран видеомонитора должен находиться от глаз пользователя на
расстоянии 600 - 700 мм, но не ближе 500 мм с учетом размеров
алфавитно-цифровых знаков и символов.
Рисунок 6.4. Расположение пользователя.
Обоснование: Говоря о мониторах компьютеров, не следует
забывать и об электростатическом поле, которое создают эти устройства.
Сильные электростатические и электромагнитные поля не безобидны для
человеческого организма. Правда, на расстоянии 50-60 см от экрана
влияние ЭСП и ЭМП значительно убывает. Применение же специальных
фильтров, прикрывающих экран, вообще позволяет свести его к нулю. В
таблице 5.1 приведены требования к электромагнитным полям дисплея.
Таблица 5.1 Параметры дисплея
Наименование параметра
ГОСТ Р
50948-96
Напряженность ЭМП в 50
см вокруг дисплея по
электричес-кой составляющей, В/м, не более в
диапазоне частот: 5Гц 2кГц 2 - 400 кГц
Плотность магнитного
потока в 50 см вокруг
дисплея, нТл, не более: в
диапазоне частот: 5Гц 2кГц 2 - 400 кГц
Поверхностный
электростатический
потенциал, В, не более
С физической точки зрения ткани
СанПиН
2.2.2.542-96
25
2.5
250
25
500
человека - парамагнитный
материал: то есть они способны «намагничиваться», воспринимать
магнитные поля. Медицинские исследования показывают, что воздействие
таких полей вызывает изменение обмена веществ на клеточном уровне.
Переменные электромагнитные поля вызывают колебания ионов в
человеческом организме, что тоже имеет определенные последствия.
Поэтому следует соблюдать правила показанные на рисунке 6.4.
5. Конструкция рабочего стола должна обеспечивать оптимальное
размещение на рабочей поверхности используемого оборудования с
учетом его количества и конструктивных особенностей, характера
выполняемой работы.
При этом допускается использование рабочих столов различных
конструкций,
отвечающих
современным
требованиям
эргономики.
Поверхность рабочего стола должна иметь коэффициент отражения 0,5 0,7.
6. Конструкция рабочего стула (кресла) должна обеспечивать поддержание
рациональной рабочей позы при работе на ПЭВМ позволять изменять позу
с целью снижения статического напряжения мышц шейно-плечевой
области и спины для предупреждения развития утомления. Тип рабочего
стула (кресла) следует выбирать с учетом роста пользователя, характера и
продолжительности работы с ПЭВМ.
Рабочий
стул
(кресло) должен
быть
подъемно-поворотным,
регулируемым по высоте и углам наклона сиденья и спинки, а также
расстоянию спинки от переднего края сиденья, при этом регулировка
каждого параметра должна быть независимой, легко осуществляемой и
иметь надежную фиксацию.
7. Поверхность сиденья, спинки и других элементов стула (кресла)
должна быть полумягкой, с нескользящим, слабо электризующимся и
воздухопроницаемым покрытием, обеспечивающим легкую очистку
от загрязнений.
Требования к организации и оборудованию рабочих мест с ПЭВМ для
взрослых пользователей
1. Высота рабочей поверхности стола для взрослых пользователей должна
регулироваться в пределах 680 - 800 мм; при отсутствии такой
возможности высота рабочей поверхности стола должна составлять 725
мм.
2. Модульными размерами рабочей поверхности стола для ПЭВМ, на
основании которых должны рассчитываться конструктивные размеры,
следует считать: ширину 800, 1000, 1200 и 1400 мм, глубину 800 и 1000 мм
при нерегулируемой его высоте, равной 725 мм.
Рисунок 6.5. Рабочий стол и рабочее кресло пользователя.
3. Рабочий стол должен иметь пространство для ног высотой не менее 600
мм, шириной - не менее 500 мм, глубиной на уровне колен – не менее 450
мм и на уровне вытянутых ног - не менее 650 мм.
4. Конструкция рабочего стула должна обеспечивать:
- ширину и глубину поверхности сиденья не менее 400 мм;
- поверхность сиденья с закругленным передним краем;
- регулировку высоты поверхности сиденья в пределах 400 - 550 мм и
углам наклона вперед до 15 град, и назад до 5 град.;
- высоту опорной поверхности спинки 300 +-20 мм, ширину - не менее
380 мм и радиус кривизны горизонтальной плоскости - 400 мм;
- угол наклона спинки в вертикальной плоскости в пределах +-30
градусов;
- регулировку расстояния спинки от переднего края сиденья в
пределах 260 - 400 мм;
- стационарные или съемные подлокотники длиной не менее 250 мм и
шириной - 50 - 70 мм;
- регулировку подлокотников по высоте над сиденьем в пределах 230
+-30 мм и внутреннего расстояния между подлокотниками в пределах
350 -500 мм.
5. Рабочее место пользователя ПЭВМ следует оборудовать подставкой для
ног, имеющей ширину не менее 300 мм, глубину не менее 400 мм,
регулировку по высоте в пределах до 150 мм и по углу наклона опорной
поверхности подставки до 20°. Поверхность подставки должна быть
рифленой и иметь по переднему краю бортик высотой 10 мм.
6. Клавиатуру следует располагать на поверхности стола на расстоянии
100 - 300 мм от края, обращенного к пользователю или на специальной,
регулируемой по высоте рабочей поверхности, отделенной от основной
столешницы.
Общее обоснование для конструктивных особенностей рабочего места.
Мало кто подходит к выбору мебели тщательно. Чаще всего в офисе не
приходится
перебирать
столами
и
стульями.
Поэтому
неправильное
соотношение размеров мебели между собой и с размерами пользователя заранее
обречено приносить неприятности человеку. Все начинается с неправильной
осанки. Если "внутренний стержень" человека - позвоночник находится в
неестественном для себя состоянии, то нарушаются многие функции организма.
Прежде всего, при согнутом позвоночнике воздух циркулирует только в верхней
части легких, а в нижней воздух "застаивается". Кроме того, согнутый
позвоночник опускает сами легкие, и они давят на внутренние органы брюшной
полости. Это может быть причиной многих болей в области живота. Подбор
стула, который смог бы поддерживать осанку, возможно, решит эту проблему.
Безусловно, он должен иметь вертикальную спинку и по возможности у него
должно быть максимум регулируемых степеней свободы. Стул должен иметь
такую высоту, чтобы ноги пользователя, опущенные на пол, не были согнуты
больше чем на 90 градусов, иначе перегибаются кровеносные сосуды и идет
плохое снабжение нижних конечностей кислородом. При долгом сидении это
может вызвать отеки ног. Высота стола вместе со стулом должна быть
подобрана так, чтобы руки в полусогнутом положении (когда, например, они
лежат на клавиатуре) не "подвисали", а опирались то ли на сам стол, то ли на
подлокотники кресла.
Рисунок 5.6. Пример расположения персонального компьютера.
При этом позвоночник должен сохранять свое ровное положение. В
противном случае человек сам вынужден их поддерживать, что при длительной
работе вызывает перенапряжение мышц плеч и шеи. Если для подпорки рук
необходимо нагибаться вперед в сторону стола, то со временем это сильно
скажется на сутулости. Поэтому у пользователя должна быть возможность
пододвинуться, как ему будет удобно, к столу. Соответственно под столом
должно быть достаточно свободного места, чтобы удобно разместить ноги. Со
времен, когда еще корпуса ПК имели форм-фактор Baby-AT и занимали
горизонтальное положение, повелось ставить на них сверху монитор, тем самым
уменьшая площадь рабочего стола, занимаемую компьютером. Многие сейчас
по привычке подставляют разнообразные коробки под мониторы. При таком
положении длительный промежуток времени голова человека находится в
неудобном для себя положении, заставляя напрягаться мышцы шеи. Также
напрягаются и мышцы глаз. Согласно правилам эргономики, монитор должен
находиться на расстоянии около полуметра, а его дисплей должен быть
расположен на 10-15 градусов ниже горизонтальной линии взора глаз. Тогда
зрачки немного опущены и шея держит голову ровно. Положительной стороной
опущенного монитора является также меньшее расстояние между экраном и
клавиатурой, а, следовательно, пользователю необходимо меньше переводить
взгляд между ними. При удачном расположении этих двух компонент ПК взгляд
можно переводить только самими глазами, не поворачивая каждый раз шею. Для
профилактики напряжений мышц не только шеи, но и всего тела, необходимо
каждый час делать перерывы, вставать, ходить, если есть возможность размяться. Турник или брусья в офисе найти трудно, но выйти в коридор и
сделать упражнения всегда можно. Чтобы размять ноги, можно на время
отказаться
от
лифта
производительность
компоненты
и
пользоваться
труда
компьютера
можно,
на
рабочем
лестницей.
правильно
столе.
Заметно
расположив
Часто
бывает,
повысить
различные
что
из-за
неупорядоченности на столе пропадает много документов, внимание постоянно
отвлекается на перемещение одних предметов, чтобы получить доступ к другим,
и т. д. На данный момент производится большое количество компьютерной
мебели, со всевозможными специализированными отделениями. К сожалению,
она не всегда бывает до конца продумана с технической точки зрения. Решить
проблему можно, расположив, к примеру, принтер и сканер на дополнительных
полках. Также можно убрать большое количество информационных и силовых
кабелей, соединив их по возможности между собой с помощью скотча. На
рабочем месте человек проводит около трети своей жизни. Поэтому необходимо
обеспечить пользователю безопасное место работы с учетом всех выше
перечисленных требований.
Заключение
В рамках дипломного проекта были разработаны и внедрены некоторые
подсистемы и модули. Полностью внедрена подсистема «Оператор ПК», в
состав которой входят модули: «Анкета абитуриента», «Добавление данных
абитуриента», «Печать пакета документов», «Поиск абитуриента», «Список
абитуриентов», «Список возможных специальностей», «Список абитуриентов,
несдавших документы», «Статистика», «Журнал регистрации». Частично
внедрена подсистема «Секретарь ПК» были внедрены следующие модули:
«План набора», «Список предметов», «Список экзаменаторов», «Расписание
экзаменов». В приложении Е показан внешний вид системы. В дальнейшем
будут продолжены работы по разработке и внедрению остальных подсистем и
модулей. Также планируется наращивание функциональных возможностей
системы, таких как фотографирование абитуриентов, с занесением фотографии в
базу данных, самостоятельная регистрация абитуриентов через интернет,
почтовая рассылка уведомлений о зачислении. Также планируется внедрение
системы «Абитуриент» в филиалах ИрГУПС. В настоящие время внедренные
подсистемы активно используются приемной комиссией ИрГУПС.