42
58
Программа просмотра
файлов Portable
document format
Adobe Reader
версия 9.3.0
Adobe Reader
версия начиная от
10
Требования к аппаратной конфигурации сервера перечислены в табл. 10.
Таблица 10
Аппаратная конфигурация сервера
Наименование
параметра
Характеристика
Процессор
Intel® Xeon® Processor E5620
(12M Cache, 2.40 GHz, 5.86 GT/s Intel® QPI)
64-bit; количество ядер – 4
Материнская плата
S5520HC (для использования в серверных платформах
Intel)
RAID-контроллер
Интегрированный
Жесткие диски
500Gb Seagate (ST3500413AS) 16Mb 7200rpm SATA3
Barracuda (4 шт)
Объем оперативной
памяти
4 Гб (Registered DDR3)
Сеть
2 x 10/100/1000 Мбит/сек. 2х канальный контроллер
Intel 82575EB 10/100/1000 Мбит/с
Имеющиеся в распоряжении предприятия средства полностью
удовлетворяют перечисленным выше требованиям. Дополнительные
приобретения не требуются.
43
2 ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
В качестве стандарта жизненного цикла АРМ САОЗ рассмотрим ГОСТ
34.601-90, который предусматривает следующие стадии и этапы создания
автоматизированной системы [1]:
1) Формирование требований к АРМ САОЗ:
– обследование объекта и обоснование необходимости создания АРМ;
– формирование требований пользователя к АРМ;
– оформление отчета о выполнении работ и заявки на разработку АРМ
САОЗ;
2) Разработка концепции АРМ САОЗ:
– изучение объекта;
– проведение необходимых научно-исследовательских работ;
– разработка вариантов концепции АРМ и выбор варианта концепции,
удовлетворяющего требованиям пользователей;
– оформление отчета о проделанной работе;
3) Техническое задание:
– разработка и утверждение технического задания на создание ИС;
4) Эскизный проект:
– разработка предварительных проектных решений по системе и ее
частям;
– разработка документации на АРМ САОЗ и ее части;
5) Технический проект:
– разработка проектных решений по системе и ее частям;
– разработка документации на АРМ САОЗ и ее части;
– разработка и оформление документации на поставку комплектующих
изделий;
– разработка заданий на проектирование в смежных частях проекта;
44
6) Рабочая документация:
– разработка рабочей документации на АРМ САОЗ и ее части;
– разработка и адаптация программ;
7) Ввод в действие:
– подготовка объекта автоматизации;
– подготовка персонала;
– комплектация АРМ САОЗ поставляемыми изделиями (программными и
техническими средствами, программно-техническими комплексами,
информационными изделиями);
– строительно-монтажные работы;
– пусконаладочные работы;
– проведение предварительных испытаний;
– проведение опытной эксплуатации;
– проведение приемочных испытаний;
8) Сопровождение АРМ САОЗ:
– выполнение работ в соответствии с гарантийными обязательствами;
– послегарантийное обслуживание.
При этом эскизный, технический проекты и рабочая документация — это
последовательное построение все более точных проектных решений.
Допускается исключать стадию "Эскизный проект" и отдельные этапы работ на
всех стадиях, объединять стадии "Технический проект" и "Рабочая
документация" в "Технорабочий проект", параллельно выполнять различные
этапы и работы, включать дополнительные.
Описания действий и задач на каждом этапе жизненного цикла и
последовательности выполнения стадий и этапов называют моделью
жизненного цикла.
Модель фактически отражает различные состояния системы: ее
разработку, функционирование и сопровождение в течение всей жизни АРМ
САОЗ.
При разработке АРМ САОЗ санатория ООО «Белое озеро» используем
45
каскадную модель (рис. 11.), предусматривающую последовательное
выполнение всех вышеуказанных этапов в строго фиксированном порядке,
причем переход на следующий этап возможен только после полного
завершения пре дыдущего.
Рисунок 11 – Каскадная модель жизненного цикла АРМ САОЗ
Таким образом, эта модель предполагает разработку законченных
продуктов на каждом этапе, что фактически исключает какое-либо изменение
или уточнение требований пользователей.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Риски на подэтапе "Определение требований к ИС". Основной риск на
данном подэтапе это недостаточное определение свойств АРМ САОЗ,
требуемых для решения задачи и неправильный выбор задач проектирования
(недостаточный объем задач автоматизации). Это может потребовать, на этапе
46
эксплуатации, дополнительной доработки АРМ САОЗ, что приведет к
финансовому риску. Риск предотвращается использованием современных case-
средств при моделировании бизнес-процессов. При возникновении такого
риска проводится дополнительное моделирование с использованием case-
средств (BPWin, ERWin).
На подэтапе "Определение функций ИС и стратегий автоматизации"
основной риск – неправильное определение функций АРМ САОЗ и стратегии
автоматизации. На данном подэтапе существует риск неправильного выбора
варианта (приобретение готовой ИС или собственная разработка). Риск
предотвращается основательным анализом всех вариантов. В случае
возникновения, риск устраняется проведением повторного анализа вариантов
выбора.
Риски на подэтапе "Разработка проекта автоматизации". Основной риск –
неэффективный план-график автоматизации: недостаточность ресурсов.
Данный риск является финансовым, предотвращается использованием
современных автоматизированных средств проектирования. В случае
возникновения, риск устраняется повторной корректировкой плана-графика
автоматизации.
На подэтапе "Разработка информационного обеспечения задачи"
основные риски – это разработка неправильной информационной модели и
неудобных для пользователя прототипов экранных форм. Риск
предотвращается по согласованию прототипов экранных форм с будущими
пользователями, а устраняется дополнительной доработкой экранных форм
АРМ САОЗ.
На подэтапе "Подготовка к разработке ПО" основной риск –неправильная
формализация расчетов показателей. Риск устраняется тестированием
программных модулей АРМ САОЗ на этапе внедрения.
На подэтапе "Разработка программного обеспечения" основной риск
заключается в некорректной разработке программы. Риск устраняется
посредством использования для программирования последней обновленной
47
версией Денвера [9]. Необходимо учитывать также то, что программные
модули будут тестироваться на этапе внедрения.
Риск на этапе "Внедрение" – некорректное тестирование технического
обеспечения программных модулей АРМ САОЗ. Риск предотвращается
использованием лицензионного стендового оборудования, а устраняется
двойным тестированием.
На этапе "Сопровождение" основные риски – выход из строя
оборудования и моральное устаревание ПО. Первый риск предотвращается
регулярным мониторингом состояния оборудования. Второй риск
предотвращается посредством гибкости разработанного АРМ САОЗ и
своевременной доработкой программной архитектуры.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
При эксплуатации АРМ САОЗ с целью защиты от внутренних угроз
определяются следующие группы пользователей (табл. 11)
Таблица 11
Разграничение прав пользователей
Группы
пользоват
елей
Пода
ча
заяв
ки
Просм
отр
заявок
Формиров
ание
отчетности
Измене
ние
пароля
Доступ к
физичес
кой БД
Доступ
в
Intern
et
Пользовател
и
да
нет
нет
нет
нет
Огранич
ен
1
Руководство
да
нет
да
нет
нет
Огранич
ен
Системный
администрат
ор
да
да
да
да
да
Не
огранич
ен
С целью защиты от внешних угроз применяется аутентификация
пользователей (логин и пароль) для входа в АРМ САОЗ.
С целью защиты базы данных необходимо регулярное резервное
1
Сайт helpdesk входит в число разрешенных к посещению
48
копирование, что позволит в случае необходимости выполнить восстановление
информации.
Из программно-аппаратных средств наряду со стандартным фаерволом
операционной системы сервера может применяться Web Application Firewall –
защитный экран уровня приложений, предназначенный для выявления и
блокирования современных атак на веб-приложения [14].
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
В процессе разработки концептуальной информационной модели
предметной области было определено 6 сущностей: должности; неисправности;
оборудование; отделы; сообщения; сотрудники.
ER-диаграмма в разрезе сущность-связь [33] в нотации Information
Engineering, построенная в программном средстве ERwin Data Modeler [8]
приведена на рис. 12.
Рисунок 12 – Сущности БД АРМ САПЗ
49
Исходя из анализа предметной области, можно выделить следующие
бизнес-правила процесса службы поддержки.
1. Каждый тип оборудования имеет уникальный идентификатор.
2. Один тип оборудования может иметь несколько характерных
неисправностей.
3. Каждая неисправность имеет уникальный идентификатор.
4. Каждая неисправность может относиться только к какому-то одному
типу оборудования.
5. Каждый отдел (подразделение) имеет уникальный идентификатор.
6. Каждая должность сотрудника имеет уникальный идентификатор.
7. Каждый сотрудник имеет уникальный идентификатор.
8. Каждый сотрудник занимает конкретную одну должность и входит в
штат определенного отдела.
9. Одну и ту же должность могут иметь несколько сотрудников.
10. Каждый отдел может содержать множество сотрудников.
11. Один и тот же сотрудник может отправлять сообщения в службу
поддержки множество раз.
12. Одна и та же проблема может прявляться множество раз.
13. Один и тот же тип оборудования может быть источником проблем
множество раз.
14. Каждое сообщение в службу поддержки имеет уникальный
идентификатор, дату и время обращения.
15. Некоторые сотрудники могут не обращаться в службу поддержки ни
разу.
Также существуют следующие ограничения.
1. Идентификатор оборудования не может быть пустым.
2.Наименование оборудования не может быть пустым.
3. Идентификатор неисправности не может быть пустым.
4. Наименование неисправности не может быть пустым.
5. Идентификатор отдела не может быть пустым.
50
6. Наименование отдела не может быть пустым.
7. Идентификатор должности не может быть пустым.
8. Наименование должности не может быть пустым.
9. Идентификатор сотрудника не может быть пустым.
10. ФИО, инициалы сотрудника, принадлежность к штатному расписанию
не могут быть пустыми.
11. Дата и время сообщения не могут быть пустыми.
12. Закрытая заявка характеризуется датой и временем закрытия, которые
не могут быть пустыми.
13. Все заявки прошлых периодов должны оставаться в системе.
Исходя из бизнес-правил и ограничений прежметной области,
перечислим соответствующие атрибуты каждой сущности.
1) Сущности "Должности" соответствуют следующие атрибуты: код
должности; наименование должности.
2) Сущности "Неисправности" соответствуют следующие атрибуты: код
неисправности товара; наименование неисправности; код оборудования;
характеристика неисправности.
3) Сущности "Оборудование" соответствуют следующие атрибуты: код
оборудования; наименование оборудования.
4) Сущности "Отделы" соответствуют следующие атрибуты: код одела;
наименование одела.
5) Сущности "Сообщения" соответствуют следующие атрибуты: номер
собщения; дата сообщения; время сообщения; признак закрытия; код
неисправности; код сотрудника; описание проблемы; дата закрытия; время
закрытия.
6) Сущности "Сотрудники" соответствуют следующие атрибуты: код
сотрудника; код одела; код должности; ФИО; инициалы; дата рождения; e-mail;
имя пользователя в системе; пароль пользователя в системе; телефон.
ER-диаграмма в разрезе атрибутов приведена на рис. 13.
51
Рисунок 13 – ER-диаграмма БД АРМ САПЗ
Как видно из рис. 13, ER-диаграмма содержит 5 связей:
1) Должности-Сотрудники. Сущность "Должности" выступает главной, а
"Сотрудники" – подчиненной. Связь осуществляется по ключевому полю код
должности. Тип связи – "один-ко-многим".
2) Отделы-Сотрудники. Сущность "Отделы" выступает главной, а
"Сотрудники" – подчиненной. Связь осуществляется по ключевому полю код
отдела. Тип связи – "один-ко-многим".
3) Оборудование-Неисправности. Сущность "Оборудование" выступает
главной, а "Неисправности" – подчиненной. Связь осуществляется по
ключевому полю тип оборудования. Тип связи – "один-ко-многим".
4) Сотрудники-Сообщения. Сущность "Сотрудники" выступает главной, а
"Сообщения" – подчиненной. Связь осуществляется по ключевому полю код