46
8) редакторы графического интерфейса.
Инструментальное ПО для планируемого усовершенствования системы
управления обращениями будет выбрано программистом-проектировщиком,
привлеченным для выполнения разработки программных модулей.
1.4.3. Обоснование проектных решений по техническому
обеспечению
Для стабильной работы информационной системы на рабочих станциях к
последним предъявлены следующие требования:
o графический адаптер с поддержкой WDDM (технология для
повышения производительности графики посредством
задействования видеоадаптера) и с наличием 128 Мб видеопамяти;
o минимальный объем ОЗУ – 2048 Мбайт;
o минимальный объем свободного места на устройстве хранения
(hdd, ssd и тд) – 20 Гб;
o процессор - Intel Pentium 4 / Athlon 64 или более поздней версии с
поддержкой SSE2 и тактовой частотой от 1000 МГц;
o наличие монитора, клавиатуры, мыши.
К файловому серверу, на котором хранится непосредственно база
данных, предъявлены следующие минимальные требования:
o минимальный объем ОЗУ – 8 Гб;
o процессор - 4-х ядерный Intel Xeon E3 или аналогичный с тактовой
частотой от 3100 МГц;
o объем свободного места на устройстве хранения зависит от размера
базы данных, рекомендуется не менее 80 ГБ с возможным
последующим расширением.
При активной работе с базой файловая система должна обеспечить
достаточно высокую скорость записи. Этим требованиям удовлетворяет
интерфейс SATA 6Gb/s
47
ГЛАВА 2. ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Определение жизненного цикла входит в число основных определений, на
которых базируется методология проектирования информационной системы.
Жизненный цикл информационной системы - это непрерывный процесс,
который берет свое начало в момент принятия решения о создании
информационной системы и заканчивается в момент вывода системы из
эксплуатации [9, 10].
Существуют три стратегии конструирования информационных систем:
- однократный проход - линейная последовательность этапов
конструирования;
- инкрементная стратегия. В начале процесса определяются все
пользовательские и системные требования, оставшаяся часть конструирования
выполняется в виде последовательности версий. Первая версия реализует часть
запланированных возможностей, следующая версия реализует дополнительные
возможности и т. д., пока не будет получена полная система;
- эволюционная стратегия. Система также строится в виде
последовательности версий, но в начале процесса определены не все требования.
Требования уточняются в результате разработки версий.
Характеристики стратегий конструирования информационной системы
приведены в таблице № 5.
Таблица № 5.
Характеристики стратегий конструирования.
Стратегия
конструирования
В начале процесса
определены все
требования?
Множество циклов
конструирования?
Промежуточное ПО
распространяется?
Однократный
проход
Да
Нет
Нет
Инкрементная
стратегия
Да
Да
Может быть
Эволюционная
Нет
Да
Да
48
Для каждой стратегии существует соответствующая модель жизненного
цикла информационной системы.
Модели жизненного цикла, использующиеся в настоящее время:
1. Каскадная модель учитывает выполнение всех этапов проекта
последовательно и в строго фиксированном порядке. Переход на следующий
этап означает полное завершение работ на предыдущем этапе.
2. Поэтапная модель с промежуточным контролем. Между этапами
разработки проводятся циклы обратной связи на каждую выполненную
итерацию. Межэтапные корректировки дают возможность обращать внимание
на реально существующее влияние результатов разработки друг на друга на
разных этапах; продолжительность жизни каждого этапа растягивается на весь
период разработки.
3. Спиральная модель. На каждом витке спирали создается очередная
версия продукта, происходит уточнение требований проекта, формируются его
качества и планируется работа последующего витка. Большое внимание
уделяется начальным этапам разработки - анализу и проектированию, где
проверяется и обосновывается реализуемость различных технических решений с
помощью использования прототипов (макетирования).
В своей работе мы будем использовать каскадную модель, при которой
жизненный цикл системы автоматизации обработки обращений сводится к
выполнению следующих этапов [6]:
1. Планирование и анализ требований (предпроектная стадия) ─
системный анализ. Проводится исследование и анализ существующей системы
управления обращениями, определяются требования к создаваемой ИС,
формируются функциональная и информационная модели объекта, для которого
предназначена разрабатываемая информационная система.
Системный анализ ИС начинается с описания и анализа
функционирования рассматриваемого объекта в соответствии с требованиями
(целями), которые предъявляются к нему. В результате этого этапа выявляются
недостатки существующей ИС, на основе которых формулируется потребность в
её совершенствовании, и ставится задача определения экономически
обоснованной необходимости автоматизации определенных функций
управления (создается технико-экономическое обоснование проекта ИС). После
49
определения этой потребности происходит выбор направлений
совершенствования объекта на основе выбора программно-технических средств.
Результаты оформляются в виде технического задания на проект, в котором
отражаются технические условия и требования к ИС, а также ограничения на
ресурсы проектирования.
2. Проектирование (техническое и логическое проектирование). В
соответствии с требованиями формируются состав автоматизируемых функций
(функциональная архитектура) и состав обеспечивающих подсистем (системная
архитектура). Создаются представления алгоритмической структуры
программного обеспечения, структуры данных, входного и выходного
интерфейса (входных и выходных форм данных)
Формирование функциональной архитектуры, которая представляет собой
совокупность функциональных подсистем и связей между ними, является
наиболее ответственным и важным этапом с точки зрения качества всей
последующей разработки ИС.
Построение системной архитектуры на основе функциональной
предполагает определение элементов и модулей информационного,
технического, программного обеспечения и других обеспечивающих подсистем,
связей по информации и управлению между выделенными элементами и
разработку технологии обработки информации.
3. Реализация (рабочее и физическое проектирование). Разработка и
настройка программных модулей, формирование и наполнение баз данных,
формулировка рабочих инструкций для персонала, оформление рабочего
проекта информационной системы.
4. Внедрение (опытная эксплуатация). Комплексная отладка подсистем,
обучение персонала новому функционалу, внедрение новой информационной
системы в эксплуатацию по подразделениям организации, проверка
работоспособности элементов и программных модулей проекта, устранение
ошибок на уровне элементов и связей между ними, оформление акта о приемо-
сдаточных испытаниях информационной системы.
Внедрение является общим понятием, и для него существуют разные
стратегии реализации, которые напрямую зависят от срока исполнения и
50
качества ИС, получаемой на выходе. Существуют четыре основные стратегии
внедрения системы:
Параллельная стратегия - когда одновременно работают старая (ручная) и
новая система, и их выходные документы сравниваются. Если они согласуются
длительное время, осуществляется переход на новую систему [7].
"Скачок" - это резкий переход от старой системы к новой без
дополнительных проверок и с полным отказом от старой системы.
"Пилотный проект" это наиболее часто используемая стратегия.
"Пилотный проект" - это тактика "скачка", но применяемая к ограниченному
числу процессов. Область применения стратегии - небольшой участок
деятельности. Такой подход снижает риск и наиболее надежен.
"Узкое место" - это малая часть производственного процесса. При
использовании подхода "узкое место" план внедрения выполняется только для
"узкого места" и для людей, работающих в нем.
В данном дипломной проекте будет применена стратегия “Пилотный
проект”.
5. Эксплуатация (сопровождение, модернизация). Этап сдачи
информационной системы в промышленную эксплуатацию. Организация
проверки проекта на уровне функций, контроля соответствия его требованиям,
сформулированным на стадии системного анализа (сбор рекламаций и
статистики о функционировании ИС), оформление требований к модернизации
ИС и ее выполнение.
Наглядно все этапы цикла представлены на рисунке 6.
Рис.6. Этапы жизненного цикла продукта.
51
Выбранные модель жизненного цикла и стратегия внедрения системы
соответствуют международному стандарту ISO/IEC 12207:2008 Systems and
software engineering - Software life cycle processes. Таким образом, стандарт
ISO/IEC 12207 будет являться основным нормативным документом,
регламентирующим жизненный цикл программного обеспечения.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их
описание
На этапе планирования и анализа требований существует риск
превышения установленных сроков, так как процесс определение требований к
создаваемым доработкам к ИС может затянуться во время в связи с тем, что он
требует непосредственного участия пользователей – работников службы
технической поддержки, а также их руководства.
На этапе проектирования при формировании функциональной и
информационной моделей объекта возможно появление риска неправильно
сформированной архитектуры решения. Это зависит от компетенции работников
проектной группы, а также опыта и знаний разработчика и руководителя
проекта. Неправильное построение системной архитектуры может поставить под
угрозу успешную реализацию проекта в целом [7].
На этапе реализации появляется риск выхода за границы ранее
согласованного бюджета проекта.
На этапе внедрения возможно появление ошибок в работе ИС, которые
выявят ранее не учтенные моменты, необходимые к устранению. Существует
риск того, что проект будет считаться законченным ошибочно, что повлечет за
собой возникновение неполадок в работе ИС.
На этапе эксплуатации рисков быть не должно, при условии, что
сотрудники предприятия ответственно отнесутся к прохождению обучения и в
дальнейшем не будут допускать ошибки при работе с модернизированной
программой.
52
2.1.3. Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
Комплекс мер по защите информации включает в себя следующие
аспекты:
· защита информации непосредственно в информационной системе от
внутренних угроз;
· защита информации от внешних угроз.
Для защиты от внутренних угроз используется политика разделения прав
доступа. Характеристика политики приведена в таблице 6.
Таблица № 6.
Разграничение прав пользователей
Группа
пользователей
Модуль «Управление
обращениями»
Модуль «Статистика»
Сотрудник
Чтение
Ограничен
Руководитель
Чтение
Чтение
Администратор
Полный
Полный
Для защиты от внешних угроз информационной безопасности
используются системы предотвращения вторжений на уровне хоста (HIPS).
Система даёт почти стопроцентный уровень защищённости. Применение
совместно с HIPS антивирусного пакета предоставляют очень высокий уровень
безопасности. Организация получает защиту практически от всех типов
вредоносного ПО, значительно затрудняет работу хакера, решившего
попробовать пробить информационную защиту предприятия, сохраняет
интеллектуальную собственность и важные данные организации [8].
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
На рисунке 7 представлена связь информационных потоков в
разрабатываемой системе, в качестве примера взят конкретный сотрудник –
системный администратор.
53
Рис.7. Связь информационных потоков
54
На рисунке отображены входящие и результатные документы, экранные
формы и справочники с условно-постоянной информации и их взаимосвязи.
Рассмотрим данную модель. На рисунке 8 показан принцип построения
информационной модели и ее условные обозначения [11].
Рис. 8. Пример построения информационной модели
Файл «заявка-N» формируется после ввода специалистом службы
поддержки через экранную форму (ЭФ) «создать заявку». Заявка записывается в
БД заявок, после чего отправляется в подпрограмму распределения заявок, где
определяются ее приоритет и специалист для обработки. Файл с распределением
заявки получает определенный специалист через ЭФ «заявки для обработки», а
также через форму «отправить сообщение заявителю» специалист отправляет
сообщение заявителю о том, что его заявка принята в обработку. Для того, чтобы
закрыть завершенную заявку, специалист обращается к программе через ЭФ
«заявки для обработки» → «выбрать заявку» → «завершить выполнение заявки».
Файл с завешенной заявкой записывается в статистическую БД, с
помощью которой начальник отдела может посмотреть необходимые данные с
помощью ЭФ «статистика» → «выбрать параметры для вывода статистики».
Справочник оценки запросов содержит в себе следующие данные: имя
специалиста, порядковый номер задачи, описание задачи, среднее время
выполнения задачи и ее приоритет. Данный справочник используется для
выбора приоритета задачи, ответственного специалиста и подсчета среднего
времени выполнения задач. Справочник среднего количества заявок по дням
содержит соответствующие данные и используется для расчета вероятностей.
Справочник допустимых показателей качества работы содержит данные
показатели качества работы как сотрудников, так и всего отдела
информатизации, и используется для оценки работы путем сравнения табличных
показателей с реальными.
На рисунке 9 представлен процесс управления обращениями.
55
Рис. 9. Диаграмма IDEF0 процесса управления обращениями.
Главная цель управления обращениями – как можно быстрее
восстановить нормальное функционирование услуг и минимизировать
отрицательное влияние на бизнес-процессы [16]. Примерами обращений могут
быть такие случаи, как неработающий принтер, утеря пароля, ошибка в
приложении и подобные.
Задачами процесса управления обращениями являются:
1. Применение стандартных методов и процедур для оперативного
реагирования, анализа, документирования, текущего управления и составления
отчетности об обращениях;
2. Повышение качества взаимодействия бизнес-заказчиков и ИТ-
персонала в ходе обработки обращений;
3. Согласование деятельности и приоритетов ИТ-подразделений по
управлению обращениями с деятельностью и приоритетами бизнеса;
4. Поддержание удовлетворенности пользователей качеством ИТ-услуг.
2.2.2. Характеристика нормативно-справочной, входной,
оперативной и результатной информации
Процесс управления обращениями начинается с поступления их в
Службу диспетчеров (общая схема указана на рисунке 10). Обращения могут
поступать как от внешних пользователей, так и от внутренних. На основании