Файл: Пермский филиал Факультет бизнесинформатики Кафедра информационных технологий в бизнесе удк 004. 031. 4 Информационная система для привлечения абитуриентов выпускная квалификационная работа бакалавра.docx

Заместитель директора	Подконтрольные подразделения
Оболонская Алла Владимировна	Отдел по организации приема абитуриентов
	Деканат факультета довузовской подготовки
	Отдел развития университетского округа НИУ ВШЭ
Левина Светлана Геннадьевна	Отдел по связям с общественностью
	Отдел веб-технологий

На следующем этапе определим основные входы и выходы подразделений. Разделим их на:

1. 
   школьников, участвовавших в каких-либо мероприятиях и решивших продолжить взаимодействие с НИУ ВШЭ – Пермь (подать документы);
   
2. 
   школьников, решивших не подавать документы;
   
3. 
   учителей, участвовавших в каких-либо мероприятиях;
   
4. 
   мероприятия по привлечению школьников (PR­ ­– мероприятия);
   
5. 
   мероприятия образовательного характера (дополнительные курсы, олимпиады);
   
6. 
   результаты мониторинга образовательных услуг;
   
7. 
   официальный вебсайт университета.
   

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

На следующем этапе в соответствии с положениями выбранных ранее подразделений необходимо определить их основные функции (см. табл. 2.3. Функции подразделений) [35].

Столбец «БП» содержит информацию об отношении функции подразделения к определяемым далее бизнес‑процессам.

3. 
   Функции подразделений
   

Подразделение	Основные функции	БП
Отдел по организации приема абитуриентов	Организация набора студентов очной формы обучения (студентов бакалавриата и магистратуры) НИУ ВШЭ – Пермь	5
	Подготовка приказов, служебных записок, положений и иных документов, регламентирующих прием документов очередного набора	2,5
	Ведение и актуализация баз данных абитуриентов	5
	Проведение информационной и консультативной работы с абитуриентами и их родителями (законными представителями) по вопросам поступления	2,5
	Организация проведения мониторинга рынка образовательных услуг (спроса и предложений) в области высшего образования	4
	Организация и проведение олимпиад для школьников	1, 6
	Формирование отчетной документаций	5
Деканат факультета довузовской подготовки	Создание и реализация на практике образовательных программ, учебных планов, программ учебных курсов	6
	Организация и проведение профессионально-ориентационной работы	6
	Организация, проведение и контроль образовательного процесса подготовительных курсов и организация работы базовых классов при НИУ ВШЭ – Пермь	6
	Организация, проведение и контроль процесса повышения профессиональной компетентности работников образования	3
Отдел веб‑технологий	Обеспечение работоспособности официального сайта	2
	Сбор и редактирование информации для официального сайта	2
	Создание веб-приложений для нужд структурных подразделений	2
	Ведение мониторинга информационных потоков официального сайта	2,4

---

3. 
   Функции подразделений (продолжение)
   

Подразделение	Основные функции	БП
Отдел развития  университетского округа НИУ ВШЭ	Создание и организация деятельности проектной группы Университетско-школьного кластера	3
	Проведение конкурса по отбору образовательных учреждений Пермского края для участия в деятельности кластера	3
	Обеспечение системы дистанционного взаимодействия участников проекта по реализации образовательных программ дополнительного профессионального образования	3
	Мониторинг процесса совершенствования предметно-содержательной компетенции учителей-предметников с применением специальной технологии	3
	Организация индивидуальных и групповых консультативных взаимодействий участников Кластера	3
Отдел по связям с общественностью	Формирование, реализация и развитие политики НИУ ВШЭ – Пермь в области связей с общественностью	1
	Разработка и контроль реализации концепций внешней и внутренней информационной и рекламной политики НИУ ВШЭ – Пермь	1
	Организация взаимоотношений НИУ ВШЭ – Пермь со СМИ, государственными органами, общественными и коммерческими организациями	1
	Координация работы НИУ ВШЭ – Пермь и его структурных подразделений по проведению информационно-рекламных кампаний и информационных поводов (выставки, презентации, события), разработке и контролю качества информационно-рекламных и презентационных материалов (плакатов, проспектов, каталогов, буклетов, баннеров и т.п.), по обеспечению НИУ ВШЭ – Пермь и его структурных подразделений сувенирными и презентационными материалам	1,2
	Предоставление и контроль актуальности и достоверности новостных материалов о деятельности НИУ ВШЭ – Пермь, комментариев для формирования новостной части официального сайта (портала) НИУ ВШЭ – Пермь	1,2

---

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

Выходы были разделены на основные и их обеспечивающие. Для получения основных выходов обозначим основной бизнес–процесс организации –взаимодействие со школьниками (см. рис. 2.1. Бизнес-процессы организации).

1. 
   Бизнес-процессы организации
   

Среди обеспечивающих его процессов выделим процессы, как:

1. 
   проведение PR – мероприятий;
   
2. 
   оказание информационной поддержки;
   
3. 
   работа со школьными учителями;
   
4. 
   проведение мониторинга рынка образовательных услуг;
   
5. 
   организация Приемной кампании;
   
6. 
   организация дополнительного образования школьников.
   

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

Для более подробного рассмотрения был выбран БП «Проведение PR‑мероприятий» (см. рис. 2.2. Бизнес-процесс «Проведение PR–мероприятия»). Основанием для выбора послужил факт, что данный БП протекает и в рамках Приемных кампаний, и при организации дополнительного образования, и при работе с учителями. Различие состоит в направленности мероприятия, однако основные этапы остаются схожими. Кроме того, организация различных мероприятий является основой для деятельности в области public engagement.

Основными этапами БП являются анализ концепции мероприятия и требуемых затрат, получение ресурсов для мероприятия и поиск площадки для его проведения, сбор информационных материалов. Затем начинается подготовка информации для публикации на официальном сайте НИУ ВШЭ – Пермь и профилях в социальных сетях, рассылка приглашений заинтересованным лицам и заключение договоров для публикации в средствах массовой информации. До или после непосредственного проведения мероприятия возможно анкетирование школьников или других лиц.

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

---

Определим узкие места построенного бизнес-процесса.

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



1

2. 
   Бизнес-процесс «Проведение PR–мероприятия» (начало)
   

1

2. 
   Бизнес-процесс «Проведение PR–мероприятия» (окончание)
   

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

В качестве одного из недостатков описанного БП также является выполнение всех этапов сотрудниками НИУ ВШЭ – Пермь. К работе над некоторыми этапами, как например, подготовка и сбор информации, могут быть привлечены студенты, чья заработная плата будет существенно ниже. Ранее также были описаны преимущества волонтерского движения для университета и студентов.

На основе анализа БП были определены следующие недостатки существующей модели бизнес-процесса:

1. 
   Основными причинами задержек является необходимость обработки информации различными подразделениями НИУ ВШЭ – Пермь.
   
2. 
   Для организации информационной поддержки мероприятия используются различные информационные системы, что ведет к отсутствию единой базы данных пользователей.
   
3. 
   Этапы БП выполняются исключительно сотрудниками НИУ ВШЭ – Пермь, без привлечения к работе студентов.
   

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

3. Построение модели TO_BE

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

Для представления функций системы была описана диаграмма вариантов использования (см. рис. 2.1. Диаграмма вариантов использования). Диаграмма приписывает прецеденты к субъектам и позволяет установить отношения между ними:

1. 
   Диаграмма прецедентов
   

В созданной диаграмме смысл отношения «расширить» состоит в том, что, например, прецедент «Добавление и редактирование» события может быть расширен прецедентом «Уведомление участников». Между администратором системы (АС), контентным администратором (КА), публицистом (Пт) и обычным пользователем (ОП) существует отношение обобщения. Таким образом, публицист обладает всеми возможностями обычного пользователя, контентный администратор – публициста, а администратор системы – возможностями контентного администратора и доступом к системе администрирования.

Для описания каждого из прецедентов был использован документально зафиксированный поток событий (flow of events). Соответствующий документ определяет, что должна делать система, когда субъект инициирует прецедент, кто может его инициировать и какими будут постусловия.

Описание прецедентов началось с описания прецедента «Добавление и редактирование события», доступного для контентного администратора и администратора системы (см. табл. 2.4. Прецедент «Добавление и редактирование события»):

4. 
   Прецедент «Добавление и редактирование события»
   

Краткое описание	Прецедент дает возможность АС или КА добавлять, редактировать и размещать события. Вводится описание события, дата и место проведения, прикрепляются дополнительные материалы.
Актеры	Администратор системы или Контентный администратор
Предусловия	АС или КА проходит авторизацию и переходит на страницу с событиями
Основной поток	Начало прецедента совпадает с решением АС или КА создать событие с помощью выбора функции «Создать событие» (или аналогичной функции) при отображении на экране сведений о ранее созданных событиях. Система просит АС или КА ввести детали События, в том числе: заголовок и описание, детали, касающиеся времени и места проведения (если оно есть). Также существует возможность прикрепить дополнительные файлы. АС или КА вводят детали События и/или прикрепляют файлы. АС или КА могут отредактировать информацию о Событии, добавить или удалить прикрепленные файлы, затем выбрать функцию «Опубликовать событие» (или аналогичную) Система присваивает уникальный номер и запоминает информацию о событии в базе данных.
Альтернативные потоки	АС или КА инициирует функцию «Опубликовать событие» до того, как введет всю обязательную информацию. Система отображает на экране сообщение об ошибке и просит ввести пропущенную информацию. АС или КА выбирает функцию «Отмена» (или аналогичную) для того, чтобы вернуться к списку событий.
Постусловия	Если прецедент был успешным, «Событие» записывается в базу данных и публикуется в списке событий. В противном случае состояние системы остается неизменным

Прецедент «Добавление и редактирование события» может быть расширен прецедентом «Уведомление участников». Иными словами, после создании события администраторы системы могут осуществить информационную рассылку (см. табл. 2.5. Прецедент «Уведомление участников»).

5. 
   Прецедент «Уведомление участников»
   

Краткое описание	Прецедент дает возможность АС или КА уведомлять пользователей системы о предстоящем событии.
Актеры	Администратор системы или Контентный администратор
Предусловия	Успешно добавленное в систему событие
Основной поток	Начало прецедента совпадает с решением АС или КА уведомить пользователей о событии с помощью выбора функции «Рассылка» (или аналогичной функции) при переходе на вкладку «Рассылка» созданного события. Система просит АС или КА ввести список электронных адресов для рассылки. АС или КА могут ввести электронные адреса самостоятельно или выбрать из списка зарегистрированных пользователей системы по таким критериям, как: город, школа, тип пользователя (если указаны). Также существует возможность отредактировать список для рассылки, удалив из него ранее внесенные адреса ручную. АС или КА вводит текст уведомления. Существует возможность использования служебных слов, как: %recipient_FIO%, %recipient_EMAIL%, %sender_FIO%, %note_NAME% и др. АС или КА инициирует функцию «Уведомить» (или аналогичную)
Альтернативные потоки	АС или КА инициирует функцию «Уведомить» до того, как введет всю обязательную информацию. Система отображает на экране сообщение об ошибке и просит ввести пропущенную информацию. Клиент выбирает функцию «Отмена» (или аналогичную) для того, чтобы вернуться к странице события
Постусловия	Если прецедент был успешным, система выводит сообщение об успешной рассылке приглашений. В противном случае состояние системы остается неизменным

Администратор системы и контентный администратор могут сформировать отчет о подтвердивших участие (см. табл. 2.6. Прецедент «Формирование отчета»):

6. 
   Прецедент «Формирование отчета»
   

Краткое описание	Прецедент дает возможность АС или КА просматривать и сохранять на локальный компьютер списки пользователей, подтвердивших участие.
Актеры	Администратор системы или Контентный администратор
Предусловия	АС или КА открывают страницу события и переходят к вкладке с участниками
Основной поток	Начало прецедента совпадает с решением АС или КА просмотреть списки участников события с помощью выбора функции «Участники» (или аналогичной функции). Система выводит информацию об участниках, подтвердивших или опровергнувших участие. АС или КА могут инициировать функцию «Сохранить» для получения списка участников.
Альтернативные потоки	АС или КА просматривает сведения о событии, не просматривая информацию об участниках
Постусловия	Если прецедент был успешным, файл формата .xlsx сохраняется на компьютере пользователя. Иначе состояние системы остается неизменным

Публицист, контентный администратор и администратор системы могут добавлять и редактировать публикацию напрямую, без проверки контентным администратором (см. табл. 2.7. Прецедент «Добавление и редактирование публикации»):

7. 
   Прецедент «Добавление и редактирование публикации»
   

Краткое описание	Прецедент дает возможность АС, КА или Пт добавлять, редактировать и размещать публикации. Вводится текст публикации, прикрепляются дополнительные материалы.
Актеры	Администратор системы, Контентный администратор, Публицист
Предусловия	АС или КА или Пт проходит авторизацию и переходит на страницу с публикациями
Основной поток	Начало прецедента совпадает с решением АС, КА или Пт создать публикацию с помощью выбора функции «Добавить публикацию» (или аналогичной функции) при отображении на экране списка публикаций. Система просит АС, КА или Пт ввести детали публикации, в том числе: заголовок и текст. Также существует возможность прикрепить дополнительные файлы. АС, КА или Пт вводит текст публикации и/или прикрепляют файлы. АС, КА или Пт может отредактировать публикацию, добавить или удалить прикрепленные файлы, затем выбрать функцию «Опубликовать» (или аналогичную функцию). Система присваивает уникальный номер и запоминает информацию публикации в базе данных.
Альтернативные потоки	АС, КА или Пт инициирует функцию «Опубликовать» до того, как введет всю обязательную информацию. Система отображает на экране сообщение об ошибке и просит ввести пропущенную информацию. АС, КА или Пт выбирает функцию «Отмена» (или аналогичную) для того, чтобы вернуться к списку публикаций.
Постусловия	Если прецедент был успешным, публикация записывается в базу данных и размещается на сайте. В противном случае состояние системы остается неизменным

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

Под черновиком в данном контексте подразумевается созданная, но не размещенная на сайте публикация, требующая рассмотрения контентного администратора (см. табл. 2.8. Прецедент «Добавление и редактирование черновика»).

8. 
   Прецедент «Добавление и редактирование черновика»
   

Краткое описание	Прецедент дает возможность ОП добавлять и редактировать черновик публикации. Вводится текст публикации, прикрепляются дополнительные материалы.
Актеры	Пользователь системы
Предусловия	Пользователь проходит авторизацию и переходит на страницу с публикациями
Основной поток	Начало прецедента совпадает с решением ОП создать публикацию с помощью выбора функции «Добавить публикацию» (или аналогичной функции) при отображении на экране списка публикаций. Система просит ввести детали публикации, в том числе: заголовок и текст. Также существует возможность прикрепить дополнительные файлы. Пользователь вводит текст публикации и/или прикрепляет файлы. Пользователь может отредактировать публикацию, добавить или удалить прикрепленные файлы, затем выбрать функцию «Отправить на модерацию» (или аналогичную функцию). Система присваивает уникальный номер и запоминает информацию публикации в базе данных.
Альтернативные потоки	Пользователь инициирует функцию «Отправить на модерацию» до того, как введет всю обязательную информацию. Система отображает на экране сообщение об ошибке и просит ввести пропущенную информацию. Пользователь выбирает функцию «Отмена» (или аналогичную) для того, чтобы вернуться к списку публикаций.
Постусловия	Если прецедент был успешным, публикация записывается в базу данных. Публикации присваивается статус «на рассмотрение». В противном случае состояние системы остается неизменным

Для того, чтобы публикация была размещена на сайте, она должна быть одобрена контентным администратором или администратором системы (см. табл. 2.9. Прецедент «Изменение статуса публикации»):

9. 
   Прецедент «Изменение статуса публикации»
   

Краткое описание	Прецедент дает возможность АС или КА просматривать и утверждать для публикации черновик, созданный пользователем системы. Изменяется статус публикации.
Актеры	Администратор системы, контентный администратор
Предусловия	КА проходит авторизацию и переходит на страницу с черновиками публикаций
Основной поток	Начало прецедента совпадает с решением КА просмотреть черновики публикации с помощью выбора функции «Публикации для рассмотрения» (или аналогичной функции) при отображении на экране списка черновиков публикаций. Система выводит страницу черновика публикации. КА просматривает текст публикации и/или вносит правки. КА инициирует функцию «Опубликовать» (или аналогичную функцию). Система присваивает уникальный номер и запоминает информацию в БД.

9. 
   Прецедент «Изменение статуса публикации» (продолжение)
   

Альтернативные потоки	КА инициирует функцию «Переделать» после просмотра черновика. Система сообщает пользователю – создателю черновика о необходимости доделать публикацию. Пользователь выбирает функцию «Отмена» (или аналогичную) для того, чтобы вернуться к черновикам публикаций.
Постусловия	Если прецедент был успешным, публикация записывается в базу данных и размещается на сайте. В противном случае состояние системы остается неизменным.

Пользователь может оставить комментарий к публикации или событию (см. табл. 2.10. Прецедент «Добавление комментария»):

10. 
    Прецедент «Добавление комментария»
    

Краткое описание	Прецедент дает возможность пользователям системы оставить комментарий к публикации или событию.
Актеры	Пользователи системы
Предусловия	Размещение события или публикации.
Основной поток	Начало прецедента совпадает с просмотром сведений о событии или публикации. Пользователь инициирует функцию «Оставить комментарий» (или аналогичную функцию), затем пишет текст комментария. Система присваивает уникальный номер и запоминает информацию о комментарии в базе данных. Система выводит комментарий пользователя на экран.
Альтернативные потоки	Автор выбирает функцию «Отмена» (или аналогичную) для того, чтобы вернуться к событию или публикации без комментирования.
Постусловия	Если прецедент был успешным система выводит оставленный комментарий. В противном случае состояние системы остается неизменным

Также у пользователя существует возможность прикрепить опрос к событию или публикации (см. табл. 2.11. Прецедент «Добавление опроса»):

11. 
    Прецедент «Добавление опроса»
    

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

11. 
    Прецедент «Добавление опроса» (продолжение)
    

Альтернативные потоки	Автор инициирует функцию «Прикрепить опрос» до того, как введет всю обязательную информацию. Система отображает на экране сообщение об ошибке и просит ввести пропущенную информацию. Автор выбирает функцию «Отмена» (или аналогичную) для того, чтобы вернуться к редактированию события или публикации.
Постусловия	Если прецедент был успешным, опрос записывается в базу данных. Отметка о прикрепленном отчете указывается в событии/публикации. В противном случае состояние системы остается неизменным

После прохождении опроса пользователь может просмотреть статистику опроса (см. табл. 2.12. Прецедент «Просмотр статистики»):

12. 
    Прецедент «Просмотр статистики»
    

Краткое описание	Прецедент дает возможность пользователям системы просмотреть статистику опроса
Актеры	Пользователи системы
Предусловия	Создание опроса, прохождение его пользователями
Основной поток	Начало прецедента совпадает с прохождением пользователями прикрепленного опроса. Пользователь инициирует функцию «Просмотреть статистику» (или аналогичную функцию) Система выводит данные ответов пользователей
Альтернативные потоки	Автор выбирает функцию «Отмена» (или аналогичную) для того, чтобы вернуться к событию или публикации без просмотра данных опроса
Постусловия	Если прецедент был успешным система выводит данные опроса. В противном случае состояние системы остается неизменным

Пользователи системы могут изменить свой статус участия в событии (см.  табл. 2.13 Прецедент «Изменение статуса участия»):

13. 
    Прецедент «Изменение статуса участия»
    

Краткое описание	Прецедент дает возможность зарегистрированным пользователям изменять статус участия в событии. Пользователи могут подтвердить или опровергнуть свое участие.
Актеры	Зарегистрированный пользователь
Предусловия	Пользователь проходит авторизацию и переходит на страницу с событиями
Основной поток	Начало прецедента совпадает с просмотром пользователем списка событий или страницы определенного события. Пользователь может выбрать функцию «Участвую» или «Не участвую». Система присваивает уникальный номер и запоминает информацию о решении пользователя в базе данных.
Альтернативные потоки	Пользователь просматривает список событий, не изменяя статус участия
Постусловия	Если прецедент был успешным, состояние участия пользователя записывается в базу данных и публикуется на странице участников события. Иначе состояние системы остается неизменным

Администратор системы и контентный администратор обладают правами осуществлять контроль контента (см. табл. 2.14. Прецедент «Контроль контента»):

14. 
    Прецедент «Контроль контента»
    

Краткое описание	Прецедент дает возможность АС или КА осуществлять контроль контента системы
Актеры	Администратор системы или Контентный администратор
Предусловия	Авторизация АС или КА
Основной поток	Начало прецедента совпадает с открытием страницы списка изменений контента (публикации, комментарии). АС или КА инициирует функцию «Просмотреть добавленные публикации» (или аналогичную функцию). Система выводит список добавленных публикаций. АС или КА просматривают список публикаций, при необходимости инициируют функции «Редактировать» или «Удалить». АС или КА инициирует функцию «Просмотреть добавленные комментарии» (или аналогичную функцию). Система выводит список добавленных комментариев. АС или КА просматривают список комментариев, при необходимости инициируют функции «Редактировать» или «Удалить». Система запоминает информацию об изменении контента в системе.
Альтернативные потоки	АС выбирает функцию «Отмена» (или аналогичную)
Постусловия	Если прецедент был успешным система записывает изменение в базу данных. В противном случае состояние системы остается неизменным

Распределение ролей в системе осуществляется администратором системы (см. табл. 2.15. Прецедент «Управление доступом»):

15. 
    Прецедент «Управление доступом»
    

Краткое описание	Прецедент дает возможность АС управлять ролями пользователей
Актеры	Администратор системы
Предусловия	Авторизация администратора системы
Основной поток	Начало прецедента совпадает с открытием списка пользователей системы. АС инициирует функцию «Просмотреть список пользователей» (или аналогичную функцию). Система выводит список пользователей системы с указанием их ролей. АС инициирует функцию «Изменить роль». АС инициирует функцию «Сохранить изменения» (или аналогичную) Система запоминает информацию об изменении роли пользователя в БД
Альтернативные потоки	АС выбирает функцию «Отмена» (или аналогичную) для того, чтобы отменить изменения.
Постусловия	Если прецедент был успешным система записывает изменение в базу данных. В противном случае состояние системы остается неизменным

Для каждого посетителя системы (неавторизованного пользователя) существует возможность зарегистрироваться (см. табл. 2.16. Прецедент «Добавление и редактирование данных профиля»).

16. 
    Прецедент «Добавление и редактирование данных профиля»
    

Краткое описание	Прецедент дает возможность посетителям зарегистрироваться в системе.
Актеры	Посетитель
Предусловия	Посещение вебсайта системы
Основной поток	Начало прецедента совпадает с посещением вебсайта системы. Посетитель инициирует функцию «Регистрация» (или аналогичную функцию). Система предлагает пользователю ввести логин, пароль, личные данные. Посетитель подтверждает ввод данных. Система отправляет на указанный адрес электронной почты письмо для подтверждения регистрации. Пользователь переходит по ссылке, указанной в письме и инициирует функцию «Подтвердить регистрацию».
Альтернативные потоки	Посетитель инициирует функцию «Регистрация» до того, как введет всю обязательную информацию. Система отображает на экране сообщение об ошибке и просит ввести пропущенную информацию. Информация, введенная посетителем, содержит ошибки (не проходит верификацию). Система отображает на экране сообщение об ошибке и просит ввести корректную информацию. Посетитель выбирает функцию «Отмена» (или аналогичную)
Постусловия	Если прецедент был успешным система выводит сообщение об успешной регистрации пользователя и перенаправляет его на главную страницу сайта. Информация о пользователе сохраняется в системе. В противном случае состояние системы остается неизменным.

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

---

Выбор программного обеспечения

Отправной точкой выбора ПО является архитектура ИС. Для сравнения были выбраны трёхзвенная архитектура (Three-tier, или Multitier architecture) и концепция MVC («Model – view – controller»), предполагающая разделение данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: модель, представление и контроллер [36].

Трехзвенная архитектура является примером многоуровневой архитектуры, включающей клиентское приложение (браузер), сервер приложений и сервер базы данных [37]. Подбор архитектур основан на общем свойстве изолированности (независимости) компонентов, что впоследствии обеспечивает возможность повторного использования и более высокую скорость разработки, за счёт возможности параллельной работы.

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

Следовательно, одним из критериев подбора фреймворков для сравнения является поддержка концепции MVC. Сравнение будет произведено по следующим критериям (см. табл. 2.17. Сравнение фреймворков для разработки):

1. 
   стоимость (приобретения, внедрения, владения);
   
2. 
   язык программирования;
   
3. 
   функциональность (наличие ключевых функций для обеспечения задач ИС);
   
4. 
   техническая документация и примеры;
   
5. 
   поддерживаемые СУБД;
   
6. 
   сложность установки и настройки;
   
7. 
   платформа;
   
8. 
   успешные проекты.
   

По итогам сравнения лучшие результаты показали фреймворк Ruby on Rails и Django. Малое количество примеров и справочников и высокая сложность установки и настройки привели к отказу от фреймворка Symfony [38]. Стоимость и необходимость работы исключительно с платными продуктами компании «Microsoft» исключили фреймворк ASP.NET MVC [39].

Фреймворки Django и Ruby on Rails основаны на общем принципе повторного использования, позволяющего снизить дублирование кода в приложении (принцип «Don’t repeat yourself») [40]. Хотя Django имеет обширную встроенную функциональность,

---