Ссылки: прецедент «Генерация отчетов».
Предусловия: пользователь вошел в систему.
Постусловия: отображение отчета.
Рисунок 2.1 Диаграмма последовательностей «Генерация отчетов»
Название: «Регистрация участников на мероприятие» (рис. 2.2).
Обязанности: выбрать мероприятие, нажать на кнопку «Добавить участников», выбрать участников, нажать на кнопку «Сохранить».
Ссылки: прецедент «Регистрация участников на мероприятие».
Предусловия: пользователь открыл календарь мероприятий.
Постусловия:
1. Добавлена связь между выбранными участниками и мероприятием.
2. Данные сохранены.
Рисунок 2.2 Диаграмма последовательностей «Регистрация участников на мероприятие»
Название: «Добавление мероприятия» (рис. 2.1).
Обязанности: нажать на кнопку «Добавить мероприятие», заполнить информацию, нажать на кнопку «Сохранить».
Ссылки: прецедент «Добавление мероприятий».
Предусловия: пользователь открыл календарь мероприятий.
Постусловия:
1. Создан объект «Мероприятие».
2. Объект добавлен в БД.
Рисунок 2.3 Диаграмма последовательностей «Добавление мероприятия»
2.2 Проектирование базы данных
На данном этапе необходимо было выполнить нормализацию отношений (прил. C). Итоговая база данных содержит 35 таблиц, схема данных представлена в приложении A (рис. A.7-A.9).
2.3 Диаграмма классов модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
В процессе проектирования системы необходимо было разработать статическую структуру системы в нотации диаграмм классов UML.
Классы предметной области были разработаны на основе БД с некоторыми изменениями (рис. A.10-A.12). Были также добавлены перечислимые типы, необходимые для выбора типа мероприятия, типа участника и пола ученика - данные типы не хранятся в БД, так как они должны оставаться неизменными.
Кроме того, были разработаны классы, необходимые для работы приложения с БД и с запросами - NHRepository<T> и контроллеры (рис. A.13).
Таким образом, была спроектирована диаграмма классов системы учета профориентационных мероприятий.
2.4 Проведение технико-экономического обоснования разработки модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
На данном этапе необходимо было провести технико-экономическое обоснование разработки системы.
Для расчета трудоемкости и стоимости работ на создание программного продукта была выбрана методика CETIN.
Первым этапом расчета была оценка функционального размера программного продукта. Показатели были выявлены с помощью построенных диаграмм:
1. Количество вариантов использования (количество прецедентов) - 20.
2. Количество типов объектов (количество классов, относящихся к предметной области) - 31.
3. Количество свойств типов объектов (количество свойств классов, относящихся к предметной области) - 98.
4. Количество взаимодействий между типами объектов (количество связей между классами, относящимися к предметной области) - 33.
5. Количество типов узлов (серверная часть, клиентская часть) - 2.
Таким образом, функциональный размер составляет {20, 31, 98, 33, 2}. Далее необходимо было рассчитать базовую трудоемкость создания программного продукта (табл. 2.1).
Таблица 2.1 Расчет базовой трудоемкости создания программного продукта
|
Наименование процесса |
Функциональная единица измерения |
Итого чел. мес. |
|||||
|
Вариант использования |
Тип объекта |
Свойства типа объекта |
Свойства взаимоотношения между объектами |
Тип узла |
|||
|
Трудоемкость, чел.час |
|||||||
|
Бизнес моделирование |
32,12 |
28,33 |
0 |
14,15 |
0 |
12,05 |
|
|
Управление требованиями |
58,03 |
28,04 |
0 |
20,32 |
0 |
16,37 |
|
|
Проектирование |
45,42 |
61,75 |
31,35 |
37,52 |
24,02 |
43,52 |
|
|
Реализация |
31,57 |
81,51 |
50,72 |
36,11 |
0 |
56,49 |
|
|
Тестирование |
88,96 |
0 |
0 |
0 |
0 |
10,78 |
|
|
Развертывание |
8,69 |
0 |
0 |
0 |
23,74 |
1,34 |
Базовая трудоемкость составляет 140.55 человеко-месяцев.
Следующим этапом необходимо было рассчитать поправочные коэффициенты трудоемкости процессов разработки программного продукта (табл. 2.2).
Таблица 2.2 Расчет базовой трудоемкости создания программного продукта
|
КП1 |
1,12 |
|
|
КП2 |
1,15734528 |
|
|
КП3 |
1,33537276 |
|
|
КП4 |
1,192297107 |
|
|
КП5 |
1,33537276 |
|
|
КП6 |
1,257984 |
Затем необходимо было оценить трудоемкость разработки с учетом поправочных коэффициентов (табл. 2.3).
Таблица 2.3 Расчет базовой трудоемкости создания программного продукта
|
№ |
Наименование процесса |
Итого чел. мес. |
Итого с учетом коэффициентов чел. мес. |
|
|
1 |
Бизнес моделирование |
12,05 |
13,50 |
|
|
2 |
Управление требованиями |
16,37 |
18,95 |
|
|
3 |
Проектирование |
43,52 |
58,12 |
|
|
4 |
Реализация |
56,49 |
67,35 |
|
|
5 |
Тестирование |
10,78 |
14,40 |
|
|
6 |
Развертывание |
1,34 |
1,69 |
Итоговая трудоемкость составляет 173.99 человеко-месяцев. При такой оценке трудоемкости сроки разработки можно оценить в 8 месяцев. Минимум 4 месяца, максимум - 12 (табл. 2.4).
Таблица 2.4 Зависимость срока разработки от трудоемкости
|
Срок разработки |
Трудоемкость чел. мес. |
|
|
1 месяц |
5 - 30 |
|
|
2 месяца |
10 - 80 |
|
|
3 месяца |
17 - 140 |
|
|
4 месяца |
26 - 210 |
|
|
5 месяцев |
37 - 280 |
|
|
6 месяцев |
50 - 340 |
|
|
7 месяцев |
65 - 400 |
|
|
8 месяцев |
80 - 450 |
|
|
9 месяцев |
100 - 500 |
|
|
10 месяцев |
120 - 550 |
|
|
11 месяцев |
140 - 610 |
|
|
12 месяцев |
160 - 670 |
|
|
13 месяцев |
180 - 720 |
При уменьшении сроков разработки с 8 до 4 месяцев произойдет увеличение трудоемкости разработки программного продукта. При условии, что коэффициент эластичности трудоемкости составляет 0.75, а срок уменьшается на 50%, трудоемкость увеличится на 37.5% и составит 239.24 человеко-месяцев.
Далее необходимо было оценить стоимость разработки программного продукта. Среднее количество лет реализации проекта составляет 1 год. Среднемесячная номинальная заработная плата в области информации и связи составляет 67797 рублей по данным от Федеральной службы государственной статистики России за 2018 год [8]. Средняя инфляция за 3 года составляет 4,06%. Средняя стоимость 1 человека-месяца инженера-программиста составляет 225 236,36 рублей.
Таким образом, стоимость работ на создание программного продукта составляет 39 188 874,15 рублей.
Развитие и сопровождение системы не предполагается.
Поскольку разрабатываемая система не предполагает массового использования, окупаемость не рассчитывается.
2.5 Проектирование пользовательского интерфейса модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
Последним этапом проектирования системы является проектирование интерфейса. На данном этапе необходимо было создать единый стиль оформления страниц и меню сайта (рис. 2.4). Для этого были использованы корпоративные цвета НИУ ВШЭ - белый (#ffffff) и синий (#003380) [7].
Рисунок 2.4 Меню сайта
Затем необходимо было разработать макет календаря мероприятий (рис. 2.5). Важно было учесть, что мероприятие должны выделяться разными цветами в зависимости от подразделения, которые занимается его организацией. Для выделения мероприятий с несколькими подразделениями был выбран серый цвет (#d8e4e4).
Рисунок 2.5 Календарь мероприятий
При нажатии на мероприятие должна отображаться краткая информация о нем и кнопки удаления и редактирования (рис. 2.6).
Рисунок 2.6. Краткая информация о мероприятии
Также необходимо было разработать макет страницы для редактирования справочников (рис. 2.7). Она должна была включать список возможных справочников со ссылками на них, заголовок текущего справочника, строку поиска, кнопку добавления и таблицу с элементами.
Рисунок 2.7 Страница редактирования справочников
Для редактирования и добавления элементов справочников было решено использовать модальные окна (рис. 2.8). Каждый такой компонент должен включать заголовок, поля ввода (либо селекторы) с названиями для всех свойств, которые есть у данного типа справочника, и кнопки «Сохранить» и «Отмена».
Остальные компоненты были спроектированы во время непосредственной разработки системы на основе представленных макетов с соблюдения общего стиля.
В данной главе были описаны этапы проектирования системы для учета профориентационных мероприятий, была разработана база данных, созданы необходимые диаграммы и основной интерфейс системы.
3. Разработка модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
Данная глава представляет собой описание этапов реализации системы: создание модели реализации, выполненной в нотации диаграммы компонентов UML, разработку основных компонентов. Также здесь содержится описание процесса тестирования системы и подготовки документации.
3.1 Модель реализации модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
Перед реализацией информационной системы была построена модель реализации, выполненная в нотации диаграммы компонентов UML.
Диаграмма, описывающая основную структуру серверной части системы, состоит из контроллера «EventController.cs», сервиса «EventService», хранилища «EventStorage.cs», репозиториев «EventRepository.cs» и «NHRepository.cs», библиотеки «NHibernate.dll» (для использования интерфейсов «ISession» и «ISessionFactory»), модели «Event.cs» и базы данных «HSEvents.dbo» (рис 3.3).
Рисунок 3.1 Диаграмма компонентов серверной части системы
Диаграмма, описывающая основную структуру клиентской части системы, состоит из макета «Index.html», который включает в себя иконку «favicon.ico», используемые скрипты («bootstrap.js», «jquery.js») и стили («bootstrap.min.css», «font-awesome.min.css», «styles.css»), а также загрузчик «SystemJS», который обеспечивает работу с Angular. Компоненты Angular состоят из модуля «app.module.ts», роутинга «app-routing.module.ts», самого компонента «app.component.ts», его шаблона «app.component.html» и стилей «app.component.css» (рис. 3.2).
Рисунок 3.2 Диаграмма компонентов клиентской части системы
3.2 Разработка серверной части модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
В серверной части системы необходимо было реализовать загрузку компонентов Angular и макета «Index.html» при любом обращении к системе кроме API запросов. Для этого были прописаны правила маршрутизации: запросы API направлялись к соответствующим контроллерам, все остальные уходили в «HomeController», который возвращал пользователю html-страницу.
Для каждой модели был добавлен свой контроллер с методами для создания, получения, обновления, удаления и обработки данных. Каждый контроллер обращается к соответствующему сервису, в котором содержится логика обработки данных. Для работы с базой данных созданы хранилища и репозитории: репозитории взаимодействуют с данными с помощью библиотеки «NHibernate» - открывают сессию и совершают необходимые транзакции; хранилища создают область действия для вызываемых методов репозиториев, чтобы завершить их правильным образом и вызвать закрытие сессии.