Операторы:
Сотрудники лаборатории программного оборудования, с помощью Системы координирующие взаимодействие между Пользователями и Исполнителями. Оператор принимает заявки (по телефону и лично) у пользователей (кроме тех, кто отправляет заявки сразу через пользовательский интерфейс системы), выясняет у пользователей недостающую необходимую информацию, назначает поступившие заявки на исполнение Исполнителями, контролирует процесс и факт исполнения заявки. Предполагается средний уровень компьютерной грамотности Операторов.
Администраторы:
Сотрудники лаборатории программного оборудования, с помощью специального административного интерфейса осуществляющие управление функционированием системы.
2.3.2 Функциональность на основе ролей.
Для определения точного перечня необходимой функциональности системы была произведена серия интервью с людьми, которые после внедрения системы будут выполнять функции соответственно Оператора (Валерия Евгеньевна) и Исполнителя (Роман Кондаков) с целью выявить их потребности от системы. Интервью будущих Пользователей не проводилось, так как это было бы неоправданно с учётом предназначения системы (многочисленные пользователи не могут заранее предусмотреть, что именно им потребуется от системы в случае заведомо нештатной ситуации).
Будущему Оператору (Валерии Евгеньевне) были заданы вопросы, позволившие по возможности полно выяснить, как происходит процесс учёта пользовательских заявок в настоящее время. Будущего Исполнителя (Роману Кондакова) попросили самого описать, какие возможности использования системы он хотел бы видеть.
По результатам этих опросов и коллективных дискуссий был разработан перечень функциональности, которую должна обеспечивать система и были разработаны макеты пользовательских интерфейсов, реализующих эту функциональность.
Функциональность для пользователей:
1) Пользователь должен иметь возможность пользоваться системой через web-интерфейс без какой либо авторизации.
2) Пользователи должны иметь возможность составлять новые заявки. На этапе Первой Очереди Функциональности интерфейс будет предельно упрощённым, не иерархическим. Одна гиперссылка - одна html-страница с одной формой, предназначенной для отправки информации для создания заявки одной категории. Наполнение формы определяется конфигурацией Системы при внедрении. На форме должны присутствовать обязательные и необязательные поля, заполнение обязательных должно немедленно проверяться посредством javascript.
3) После отправки заявки пользователю должен сообщаться уникальный номер заявки. Должен существовать Web-интерфейс для проверки пользователем статуса заявки по её номеру.
4) В случае если заявка пользователя требует подписи у ответственного лица, пользователь должен иметь возможность немедленно распечатать готовое заявление, либо запросить его распечатку в помещении Лаборатории Программного Оборудования с последующей подписью заявления ответственным лицом в порядке общей очереди, без непосредственного участия Пользователя.
5) На этапе Второй Очереди Функциональности, должен быть разработан иерархический пользовательский интерфейс, позволяющий пользователю последовательно идентифицировать проблемы у перейти к созданию соответствующей категории заявки либо к получению готового ответа из базы решений.
6) Рассматривается возможность создания на этапе Второй Очереди Функциональности email-интерфейса пользователя, являющего собой альтернативу Web-интерфейсу.
Функциональность для операторов:
1) Оператор должен работать с системой через Web-интерфейс с авторизацией.
2) Оператор должен иметь возможность создавать в системе новые заявки любых категорий, в случае если Пользователь не делает этого самостоятельно (а приходит с проблемой лично либо звонит по телефону).
3) Оператор должен видеть все новопоступившие и уже имеющиеся в системе заявки и совершать с ними следующие действия:
- Отклонить и закрыть заявку (флуд, проблема не относится к сфере ответственности Лаборатории Программного Оборудования, известная проблема, ..)
- Отредактировать поля заявки
- Добавить к заявке комментарий
- Принять заявку в работу, назначить её выполнение одним/нескольким исполнителям.
- Переназначить выполнение заявки другим исполнителем.
- Зарыть заявку как выполненную, поместить в архив закрытых заявок.
- Видеть статус и историю существования заявки.
- Отослать комментарий по заявке на e-mail пользователю (если указан)
- Распечатать по данным заявки заявление для подписи ответственным лицом.
- Работать с архивом закрытых заявок. На Второй Очереди Функциональности - возможность осуществлять интеллектуальный поиск по архиву закрытых заявок с целью, в частности, просмотра истории прошлых заявок от конкретного пользователя.
Функциональность для исполнителей:
1) Исполнители в основном работают с системой через Web-интерфейс, а также получают разнообразные уведомления от системы через e-mail.
2) Исполнители получают уведомления о назначенных им операторам заявках, а также, обособленно – обо всех поступивших в систему нераспределённых заявках.
3) Исполнитель может:
- Видеть список распределённых на него заявок, и общий список нераспределённых ни на кого заявок. По отдельной ссылке – видеть список заявок, распределённых на любого другого Исполнителя.
- Пометить распределённую на него заявку выполненной, с добавлением соответствующего комментария.
- Заявить о своей ответственности над не распределённой на него заявкой («забрать себе» заявку), причём это относится как к «ничейной» заявке, так и к назначенной другому администратору.
- Отказаться от ответственности за заявку («снять её с себя»), сделав её ничейной.
- Добавлять комментарии к заявкам, редактировать информацию в них.
- Изменять режим своей email-подписки на уведомления о новых заявках.
3.1 Анализ существующих решений.
Был произведён обзор существующих систем подобного рода (Request tracker, Issue tracker, Trouble ticketing systems) информацию о которых удалось найти в Интернете.
Рассматривались только системы с открытым исходным кодом, чья лицензия не запрещает бесплатное использование системы в масштабах факультета.
Также не рассматривались системы, изначально ориентированные на Bug-tracking, то есть на фиксацию и отслеживание обнаруженных ошибок в программном обеспечении, так как решаемая ими задача специфична и сильно отлична от задач, стоящих перед нашей системой.
Кроме того, по ряду причин нами было принято решение не рассматривать системы, созданные на платформе Java.
В результате были подробно рассмотрены следующие системы:
- RT (http://freshmeat.net/projects/requesttracker/): Мощнейшая trouble-ticketing система с открытым исходным кодом. Широко применяется, часто обновляться. Стабильна, хорошо документирована.
Недостатки: Система избыточно мощна для наших нужд, но при этом не обладает достаточной гибкостью в части реализации пользовательского интерфейса. Для того чтобы согласно требованиям к системе создать предельно упрощённый пользовательский интерфейс понадобились бы очень масштабные модификации RT.
Кроме того, ни один из членов команды не знаком в достаточной мере с языком Perl и, более того, не считает целесообразным его осваивать, так как будущее Perl как популярного промышленного языка весьма сомнительно.
- IssueTrackerProduct (http://www.issuetrackerproduct.com/): Достаточно интересная и удобная система, хотя и редко используемая. Гибкая внутренняя архитектура должна легко адаптироваться под наши нужды. Система написана на языке Python с использованием сервера приложений Zope. Однако код практически не документирован, и на момент проведения исследования система давно не обновлялась и неизвестно, являлась ли стабильной. Что и послужило главным аргументом против этого варианта.
- Trouble Ticket Express (http://www.troubleticketexpress.com/):
Система написана на Perl, но обладает очень приятным на вид пользовательским интерфейсом. Система поставляется бесплатно и с исходным кодом, но обладает при этом весьма ограниченной функциональностью. Исходный код качественный и легко читаемый, хотя и слабо документированный. Также авторы предлагают за символическую плату дополнительные подключаемые модули к системе, реализующие дополнительную функциональность. С включением нескольких из этих модулей система вплотную приближается к тому, что нужно нам. Однако недостатком является то, что недостающие модули пришлось бы всё-таки оплатить (хотя сумма не очень велика, суммарно порядка нескольких десятков долларов США). И не удалось выяснить, поставляются ли модули с исходным кодом или без.
- Roundup (http://roundup.sourceforge.net/): Issue tracker, написанный на чистом Python. Отличительная особенность в том, что эта система изначально позиционируется не как готовое решение, а скорее как SDK для построения решения на его основе (хотя система работает и может быть использована и без модификаций). Технически Roundup представляет собой ядро в виде модуля Python, которое может настраиваться на конкретные применения посредством набора шаблонов. Шаблоны состоят из собственно HTML-шаблонов по технологии TAL, и Python-скриптов, дополняющих необходимую функциональность ядра посредством механизма так называемых «реакторов». Достаточно стабильный код, изрядный объём документации.