1.2.2. Функциональность

Данный критерий отражает возможности системы, связанные с выполнением заявленных функций.

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

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

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

1.2.3. Сложность в разработке, расширении и поддержке приложения

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

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

Приложение должно максимально просто разворачиваться для начала эксплуатации и быть готовым к работе «из коробки», т. е. не требовать никаких дополнительных настроек после запуска.

Должна быть возможность разворачивания приложения на любом сервере приложений и с использованием любой базы данных (при внесении соответствующих минимальных изменений в программный код). Для этого программный код для взаимодействия с СУБД должен использовать ORM-решение.

1.2.4. Скорость работы

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

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

1.3. Перечень задач, подлежащих решению в процессе разработки

Процесс создания web-приложения может быть разделен на следующие задачи:

• анализ предметной области,

• обоснование выбора языка программирования,

• концептуальное проектирование,

• разработка архитектура системы,

• разработка интерфейса пользователя,

• разработка эргономического сертификата,

• разработка, отладка и тестирование приложения,

• разработка документации (включая документирование кода).

2. Техническое задание

2.1. Наименование

Веб-приложение для технической поддержки пользователей «UHD Service».

2.2. Основание для разработки

Основанием для разработки является задание на квалификационную работу, подписанное исполнителем квалификационной работы, руководителем квалификационной работы, заведующим кафедрой АСОИУ МГТУ им. Баумана.

2.3. Исполнитель

Исполнителем является студент группы ФИО

2.4. Назначение и цель разработки

Объектом разработки является веб-приложение для технической поддержки пользователей под проектным названием «UHD Service».

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

2.5. Содержание работы

2.5.1. Задачи, подлежащие реализации

1. описание предметной области,

3. постановка задач разрабатываемой системы,

4. разработка структуры системы,

5. выбор и обоснование комплекса программных средств реализации,

6. реализация модели системы,

7. разработка графа диалога и набора экранных форм,

8. разработка эргономического сертификата,

9. составление документации.

2.5.2. Требования к функциональным характеристикам

Приложение должно выполнять следующие функции:

Со стороны пользователя:

• Регистрация пользователя в системе;

• Авторизация пользователя в системе;

• Создание новых обращений с выбором тематики;

• Просмотр всех созданных ранее обращений;

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

• Получение нотификаций о смене статуса обращения по указанным в профиле каналам связи;

• Возможность задания вопроса без авторизации с заполнением поля Email для получения ответа по почте.

Со стороны уполномоченных лиц:

• Разделение сотрудников по ролям;

• Возможность заведения новых уполномоченных лиц и назначение им ролей для роли «Администратор» + все права, описанные ниже;

• Возможность переназначения обращений, переоткрытия и закрытия обращений, смена категории обращений для роли «Руководитель» + все права, описанные ниже;

• Изменение статуса, назначение задач на себя для роли «Исполнитель»;

• Поиск по всем обращениям, фильтры и сортировки по категориям, статусам, датам обращения.