73
проектирования. На данных этапах реализуемость технических решений
проверяется посредством создания прототипов. Каждый из витков спирали
соответствует созданию фрагмента, или версии программного обеспечения, на нем
уточняют цели и характеристики проекта, определяют его качество и
планируют работы следующего витка спирали. В итоге углубляются и
конкретизируются основные детали проекта и затем выбирают более
подходящий вариант, доводят его до реализации.
Разработка итерациями отражает существующий объективно спиральный цикл
при создании системы. Неполное завершение работ на отдельных этапах позволяет
переходить на следующие этапы, не дожидаясь завершения работ на текущем
этапе. При применении итеративного способа разработки недостающую работу
можно выполнить на следующей итерации. Основной задачей является задача по
возможности как можно скорее дать пользователям вполне работоспособный
продукт, активизируя уточнение и дополнение существующих требований.
Главная проблема спирального цикла состоит в определении момента перехода на
очередной из этапов. Для ее решения требуется ввести временные ограничения на
все этапы жизненного цикла. Переход проводится в полном соответствии с
существующим планом, если даже не вся работа была завершена. План
составляется на основе существующих статистических данных, которые были
получены в предыдущих проектах, и опыта разработчиков. На рис. № 10 дано
графическое изображение спиральной модели цикла ИС.
74
Рис 10. Спиральная модель ЖЦ ИС
Наиболее оптимальной я считаю спиральную модель, поскольку в ней учтены
недостатки задачной и каскадной модели. В рамках доработки ИС часто на
практике возникают новые замечания от пользователей. Их можно успешно
реализовать на новом витке применяемой спиральной модели.
2.1.2 Ожидаемые риски на разных этапах жизненного цикла и их
описание
Стандарт MSF даёт гарантию снижения существующих на практике рисков,
поскольку ЖЦ проекта разделён на разные составные этапы, и на каждом из них
существуют свои определенные роли, за которыми закреплены цели, которые
должны быть достигнуты. Но при этом на каждой фазе есть свои риски:
В фазе выработки концепции могут возникнуть такие риски:
● Неправильно подобранный проектный состав исполнителей может повлечь
отсутствие командной работы. Риск можно снизить за счет правильного
подбора специалистов проектной группы. Это можно сделать за счет
тестирования навыков работы и проверки личных качеств претендентов.
● Недальновидный анализ сроков проекта и имеющегося у него бюджета
Для ликвидации риска требуется несколько детальнее прорабатывать задачи и цели
проекта, ставить большее число контрольных точек.
На фазе планирования могут возникнуть такие риски:
75
● Неправильно сформированное архитектура решения
Возможность появления риска зависит от компетенции руководителя
определенного проекта.
В фазе разработки возможны такие риски:
● Неправильная интерпретация существующего технического задания, что в
итоге ведет к получению неправильной архитектуры и к сдвигу сроков.
Минимизацией указанного риска на практике служит чёткое написание
технического задания, понятного для программиста.
● Отсутствие необходимой квалификации у программиста в том языке, на
котором решено реализовывать программу клиент.
В таком случае можно заказать услуги внешнего разработчика через фриланс или
аутсорсинг.
В фазе тестирования могут возникнуть такие риски:
● Риск незавершенного тестирования.
Может случиться так, что программный продукт окажется не до конца
протестированным.
Решение достигается на практике посредством проведения повторного
тестирования на следующей итерации разработки.
В фазе внедрения могут наблюдаться такие риски:
● Риски неправильного принятия решения о завершении части проекта.
Появление этих рисков приводит к незавершенности принимаемого решения и
влечет появление возникновения нестыковок с другими составными частями ИС.
Устраняется посредством доработки при следующей итерации.
76
2.1.3. Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
Для этого комплекса задач существует несколько видов практической реализации
информационной безопасности.
Обеспечение защиты от существующих внутренних угроз. Подразумевает
разграничение прав пользователей ИС HP OpenView Service Desk. Права
пользователей даны в табл. 11
Табл. 11
Разграничение прав пользователей.
Пользовател
ьские
группы
Создание заявок
Возможность
редактирован
ия заявки
Возможност
ь
переназначи
ть
поданную
заявку
Работа с базой
знаний
Сетевая
группа
Чтение
+
+
Чтение/создани
е/удаление
Группа
поддержки
пользователе
й
Чтение
+
-
Чтение/удалени
е
Горячая
линия
Чтение/создание/удален
ие
+
+
Чтение
2. Защита от внешних угроз реализуется такими параметрами:
Серверные системы предприятия не имеют сторонних средств удаленного
администрирования, например Remote administrator. Доступ организован на
практике посредством Remote desktop protocol, на требуемый сервер, в том числе
77
на сервер приложений и СУБД, где размещена ИС HP open view Service Desk, вход
осуществляется на практике лишь по доменной авторизации в соответствии с
уровнем доступа, который согласуется по заявке на горячую линию.
3) На предприятии «Логика Бизнеса» применяют разные методы обеспечения
защиты сведений, поскольку на деле не существует какого-то определенного
уникального метода, который дает возможность обеспечить информационную
безопасность, а сочетание разных применяемых методов позволяет в итоге
реализовать на практике максимум информационной безопасности.
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
На рис. 11 дана Информационная модель дипломного проекта, она представлена в
виде следующей схемы.
Рис. 11. Информационная модель
Эта модель включает несколько источников. Основная БД в данном случае - это
ИС HP OpenView Service Desk. В ней есть таблицы текущих заявок, справочники
Исполнителей, заявителей - это сотрудники фирмы, которые обращаются со
своими проблемами на горячую линию, в т. ч. из различных регионов. Процесс
78
обращения пользователей на горячую линию реализуется на практике через
письма, идущие на горячую линию, что отражается в том числе на
Информационной модели. Разработанная в дипломном проекте служба (сервис)
обрабатывает почту, находя новые заявки и обрабатывая письма, которые связаны
с зарегистрированными заявками. Служба обращается к HP OpenView Service Desk,
в рамках которой существуют специальные таблички для осуществления учета и
получения статистики и добавления справочника ключевых слов. Основная
таблица в этой БД - это таблица зарегистрированных заявок. В ней фиксируется в
том числе то, что обработано службой и является основой в дипломном проекте.
Для классификации существующей проблемы по тексту письма, исполнителей
заявки (ИТ специалистов) и группы (департамента), к которым принадлежит
исполнитель, спроектированы таблицы: IT_Group, It Worker, Klassification.
2.2.2 Характеристика нормативно-справочной, входной и
оперативной информации
В дипломном проекте применяются лишь входящие файлы и справочники.
Входящий файл представляет собой письмо(заявку) на почту горячей линии
общества с ограниченной ответственностью «Логика Бизнеса». Письмо
представляет неструктурированный текст с описанием имеющейся на данный
момент неисправности, отправитель по умолчанию оказывается при этом
заявителем, если этот пользователь отсутствует в HP open View Service Desk, он в
этом случае добавляется в справочник пользователей вручную. Добавление в
справочник производит специалист отделка горячей линии предприятия. Письмо
включает в себя текст, который распознается процедурой классификации
инцидентов. В теле письма может быть также описание того, для какого
сотрудника должно быть реализована заявка, данная информация определяется на
основе алгоритма классификации инцидентов. Примеры писем на горячую линию
можно увидеть на рис. 12, 13.
79
Рис. № 12 Письмо на горячую линию предприятия с просьбой заменить картридж
Справочником для регистрации заявок является таблица классификации заявок,
которая включает в себя базу знаний, по которой на основании существующего
регламента назначаются, согласовываются и впоследствии исполняются заявки на
предприятии.
Справочник «Классификация» включает в себя такие поля:
1. дата (ежедневно с учетом работы подразделений создают новые записи)
2.Код (ключевое поле, позволяющее уникально идентифицировать запись);
3.Ключевая фраза/слово (список синтаксических выражений, полных и неполных,
классифицирующих существующую проблему);
4. Код группы (идентифицирует тот или иной конкретный отдел ИТ;
5. Код специалиста (непосредственного исполнителя, руководителями ежедневно
присылается отчёт о присутствии, исходя их него назначаются исполнители на
полученные заявки);
6. Согласование. поле имеет тип Истина/ложь;
На основе отчетов о присутствии и устоявшейся базы знаний, подаваемых
ежедневно, соответственно каждый день формируется справочник классификации.
2.2.3 Характеристика результатной информации
В дипломном проекте результирующей информацией являются два отчета:
1. «Отчет по согласованным заявкам»
80
Формируют данный отчет на основе следующих полей и таблиц:
● Дата создания новой заявки
● Пользователь (заявитель)
● Ответственная за выполнение данной заявки группа
● Назначенный сотрудник
● Статус исполнения данной заявки
● Исходное письмо (тема и тело письма даются при этом в оригинале)
2. Отчет ”заявки по местоположению заявителя”:
Включает в себя таблицу с полями:
● Дата создания новой заявки
● Даты писем по согласованию
● Пользователь (заявитель)
● Месторасположение заявителя (город)
● Адрес заявителя
● Ответственная за выполнение данной заявки группа
● Текущий статус переписки и зарегистрирована ли была заявка
● Приложенное письмо (тема и тело письма в оригинале)
Такие отчеты служат в первую очередь для составления итоговой статистики . В
меньшей степени они служат целью оперативного управления и принятия
решений, а Информация является уточняющей. По ведомости за месяц в итоге есть
возможность уточнить, насколько оказалась в течение данного периода времени
загруженной горячая линия по регистрации заявок. Можно также получить
сведения о том, много ли ошибок при регистрации допускает служба. На рис. 14
дан скриншот Журнала Созданных заявок за 1/3/6 час.».
81
Рис. № 14 «Журнал Созданных заявок в одну итерацию за 1/3/6 часов»
2.3 Программное обеспечение задачи
2.3.1 Общие положения (дерево функций и сценарий диалога)
В дипломном проекте я автоматизирую часть Информационной системы, а именно
рутинную работу, которую осуществляют на практике работники отдела горячей
линии предприятия, вместо выполнения своих прямых обязанностей. Основное
окно программы предоставляет статистические сведения об обработке
поступивших на горячую линию предприятия писем, и о письмах, которые на
данный момент времени находятся на согласовании. Сценарий диалога дан на рис.
15.
.
82
Рис. 15 Сценарий Диалога работы программы
Программа в соответствии с существующей в ней логикой обрабатывает письма,
проверяя при этом их содержимое и согласовывая доступ и закупку. В программе
существует возможность просмотра истории обработанных писем и отмены
созданных заявок.
Функционал программы можно подразделить на основной, при помощи которого
можно достичь основной цели алгоритма программы и дополнительный
(Служебный) - он представляет собой то, что можно настроить изменить. Дерево
функций показывает разделение функций. Дерево функций дано на рис. 16.