Дипломная работа: Автоматизация учета и обработки заявок пользователей на техническую поддержку (Help Desk) в ООО "Сфера ИТ"
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
41
решения, обоснование необходимости автоматизации описанного процесса.
Проведен анализ существующих программных и технических решений, обосно-
вание выбора определенных решений и выбор стратегии автоматизации про-
цесса регистрации, обработки и учета заявок на техническую поддержку от кли-
ентов.
42
2. Проектная часть
2.1. Разработка проекта автоматизации
Этапы жизненного цикла проекта автоматизации
Жизненный цикл (далее – ЖЦ) проекта автоматизации регламентируется
разными моделями и стандартами. Основные из интерациональных это: MSF,
RUP, COBIT, XP.
Стандарт COBIT сразу отбрасываем, он не подходят под мои цели, так
как используется для проведения аудита и стратегического планирования ИС и
IT инфраструктуры в целом. Обобщим основные характеристики в таблицу –
таблица 7.
Таблица 7
Основные показатели стандартов ЖЦ ИС
Стандарт
Команда,
чел.
Соответ-
ствие стан-
дартам
Допустимые
технологии
и инстру-
менты
Удобство
модифика-
ции и сопро-
вождения
MSF
адаптируема
любые
Удобно
RUP
стандарты
UML и
продукты
Удобно (RUP)
XP
нет
любые
Сложно
Выбор пал на Microsoft Solutions Framework (MSF) как наиболее сбалан-
сированную технологию, наиболее гибкую и удобную.
В идеологии MSF существует 5 стадий жизненного цикла ИС, которые в
понятии MSF называют фазами. Первый из них это Фаза выработки концепции.
Целью данной фазы является выработка единого видения, через которую проис-
ходит сплочение проектной группы. Команда должно делиться на 6 участников,
у каждого своя роль в проекте. Роли, отведенные участникам – кластеры: Управ-
ление продуктом, Управление программой, Разработка, Удовлетворение потре-
бителя, Тестирование, Управление выпуском. В моём проекте задачи кластеров
43
объединены и расформированы на трех ответственных лиц. Итогом этапа явля-
ется подбор ответственных сотрудников и распределение задач.
Следующий этап – фаза планирования. Фаза включает в себя подготовку
функциональной спецификации, разработку дизайнов, подготовку рабочих пла-
нов, оценку затрат и сроков. Результаты фазы: функциональная спецификация,
Описание возможных рисков, сводный план и сводный календарный график про-
екта, развернутые среды разработки и тестирования. Программист должен вы-
брать язык программирования. Должна быть продумана вся архитектура ИС.
Далее идет фаза разработки. Проектная группа фокусируется на создании
компонент решения. Результат: исходный и исполнимый код приложений,
скрипты установки и конфигурирования, окончательное описание функционала
разрабатываемого решения, материалы поддержки решения, сценарии тестов.
Следующий этап – фаза стабилизации. Тестирование разработанного ре-
шения. Проектная группа устраняет ошибки и подготавливает решение к вы-
пуску. Результат фазы: окончательный продукт, документация выпуска, матери-
алы поддержки решения, результаты и инструментарий тестирования, исходный
и исполнимый код приложений, проектная документация.
Фаза внедрения. Решение стабилизируется и передается в работу персо-
налу. По завершении фазы проектная группа анализирует выполненную работу
и удовлетворенность заказчика. Для внедрения есть разные стратегии, мной была
выбрана параллельная стратегия. В ней одновременно работают старая система
и новая. Результаты работы сравниваются, и, если проблем не обнаружено, по-
степенно происходит переход на новую систему.
Следующий этап – этап эксплуатации. Работа программы отслеживается
каждые 2-3 часа. По результатам принимается решение о необходимости дора-
ботки программного обеспечения.
Ожидаемые риски на этапах жизненного цикла и их описание
При использовании стандарта MSF риски минимизированы, потому что
ЖЦ разделен на этапы, на каждом этапе есть роли, за которыми закреплены цели,
44
которые достигаются в каждой фазе. Но риски возникнуть могут. Сведем воз-
можные риски в таблицу (таблица 8).
Таблица 8
Риски на этапах ЖЦ
Фаза
Риски
Меры
Выработки кон-
цепции
Недальновидный
анализ сроков про-
екта и его бюджета
Нужно более детально прорабаты-
вать задачи и цели проекта, ставить
больше
контрольных точек.
Неправильно подо-
бранный проект-
ный состав испол-
нителей
Более тщательный подбор специали-
стов в проектную группу тестирова-
нием не только
профессиональных навыков, но и
личностных качеств.
Планирования
Неправильно или
не совсем кор-
ректно сформиро-
ванное архитек-
тура выбираемого
решения
Зависит от компетенции руководи-
теля проекта, на котором лежит при-
нятие решение
о выборе архитектуры разрабатыва-
емого решения
Разработки
Неправильная ин-
терпретация техни-
ческого задания и
как следствие не-
правильная про-
граммирование ар-
хитектуры и
сдвиг сроков
Более чёткое написание техниче-
ского задания, понятного программи-
сту
Отсутствие долж-
ной квалификации
у программиста в
том
языке, на котором
решено реализовы-
вать программу
Придется
использовать внешнего разработ-
чика, так называемый “аутсорсинг”
или “фриланс”
Тестирования
Риски неокончен-
ного тестирования
Решается путем повторного тестиро-
вания на следующей итерации разра-
ботки.
Внедрения
Риски неправиль-
ного принятия ре-
шения о закончен-
ности части про-
екта
Устраняется путем доработки при
следующей итерации
45
Организационно-правовые и программно-аппаратные средства обес-
печения информационной безопасности и защиты информации
В компании в зависимости от угроз безопасности информации введено в
действие несколько концепций обеспечения информационной безопасности.
Внутренние угрозы. Права пользователей информационной системы
OTRS разграничены по группам. Матрица доступа в таблице 9
Таблица 9
Матрица доступа
Группа
пользовате-
лей
Создание
заявки
Редактиро-
вание своей
заявки
Переназна-
чение за-
явки
Работа с ба-
зой знаний
Сетевая
группа
Чтение
Есть
Есть
Создание,
чтение, уда-
ление
Группа под-
держки поль-
зователей
Чтение
Есть
Нет
Создание,
чтение, уда-
ление
Горячая ли-
ния
Создание,
чтение, уда-
ление
Есть
Есть
Чтение
Пользователи системы разнесены в группы согласно обязанностям. Учет-
ные данные для входа в системы выданы каждому пользователю системы инди-
видуально. Вход на рабочие станции осуществляется по доменной авторизации.
Настроены политики парольной защиты и блокировки рабочего стола. Межсете-
вое экранирование в компании организовано с помощью сертифицированного
ФСТЭК России и ФСБ России межсетевого экрана. Возможный нарушитель
имеет низкий уровень потенциала по реализации угроз безопасности информа-
ции, поэтому принятых мер достаточно. Предполагается, что потенциальный
нарушитель не может вступить в сговор с администраторами информационной
системы.
Источник: https://baza.diplomsite.ru/previewfile/2374