Цель работы и основные этапы разработки.

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

Разработка веб-сервиса включает следующие этапы:

1) Анализ предметной области

2) Обзор существующих аналогов

3) Формирование функциональных требований

4) Выбор средства разработки

5) Разработка веб-сервиса

6) Тестирование

7) Внедрение на предприятии.

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

Каждый пользователь ИУС П Т должен быть наделен набором ролей, необходимых и достаточных для выполнения операций, определенных должностными обязанностями.

Доступный для присвоения пользователям набор ролей описан в матрице доступа пользователей к информационным ресурсам ИУС П Т.

Последовательность определения ролей:

• Определение с руководителем перечня операций, который выполняется сотрудником в ИУС П Т;

• Согласно определенным операциям, по актуальной матрице доступа, определяются необходимые функциональные (отдельные/групповые) и организационные роли. Функциональные роли предоставляют права доступа на определенные операции в системе. Организационные роли предоставляют права доступа на выполнение операций по необходимым бизнес-сферам.

• В случае, если необходимые роли не найдены в матрице доступа, или возникли сложности с определением ролей, составляется заявка в SAP Solution Manager (SSM) с просьбой оказать помощь в определении ролей. Заявка в SSM должна включать подробное описание операций, которые будут выполняться в ИУС П Т, с указанием наименований структурных подразделений Общества, на которых будут распространяться результаты операций.

• После получения информации в SSM, необходимо проверить полученный перечень ролей на предмет существования в актуальной Матрице доступа к ИУС;

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

• Не допускается оформление заявок на добавление групповых ролей (состоит из одной или нескольких отдельных ролей) и отдельных ролей, включенных в эти групповые роли.

Матрица доступа ИУС П Т представляет собой перечень ролей, разделенных по функциональным блокам:

? Бухгалтерский и Налоговый учёт (БУНУ);

? Материально-техническое обеспечение (МТО);

? Диспетчерское управление (ДУ);

? Ведение карточки договора (ВКД);

? Управление финансами, Управленческий учёт (УФ и УУ);

? Техническое обслуживание и ремонт (ТОиР);

? Ведение нормативно-справочной информации (НСИ).

Роли разделяются на:

? Функциональные (отдельные/групповые): определяют ограничение полномочий в соответствии с выполняемыми функциями;

? Организационные: определяют ограничение полномочий, согласно организационной структуре предприятия.

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

Таблица 1.1 - Порядок действий при предоставлении или изменении прав доступа к ИУС П Т

Формированием такой заявки на предприятии занимается сам пользователь. Первый вопрос, которым он задается - это "а какие роли мне нужны?". Выяснение данного вопроса и является основной проблемой, решение которой занимает большую часть времени, так как пользователю необходимо, основываясь на матрице доступа и своем перечне обязанностей, самостоятельно определиться с перечнем необходимых ему ролей. При этом сама по себе матрица доступа ИУС П Т представляет собой достаточно громоздкую базу данных, содержащую в себе коды ролей и их краткое описание. В такой ситуации информационная база, содержащая в себе в качестве примеров уже заполненные заявки, могла бы ощутимо сократить время, потраченное пользователем на составление. Разработка такого веб-сервиса и стала темой данной работы.

Обзор существующих решений

Описанную концепцию информационного ресурса с функциями автоматизированного составления, проверки и просмотра готовых заявок можно было бы реализовать с помощью программ и сервисов семейства Help Desk (досл. с англ. "стол помощи") - сегмента программ, с помощью которых можно осуществлять техподдержку пользователей.

Например, программа "Регистрация заявок LAN" - это удобная и функциональная Help Desk система для учета и отслеживания заявок, и вопросов от пользователей в локальной сети. Программа обладает простым интерфейсом, который будет понятен любому пользователю и не требует специального обучения. Система легко адаптируется и подходит для любой сферы, где нужен учет заявок. Систему могут использовать как малые локальные компании, так и крупные организации, которые имеют удаленные офисы. Администраторам и исполнителям предоставляется удобный механизм контроля поступивших заявок, а каждому пользователю - возможность отслеживать состояния своей заявки.

Основной набор функций:

• Регистрация и отслеживание заявок от пользователей в локальной сети TCP/IP.

• Редактируемая база знаний.

• Клиент-Серверная технология.

• 4 типа пользователей программы.

• Группировка исполнителей и заявок.

• Возможность формирования отчетов на основании полученных заявок.

• Уведомления по e-mail.

• Задачи.

• Диалог администратора с клиентом (чат).

• Система оценки заявок.

• Календарь.

• Карточка заявки.

• Обновления.

• Возможность отправлять файлы.

• Поддержка многоязычности.

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

Неплохой альтернативой предыдущему примеру мог бы оказаться программный продукт GLPI (Gestionnaire libre de parc informatique - Свободный менеджер ИТ-инфраструктуры), который является системой работы с заявками и инцидентами, а также для инвентаризации компьютерного оборудования (компьютеры, программное обеспечение, принтеры и т.д.). Имеет расширенные функции, такие как работа системы отслеживания почты с уведомлением и методы, для создания базы данных с основной информацией о топологии сети. Включает следующие возможности:

• инвентаризацию компьютеров, периферийного оборудования, сетевых принтеров и связанных компонентов через интерфейс с OCS Inventory или FusionInventory;

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

• управление лицензиями, договорами (по стандарту ITIL);

• связывание пользователей и групп по географическому положению;

• управление деловой и финансовой информацией (договоры);

• управление статусом объектов;

• поддержка базы знаний и Часто задаваемых вопросов (FAQ);

• генераторы отчетов;

• поддержка UTF8;

• система оповещения о событиях.

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

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

Программа решает следующие задачи:

• разработка информационных систем:

? создание пользовательских интерфейсов баз данных для ввода / вывода / изменения / удаления информации в / из баз данных;

? автоматизация действий пользователя и бизнес-процессов;

? интеграция информационной системы;

• администрирование информационных систем:

? создание рабочих столов для доступа к объектам информационной системы;

? предоставление пользователями доступа к информационной системе;

? регулирование прав доступа и разрешений;

• эксплуатация информационных систем:

? доступ из локальной сети и удаленный доступ к информационной системе;

? ввод / получение / изменение / удаление пользователем информации;

? выполнение автоматизированных действий при работе в информационной системе.

Однако это решение имеет один существенный недостаток - необходимость установки и настройки на сервере собственной СУБД PostareSQL.

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

1.1 Формирование функциональных требований

Ниже пройдемся по основным направлениям решения проблемы и сформируем основные функциональные требования, предъявляемые к веб-сервису.

Основная цель создания данного веб-сервиса - помощь пользователям при заполнении индивидуальной заявки на создание нового пользователя ИУС П Т или добавление ролей существующего. Достижение данной цели можно условно разделить на два этапа:

• 1 этап - помощь в определении списка необходимых пользователю ролей;

• 2 этап - помощь в заполнении самой заявки.

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

Реализация первого этапа может быть осуществлена посредством создания базы данных (далее БД) готовых заявок. Такая база даст пользователю возможность узнать какие роли были подключены другим пользователям ИУС П Т, в том числе его коллегам и на основе этой информации позволит более точно определиться с перечнем необходимых ролей. Наглядно это показано на рисунке 2.

Рисунок 2 - обращение пользователя к базе заявок

На основании этого можно сформировать первое функциональное требование к разрабатываемому веб-сервису:

Предоставление доступа к структурированной БД пользовательских заявок для ознакомления и определения собственного перечня необходимых ролей.

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

Заявка состоит из трех разделов:

• Раздел 1 - данные пользователя. Тут пользователю необходимо указать свои личные данные (ФИО, должность, подразделение, телефон и др.), а так же номер договора о конфиденциальности, который заключается со всеми работниками, работающими с конфиденциальной информацией.

• Раздел 2 - системные реквизиты. Тут пользователь указывает необходимо ли ему внести изменения в список имеющихся у него ролей (добавить или удалить) или создать нового пользователя в ИУС П Т. Кроме того в этом разделе указывается перечень ролей необходимых пользователю.

• Раздел 3 - Подключение рабочего места. В этом разделе указывается необходимая техническая информация для подключения АРМ, а так же указываются контактные данные администратора АРМ и администратора информационной безопасности.

Кроме того, к каждой индивидуальной заявке предоставления или изменения прав доступа пользователей к ИУС П Т прилагается лист согласования, в котором дублируются контактные данные пользователя из 1 раздела заявки, а так же прописывается перечень ролей с разбивкой по функциональным блокам (БУНУ, МТО, ТОиР и др.) и согласованием каждого блока ответственным за него лицом.

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

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

Рисунок 3 - обращение пользователя к форме заполнения заявки

Тут мы подходим к формированию второго функционального требования к разрабатываемому веб-сервису:

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

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

Для поддержания актуальности базы данных заявок разумно было бы добавить на стадии формирования печатной формы одновременную отправку введенной пользователем информации администратору в виде запроса на добавление (удаление) данных в БД.

Реализация данного решения может быть осуществлена путем создания формы обработки поступающих запросов в блоке администрирования. Используя данную форму, администратор сможет просматривать поступающие запросы на добавление или удаление ролей (пользователей) и выполнять необходимые действия по внесению изменений в БД. Наглядно реализация решения может быть представлена в виде измененного рисунка 4:

Рисунок 4 - обращение пользователя к форме заполнения заявки

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

В результате можно сформировать третье функциональное требование к разрабатываемому веб-сервису:

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

Опционально еще можно предусмотреть справочный блок, в который будут помещены ссылки на:

• нормативные документы;

• регламенты;

• приказы, относящиеся к работе ИУС П Т;

• инструкции по работе данного веб-сервиса;

• иные документы, относящиеся к работе веб-сервиса и ИУСП Т.

Если у пользователя возникнут затруднения или вопросы по работе с веб-сервисом, либо по работе с ИУС П Т в целом, то в данном блоке он сможет найти всю необходимую информацию.

2. Средства разработки

2.1 Средства реализации

Учитывая задачи и функциональность проекта, было принято решение реализовывать веб­сервис с использованием:

• Apache;

• HTML;

• CSS;

• JavaScript;

• PHP;

• MySQL.

В данной работе у нас будет использоваться двухзвенная архитектура "клиент-сервер". Наглядно она представлена на рисунке 5. В архитектуре "клиент-сервер" программное обеспечение разделено на две части: клиентскую часть и серверную часть. На сервере большой нагрузки не будет, и в связи с этим мы будем использовать тонкий тип клиентов в системе клиент-сервер. И как классический пример: Web-технологии (клиент-браузер, сервер-Web-сервер).

Рисунок 5 - Двухзвенная архитектура "клиент-сервер"

Веб-сервер

В качестве HTTP-сервера выбран Apache. Apache является кроссплатформенным ПО, поддерживает операционные системы Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS. Основными достоинствами Apache считаются надёжность и гибкость конфигурации. Он позволяет подключать внешние модули для предоставления данных, использовать СУБД для аутентификации пользователей, модифицировать сообщения об ошибках и т. д. Поддерживает IPv6.

Система конфигурации Apache основана на текстовых конфигурационных файлах. Имеет три условных уровня конфигурации:

• Конфигурация сервера (httpd.conf).

• Конфигурация виртуального хоста (httpd.conf c версии 2.2, extra/httpd-vhosts.conf).

• Конфигурация уровня директории (.htaccess).

В качестве системы управлениями базами данных выбран MySQL версии 5.5. MySQL - свободная реляционная система управления базами данных. Продукт распространяется как под GNU General Public License, так и под собственной коммерческой лицензией. Помимо этого, разработчики создают функциональность по заказу лицензионных пользователей. Именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

2.2 Работа с базами данных и генерация HTML