Смекни!
smekni.com

«Проект создания системы автоматизированного учёта пользовательских заявок по функционированию факультетской компьютерной сети» (стр. 2 из 5)

Операторы:

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

Администраторы:

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

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. Содержательная часть

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-скриптов, дополняющих необходимую функциональность ядра посредством механизма так называемых «реакторов». Достаточно стабильный код, изрядный объём документации.