CC BY
131
удк о(шша 378141 Ю.В. Гольчевский, А.М. Сургуладзе
Опыт разработки и эксплуатации системы онлайн приема электронных заявлений от абитуриентов
Данная работа посвящена разработке и применению системы онлайн подачи электронных заявлений на поступление в ВУЗ от абитуриентов. Рассмотрены практические аспекты разработки и эксплуатации такой системы.
Ключевые слова: приемная кампания, прием заявлений через Интернет, система подачи электронных заявлений.
DEVELOPING AND OPERATING EXPERIENCE IN ONLINE ADMISSION SYSTEM FOR PROSPECTIVE UNIVERSITY STUDENTS
The paper is devoted to development and application of online admission system for prospective university students. Practical aspects of development and operation of such system are considered.
Keywords: reception campaign, admission system, reception of statements on the Internet, system of submission of electronic statements.
Введение
В процессе функционирования каждого вуза одно из важнейших значений имеет приемная кампания, в ходе проведения которой возникает множество процессов, оптимизация и автоматизация которых сыграли бы огромную роль в повышении надежности и скорости обработки информации при одновременном снижении расходов. Одним из путей автоматизации является внедрение интернет-ресурса для сбора и обработки заявлений от абитуриентов в электронном виде. В 2011 году отделом программирования Сыктывкарского государственного университета (СыктГУ) совместно с факультетом информационных систем и технологий (ныне это часть Института точных наук и информационных технологий СыктГУ) была разработана и внедрена в эксплуатацию специализированная информационная система, дающая возможность абитуриентам подавать онлайн-заявления на поступление в вуз в электронном виде. Система эксплуатировалась в ходе приемных кампаний в 2011 году и, в модернизированном виде, в 2012 году.
Интерес соответствующих специалистов других вузов и коммерческих структур, разрабатывающих подобные системы, к проблемам и ошибкам, путям их устранения и результатам послужил причиной появления данной статьи.
Предметом представленного исследования является автоматизация процесса приема заявлений абитуриентов, их регистрации и учета.
1. Система приема электронных заявлений
Регистрация и прием документов от абитуриентов происходят согласно федеральным законам и положениям. Существующая практика, формировавшаяся с течением лет, определяет схему действий в несколько этапов (в различных вузах она отличается в основном только в организационных незначительных деталях):
1) прием заполненного (согласно образцу) и подписанного абитуриентом заявления, а также оригиналов или копий документов, удостоверяющих личность, уровень образования и результаты ЕГЭ абитуриента;
2) присвоение абитуриенту порядкового номера в учетных журналах;
3) указание присвоенного номера в заявлении и формирование конверта (или пакета) документов абитуриента;
4) передача конвертов в компьютерную группу, где информация из заявлений вносится в информационную систему (ИС) «Абитуриент» сотрудниками группы;
5) возвращение пакета документов абитуриента в приемную комиссию.
Такой подход требует достаточно большого количества усилий, как со стороны сотрудников приемной комиссии, так и со стороны поступающих - абитуриенты вынуждены лично приходить в приемную комиссию вуза, заполнять заявления вручную, зачастую стоять в очередях и т.д. Особенно это может быть затруднительно для иногородних абитуриентов или абитуриентов, подающих документы в несколько вузов, расположенных в разных городах. Также при такой схеме, как правило, необходима достаточно большая компьютерная группа, в обязанности которой
Юрий Валентинович Гольчевский,
к.ф.-м.н., доцент кафедры информационных систем Тел.: 8 (8212) 48-67-20, Эл. почта:yurag@syktsu.ru ФГБОУВПО «Сыктывкарский государственный университет» http://www.syktsu.ru
Yury V. Golchevskiy,
Candidate of Physical and Mathematical Sciences, Associate Professor, Department of Information Systems Tel.: 8 (8212) 48-67-20, E-mail: yurag@syktsu.ru Syktyvkar State University, Syktyvkar http://www.syktsu.ru
Антон Михайлович Сургуладзе,
программист отдела сетевых технологий Тел.: 8 (904) 860-96-65, Эл. почта: asurguladze@gmail.com ФГБОУ ВПО «Сыктывкарский государственный университет» http://www.syktsu.ru
Ап^п М. Surguladze,
programmer, Department of Network Technologies Tel.: 8 (904) 860-96-65 E-mail: asurguladze@gmail.com Syktyvkar State University, Syktyvkar http://www.syktsu.ru
входит оцифровка информации и ее актуализация.
Для анализа рассматриваемого процесса была использована методология структурного анализа и проектирования SADT, которая состоит в представлении процесса в виде совокупности взаимосвязанных функций. Модель описывает, какие действия выполняются в ходе каждой операции, какой продукт производится на ее выходе, какая информация используется для управления действиями, а также какие ресурсы и средства применяются для исполнения ее функций. Подробнее о методологии SADT можно узнать в работах [1, 2].
SADT модель данного процесса представлена на рис. 1.
Ранее нами предпринимались попытки автоматизации работы компьютерной группы, обеспечивающей ввод данных в базы. В частности - разработка шаблонов и использование сканеров для автоматизации считывания, распознавания и записи данных в базы. Однако такой метод не дал ожидаемого эффекта, так как требовалась трудоемкая проверка правильности распознавания информации, достаточно частая корректировка введенных данных.
Альтернативным решением стало создание системы приема электронных заявлений (СПЭЗ) через интернет. Важной причиной внедрения СПЭЗ является необходимость в общей информатизации вуза - перенос информации с бумажных носителей в электрон-
ные базы данных (БД), интеграция внутренних сервисов с внешними, унифицированное хранение данных и автоматизация их обработки и т.д.
Возможность подавать заявление в вуз в электронном виде существует в целом ряде стран. Так, например, с 2011 года в украинских вузах во время приемной кампании использовалась единая система подачи заявлений в электронном виде «Електронний вступ» (http:// ez.osvitavsim.org.ua/). В Китае у абитуриентов имеется возможность использовать онлайн-сервис подачи заявлений в университеты и колледжи Китая CUCAS (http:// www.cucas.edu.cn/).
На наш взгляд, будущее за такими едиными централизованными системами. Однако разработка и внедрение единой системы для такой огромной страны, как Россия, - весьма сложная проблема. Требуется доскональное изучение существующего иностранного опыта, проблем и ошибок. А проблем возникает немало, о чем свидетельствует опыт соседней Украины. Здесь и технические и чисто «человеческие» проблемы (некоторые описаны, например в [3]). На наш взгляд, актуально и практически реализуемо на данном этапе внедрение региональных, вузовских (или межвузовских) систем, накопление и обобщение лучшего опыта в данной сфере и последующая разработка централизованной системы на основе лучших имеющихся.
Рис. 1. SADT модель процесса регистрация абитуриентов без использования системы приема электронных заявлений
Рис. 2. Регистрация абитуриентов с использованием электронных заявлений
На данный момент СПЭЗ внедряют многие вузы Российской Федерации. В качестве примера можно привести Казанский государственный энергетический университет, Томский политехнический университет, Дальневосточный федеральный университет, Нижневартовский государственный гуманитарный университет, Московский государственный университет экономики, статистики и информатики и другие.
На данный момент на рынке программного обеспечения существуют информационнотехнологические решения, реализующие задачу сбора информации от абитуриентов через интернет. Примером могут служить такие системы, как Комплексная Система управления образовательной и административно-хозяйственной деятельностью Университета с сервисами для абитуриентов [4], модуль «Абитуриент Онлайн» для информационной системы вуза «GS-ведомости» [5]. Однако существующие готовые решения встраиваются в более крупные коммерческие системы и организуют с ними взаимодействие. В связи с этим достаточно выгодным и перспективным может быть решение разрабатывать собственную ИС, которая бы была доступна для тонкой настройки и имела возможность взаимодействовать с уже имеющимися внутренними информационными системами (например, модулем учета контингента студентов, модулем статистики и т.п.)
СПЭЗ в СыктГУ была создана и введена в эксплуатацию в 2011 году, впервые в Республике Коми. Тогда системой воспользовались 3% абитуриентов. В ходе приемной кампании 2012 года количество электронных заявлений составило уже порядка 6% от общего количества поданных заявлений. Данный тренд увеличения доверия к электронной форме подачи документов (в 1,5-4 раза) характерен и для других вузов страны.
Преимущественно поступали заявления в электронной форме от абитуриентов из других населенных пунктов и других регионов.
Использование данного сервиса создает альтернативный способ регистрации абитуриентов, модель которого для нашего вуза представлена на рис. 2. Такой подход, по нашему мнению, в будущем сможет полностью заменить существующий ныне традиционный.
2. Требования к функциональности системы приема электронных заявлений и инструментарий
При формулировке задачи было принято решение проектировать ИС в виде двух подсистем:
1) веб-форма подачи онлайн-заявлений - веб-сайт, предоставляющий возможность абитуриентам, имеющим доступ в интернет, подать заявление и переслать отсканированные копии необходимых документов;
2) система учета заявлений -программа, организующая для администратора доступ к информации зарегистрировавшихся через веб-форму абитуриентов.
Функциональность проектируемой ИС можно обобщенно передать, используя диаграмму прецедентов (разновидность диаграмм UML) [1, 6]. Прецедент - это описание поведения системы с точки зрения пользователя. Графически каждый прецедент представляется в виде эллипса, а его исполнитель, то есть лицо, выполняющее конкретное действие, - в виде упрощенной фигурки человека. Исполнитель и прецедент соединяются линией, представляющей их взаимодействие. Исполнители, прецеденты и соединительные линии образуют модель прецедентов. Такая модель для описываемой системы изображена на рис. 3. На ней выделена веб-форма подачи заявлений и система учета заявок.
При разработке описываемой системы необходима группа специалистов, которую можно предста-
Рис. 3. Требуемая функциональность проектируемой ИС
Определения ролей проекта разработки СПЭЗ
Наименование Описание Требования
Руководитель проекта Руководитель проектной группы. Занимается постановкой задачи, общается с заказчиками и экспертами по знаниям, разрабатывает техническое задание, контролирует процесс разработки системы Знание технологии управления проектами и знание особенностей приемной кампании ВУЗа
Архитектор ИС Специалист по созданию архитектуры системы. Анализирует процессы, строит модель проектируемой ИС Навыки моделирования процессов и ИС, знание особенностей приемной кампании
Администратор БД Специалист по проектированию, разработке и администрированию БД. Разрабатывает структуру БД, создает таблицы, связи и т.д. Знание серверных технологий, технологий работы с СУБД (например, MySQL или т.н.)
Дизайнер Специалист по разработке дизайна системы. Разрабатывает макет дизайна исходя из особенностей предметной области, верстает страницы Знание технологий верстки web-страниц в формате HTML с использованием CSS, знание технологии программирования на языке Javascript, а также навыки работы с графическими рограммами
Веб-программист Специалист по разработке веб-сайтов. Занимается программированием и отладкой системы Знание технологий программирования на языках PHP, Javascript
Тестировщик Специалист, тестирующий систему и выявляющий неполадки и недочеты в работе ИС Навыки моделирования нестандартных ситуаций; знание полной архитектуры системы
вить ролевой матрицей, представленной в виде таблицы.
Эти специалисты указаны исходя из следующего инструментария, который может быть эффективно применен при разработке СПЭЗ: скриптовый язык PHP. язык разметки HTML, каскадные таблицы стилей CSS, скриптовый язык JavaScript, библиотека jQuery, СУБД MySQL. В первой версии нашей системы использовались программные модули, написанные на объектно ориентированном языке программирования C#. Однако в модернизированной версии они были переписаны и реализованы на PHP для упрощения обслуживания системы, что имело, несомненно, положительный результат.
Описываемая в статье система была реализована на скриптовом языке PHP под управлением веб-сервера Apache. Используемая СУБД - MySQL. Модули системы генерируют веб-страницы, использующие скриптовый язык JavaScript под управлением фреймворка jQuery. Подобная конфигурация выбрана в связи с тем, что она является одной из самых доступных и распространенных. Система, реализованная перечисленными инструментами, проста как в разработке, так и в дальнейшем сопровождении.
3. Особенности реализации системы подачи электронных заявлений
Хотелось бы остановиться на некоторых особенностях, трудностях и ошибках, возникших при создании и при эксплуатации СПЭЗ.
В процессе разработки системы были выявлены специфические риски и составлены паспорта рисков. Всего нами было выделено и рассмотрено более полутора десятков различных рисков.
Некоторые из них, которые мы посчитали достаточно критичными, приведены ниже:
• кража персональных данных абитуриентов;
• потеря персональных данных абитуриентов;
• некорректное отображение страниц веб-формы;
• отказ загрузки веб-формы.
На что обратить внимание для создания жизнестойкой, практически пригодной к эксплуатации системы? Что же необходимо при разработке описываемой системы?
1. Сделать упор на соответствие концепции Model View Controller (MVC). Это необходимо для последующей простоты и гибкости внесения изменений, так как условия и требования приема изменяются в той или иной степени практически
ежегодно. Кроме того, как показала практика, возникают различные дополнительные пожелания к системе и у специалистов самой приемной комиссии вуза. Причем эти пожелания также могут значительно изменяться из года в год.
2. Строить архитектуру системы согласно принципу понятности и простоты - предполагается использование системы пользователями с разным уровнем подготовки. Не лишним было бы предусмотреть некоторое подобие простого искусственного интеллекта: анализ введенной информации, сравнение с шаблонами, фильтрация подозрительной информации. Один из наиболее популярных вариантов на сегодня - разбиение процесса на несколько этапов (шагов). Пример интерфейса приведен на рис. 4. Как показала практика, такой подход действительно себя оправдывает и делает заполнение всех необходимых форм более упорядоченным и логически понятным.
3. Обеспечить обработку и жесткую валидацию всех приходящих от пользователя данных. Это позволит минимизировать количество неточностей, избежать потери информации и дальнейшей дополнительной нагрузки на приемную комиссию с целью ее поиска или уточнения.
Сыктывкарский государственный университет
Форма подачи электронного заявления
< Главная < Заявление { Справка
Выбор V Н Копии v
направления Н документов
Завершение f заявки
Внимательно проверьте введенную Вами информацию
ФИО: Петров Иван Андреевич
Дата рождения: 18.02.1989
Пол: Мужской
Пагплптииіе — предъявлен документ Паспорт гражданина Российской Федерации (8708 - 454545, выдан 12.05.2009, ОУФМС по РК
Рис. 4. Пример пошагового ввода информации на формах
Ж
Сыктывкарский государственный университет
Форма подачи электронного заявления
Справка
На этой странице Вы найдете ответы на наиболее часто задаваемые вопросы, а также сможете отправить свой вопрос службе поддержки.
Часто задаваемые вопросы (FAQ)
Как начать заполнение заявления?
На главной странице находится кнопка «Заполнить заявление», при нажатии на которую всплывает окно с запросом о Вашем согласии на передачу Ваших персональных данных по незащищенным каналам связи. В случае Вашего согласия произойдет переход к первому шагу заполнения анкеты.
Что делать, если возникает сообщение об ошибке при попытке перехода на следующий шаг заполнения анкеты?
Причиной ошибки может явиться некорректное заполнение полей анкеты: использование запрещенных символов или отсутствие информации в обязательном поле {обязательные поля выделены жирным). Поля, вызвавшие ошибку, подсвечиваются красным цветом.
Что делать, если нужной строки в списке нет?
Если система сообщила, что запись не найдена. Вам необходимо сообщить об этом в службу поддержки Почему при выборе направлений подготовки на определенном этапе пункты блокируются?
Прием заявлений от одного абитуриента ограничен.
При загрузке копий документов выводится сообщение о недопустимом формате.
Допустимыми форматами для загрузки копий документов являются распространенные форматы изображений: jpg, png, gif, bmp.
He загружается копия документа.
Возможно, загружаемый файл слишком большого размера (более 7 Мбайт).
Что делать, если на последнем шаге обнаружена ошибка во введенных данных?
К предыдущему шагу можно вернуться, нажав на его название в меню сверху. Всю введенную информацию можно отредактировать и сохранить, нажав на кнопку «Сохранить и продолжить».
Что делать после отправки заявления?
В течение двух рабочих дней с момента отправки заявления Вам будет прислан Ваш идентификационный номер (на каждый факультет отдельный номер), который необходимо сохранить. Если Вы примете решение подавать оригиналы документов в СыктГУ, Вам потребуется лично прийти в приемную комиссию СыктГУ и сообщить свой идентификационный номер секретарю.
Если Вы не нашли ответа на свой вопрос в разделе часто задаваемых вопросов, отправьте вопрос в службу поддержки
Вопрос в службу поддержки
Ваш e-mail
Ваш вопрос
Рис. 5. Пример раздела «Часто задаваемые вопросы»
4. Обязательно обеспечить механизмы обратной связи с абитуриентом, что позволяет свести риск потери персональных данных абитуриента к минимуму.
5. Предусмотреть возможность информационных рассылок зарегистрировавшимся пользователям.
6. Реализовать возможность редактирования поданного заявления абитуриентом, возможно, через авторизацию в личном кабинете. В первой версии нашей системы такой возможности не было, что су-
щественно осложняло исправление ошибок. Абитуриентам приходилось регистрироваться заново и заполнять всю информацию повторно. Это, в свою очередь, приводило к дублированию информации об одном человеке и неверным статистическим данным о приеме. Кроме того, вызывало жалобы со стороны абитуриентов.
7. Использование официальных справочников для системы (например, Классификатор адресов России - КЛАДР) позволяет су-
щественно ускорить, упростить и, главное, упорядочить ввод данных. Исключается возможность дублирования одной и той же информации с незначительными изменениями (например, «г. Сыктывкар» и «г. Сыктывкар»). Также это позволяет избежать чрезмерного разрастания внутренних справочников ИС. Однако при использовании описываемых справочников может потребоваться их оптимизация. Приведем пример на КЛАДРе. При создании поля с указанием населенного пункта при исходном виде таблицы адресов происходит около 4-х запросов в таблицу размером порядка 400 тысяч записей. Это значительно влияет на производительность системы. Возможное решение проблемы - создание таблицы населенных пунктов, с полем, содержащим данные, которые заведомо будут «вытянуты» перекрестными запросами, т.е. получается некая предварительная индексация данных.
8. Использовать автозаполняе-мые поля на форме - для устранения опечаток.
9. Создать раздел «Часто задаваемые вопросы», форму для задания вопросов службе поддержки. До этого часто «не доходят руки». Однако создание грамотной, продуманной справочной системы позволяет снизить нагрузку на службу поддержки и приемную комиссию. По нашим эмпирическим оценкам количество вопросов по использованию СПЭЗ, задаваемых абитуриентами, при внедрении справочной системы снизилось на треть. Такой раздел можно организовать в традиционном виде (пример представлен на рис. 5) или в виде форума (или раздела официального форума вуза).
10. Одной из существенных угроз является кража персональных данных абитуриентов. Чтобы минимизировать этот риск, требуется разделение системы на внешний раздел - видимый из сети Интернет для пользователей и внутренний - видимый для соответствующих сотрудников приемной комиссии и компьютерной группы с жестко заданными правами доступа. Причем к внутренне-
му разделу должен осуществляться доступ только из интрасети вуза, защищенной должным образом согласно Федеральному закону № 152-ФЗ «О персональных данных» [7] и другим нормативным документам.
11. Ведение истории (логов) изменений, вносимых в карточки абитуриентов, так как один абитуриент может быть зарегистрирован на нескольких факультетах и ответственные секретари не должны иметь возможности безвозвратно изменять информацию, доступную для других. При этом рекомендуем сохранять «нормальность» БД - не допускать дублирования записей об одном и том же абитуриенте.
12. Реализация разграничения доступа и введение ответственности за изменение данных влечет необходимость обучения сотрудников приемной комиссии работе в ИС, ознакомления со всеми тонкостями.
13. Дополнительной защитой может являться промежуточное временное хранилище данных, из которого данные мигрируют через определенный промежуток времени (в автоматическом или ручном режиме) в защищенное хранилище средствами администраторского раздела. Внешний раздел работает с промежуточной базой, а внутренний - позволяет перекачивать данные из промежуточной базы в постоянную базу данных модуля «Абитуриент», который доступен также только из интрасети вуза.
14. Использовать защищенные протоколы передачи данных через сеть Интернет, односторонняя передача данных по пользовательским запросам (от клиента к серверу), жесткая фильтрация приходящих на сервер пользовательских данных и т.д.
15. Папка, в которую загружаются копии документов, должна быть закрыта для чтения. Эта папка вообще требует особого внимания и усиленных мер защиты. Можно использовать эту папку как промежуточный интерфейс между внешней и внутренней частями системы.
16. При разработке сложных ин-
терфейсов необходимо учесть возможные проблемы при отображении страниц в разных браузерах и разных операционных системах. Для этого требуется использование простых и надежных механизмов, позволяющих реализовывать крос-сбраузерность и кроссплатформен-ность приложения.
17. Отказ загрузки веб-формы - один из рисков, с которым приходится иметь дело на практике. Рекомендуем серьезное тестирование системы перед внедрением, для того чтобы свести этот риск к минимуму. Основные причины появления такого рода сбоев в системе - недостатки программирования, относящиеся к кроссбрау-зерности и кроссплатформенно-сти системы, а также недостатки конфигурирования и обслуживания веб-сервера. Все это достаточно просто выявляется при тестировании.
18. Очень много интересных возможностей могла бы дать интеграция рассматриваемого сервиса с другими. Например, автоматическое «подхватывание» результатов ЕГЭ с сайта Федеральной базы свидетельств о результатах единого государственного экзамена (ФБС, http://www.fbsege.ru/) при указании абитуриентом номера свидетельства, а также обновление результатов после второй волны для уже зарегистрировавшихся в СПЭЗ.
19. Реализация автоматического формирования рейтингов для абитуриентов. Сейчас в основном это делается вручную по данным из ИС «Абитуриент».
20. В связи с растущей популярностью различных мобильных устройств, неплохим шагом было бы создание версии сайта для мобильных телефонов.
Дополнительные проблемы, с которыми пришлось столкнуться при эксплуатации системы, приведены ниже.
1. Согласование справочников различных информационных компонент, используемых в приемной кампании. Потребовалось сопоставление и приведение в соответствие справочников СПЭЗ и справочников имевшейся и эксплуати-
ровавшейся уже несколько лет ИС «Абитуриент».
2. Атаки на систему. Возможные решения: минимизация форм отправки данных, вживление скриптов поиска сомнительных данных, установка полностью автоматизированного теста Тьюринга для борьбы с «ботами».
3. Отслеживание логики заполнения заявления, чтобы абитуриент, окончивший школу, не мог подать заявление в магистратуру, и т.п. То есть выявление на этапе создания системы и реализация механизмов пресечения возможных ошибок, допускаемых по незнанию или невнимательности, сведение к минимуму риска появления ошибок, связанных с проявлением «человеческого фактора» (например, отслеживание попыток многократной регистрации с одного 1Р-адреса в течение небольшого промежутка времени, попыток многократной регистрации одной и той же информации и т.п.)
4. При внедрении системы и практическом ее использовании рекомендуем представлять систему как альтернативный способ подачи заявления. При успешной апробации возможен постепенный ежегодный переход факультетов и институтов вуза на онлайн-регистрацию. При этом предварительная подготовка к приемной кампании должна подразумевать активную рекламу сервиса в средствах массовой информации, на официальном сайте вуза и во время проведения профориентационных мероприятий.
5. Удобным в практическом плане вариантом является создание системы в виде отдельного раздела официального сайта. В СыктГУ система была реализована на отдельном субдомене с индивидуальным оформлением и стилистикой.
Заключение
Опыт использования системы во время приемных кампаний 20112012 гг. в СыктГУ показал актуальность и эффективность выбранного подхода. Вот некоторые из полученных выгод и преимуществ.
1. Внедрение системы позволило распределить часть нагрузки по внесению информации в БД
на самих поступающих, в том числе и при личном посещении приемной комиссии с помощью компьютеров, установленных непосредственно в вузе.
2. Контроль за правильностью вводимой информации также частично лег на самих поступающих, что позволило снизить количество ошибок в БД.
3. Абитуриенты из других населенных пунктов при помощи активной службы поддержки смогли подавать заявления, не выходя из дома. Сервис использовался абитуриентами из разных регионов и многие из них в итоге выбрали СыктГУ для дальнейшего обучения и получения высшего образования.
4. Внедрение сервиса позволило уменьшить штат сотрудников, обслуживающих приемную кампанию, и при этом снизить количество возникающих ошибок и увеличить скорость обработки заявлений.
5. Внедрение подобного сервиса благополучно влияет на общий престиж и рейтинги вуза.
Литература:
1. Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. - М.: Финансы и статистика, 2007. - 240 с.
2. Бабенко В.В. Практический анализ бизнес-процессов. - Сыктывкар: Изд-во СыктГУ, 2010. - 288 с.
3. Абитуриенты обманули сами себя в системе «Вступ». Комментарии: Луганск [Электронный ресурс]. - иЯЬ: http://lugansk.comments.ua/article/2012/08/16/131759.html (дата обращения: 17.08.2012).
4. Сайт группы компаний VPGroup, Решения [Электронный ресурс]. - иКЬ: http://www.vpgroup.ru/Default. aspx?tabid=411 (дата обращения: 17.08.2012).
5. Система автоматизации учебного процесса, автоматизация вуза - GS-Ведомости, Гуру-софт [Электронный ресурс]. - URL: http://gs-vedomosti.ru/ (дата обращения: 17.08.2012).
6. Фаулер М., Скотт К. иМЬ в кратком изложении. Применение стандартного языка объектного моделирования: Пер. с англ. - М.: Мир, 1999. - 191 с.
7. Федеральный закон от 27 июля 2006 г. № 152-ФЗ «О персональных данных» (с изменениями и дополнениями) [Электронный ресурс]. - URL: http://base.garant.ru/12148567/ (дата обращения: 17.08.2012).
