Разработка архитектуры информационной системы технической поддержки МКА с использованием моделейв нотации UML 2

Ковтунова Е.М.
Выпускник группы ITM-27
Школа IT-менеджмента
РАНХиГС при Президенте РФ

Введение

Департамент разработки и интеграции информационных систем (далее Разработчик) занимается разработкой, внедрением и сопровождением информационных систем (далее ИС) и ресурсов МКА (Комитета по архитектуре и градостроительству города Москвы). В процесс работы выросло количество пользователей ИС и ресурсов МКА, ужесточились требования к качеству технической поддержки пользователей и возникла необходимость в выделении службы технической поддержки (далее СТП) в отдельное подразделение, а также обеспечении специалистов разработчика информационной системой технической поддержки (далее ИС ТП) для более эффективной работы.

Актуальность проблемы заключается в том, что принятие своевременных мер по повышению уровня технической поддержки пользователей ИС и ресурсов МКА позволяет сохранить крупного заказчика и избежать затрат на поиски новых.

Объект проектного исследования – информационная система технической поддержки.

Предмет проектного исследования – процесс оказания помощи пользователям ИС и ресурсов МКА.

Цель исследования – разработать архитектуру с помощьюнотации UML 2 на основе стандарта ITIL и внедрить ИС ТП. Для достижения этой цели необходимо решить следующие задачи:

-Описать комплекс решаемых задач СТП и обосновать необходимость создания ИС ТП с помощью ITIL;

-Обосновать выбор нотации UML 2 для моделирования архитектуры ИС ТП;

-Разработать проект реализации ИС ТП на основе Redmineи обосновать выбранное решение;

-Протестировать ИС ТП и подвести результаты использования разработанной архитектуры ИС ТП.

Глава 1. Организация ИС ТП

1.1  О компании

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

При разработке ИС для МКА Разработчик (Департамент разработки и интеграции информационных систем) ориентировался на собственные нужды и ставил приоритет на технических вопросах, а не на вопросах дальнейшего сопровождения. Возникла очень важная проблема – отсутствие ответственных за работу с пользователями специалистов.

Сделав выводы из сложившейся ситуации, Разработчик сосредоточился на создании ИС ТПдля СТП для чего необходимо решить следующие задачи:

-Разработать схему процесса обработки обращений;

-Разработать архитектуру ИС ТП;

-Настроить интерфейс для доступа к данным ИС ТП (консоль специалиста).

Глава 2. Выбор метода моделирования архитектуры ИС ТП

Создание СТП – это в первую очередь четкое определение:

-Правил взаимодействия пользователей с Разработчиком,

-Правил работы специалистов СТП,

-Правил взаимодействия специалистов СТП между собой.

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

2.1  Сравнение различных нотаций

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

2.2  Анализ систем разработки бизнес-процессов нотации UML

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

2.3  Выбор диаграммы

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

В RUP выделяются две основные модели в процессе бизнес-моделирования [9]:

-Модель бизнес-вариантов использования, которая описывает внешние взаимодействия организации с точки зрения бизнеса;

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

Аналитическая бизнес-модель описывает внутреннее функционирование бизнеса. Модель предназначена для анализа бизнес-процессов и потоков операций. Для анализа статической части архитектуры используется диаграмма классов.

Глава 3. Реализация ИС ТП

3.1  Архитектура СТП

На основе проведенного сбора данных разработаны общие правила регистрации обращений:

-Для одного обращения может быть зарегистрировано более однойзаявки в ИС ТП (Инцидента, Запроса на обслуживание);

-К одному обращению в ИС ТП может быть привязано более одной заявки;

-В рамках обращения может быть не зарегистрировано ни одной заявки;

-Заявка может быть зарегистрирована как в рамках обращения, так и независимо от наличия обращения (системный Инцидент).

-Сотрудник 1-ой линии, принявший обращение, является исполнителем данного обращения;

-Обращения на 1-ю и 2-ю линии ТП обрабатываются в порядке их поступления. Максимальный срок реакции на обращение определяется установленным уровнем критичности.

-Время решения заявки может зависеть от критичности обращения. Уровень критичности обращений совпадает с уровнем критичности пользователя, от имени которого оформленазаявка;

-Для обработки обращений пользователей каждому пользователю как инициатору обращения в 1-ой и 2-ой линии ТП по умолчанию присваивается соответствующий уровень критичности.

На основе общих правил регистрации обращений разработана архитектура СТП ИС и ресурсов МКА.

3.2  Схема процесса обработки обращений

1-я линия СТП занимается регистрацией обращений и обработка заявок, поступающих от пользователей ИС и ресурсов МКА. Эскалация на2-ю линиюСТП (администраторы и системные инженеры)производится в случае необходимости. В случае невозможности решения инцидента специалистами 2-ой линии СТП производится передача заявки специалистам Разработчика (3-я линия СТП).

3.3  Архитектура ИС ТП

ИС ТП,реализованная на основе Рэдмайн, решает вопросы автоматизации процесса управления обращениями в СТП. Разработаннаяв рамках дипломного проекта архитектура системы.

Глава 4. Внедрение ИС ТП

Очень хорошо показала себя при тестировании консоль с нейудобно работать без особых средств из любой точки сети. ИС ТП показала себя с лучшей стороны.

Заключение

Цель дипломной работы«Разработка архитектуры информационной системы технической поддержки МКА с использованием моделей в нотации UML 2» – достигнута.

1. Проведен глубокий анализ проблемы с учетом накопившегося опыта в решении поступающих разработчику обращений пользователей ИС и ресурсов МКА.

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

3. Проведен сравнительный анализ методов моделирования архитектуры ИС с учетом опыта их использования специалистами разработчика.

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

5. Предложена архитектура СТП разработанная с учетом особенностей в процессе поступления обращений от пользователей и рекомендаций ITIL.

6. Предложена архитектура ИС ТП с учетом используемых разработчиком технических решений.

7. Проведено тестирование настроенной в соответствии с разработанной архитектурой ИС ТП консоли специалиста СТП.

8. Произведена доработка консоли в соответствии с выявленными в процессе тестирования недочетами.

9. Произведена реорганизация компании с учетом внедренных успешных практик.