57
Для управления справочниками, просмотра журнала работы, получения
справочной информации по настройке или работе разрабатываемой ИС,
требуется персональный компьютер под управлением ОС, имеющей
графическую пользовательскую среду.
Учитывая, что разрабатываемая ИС не предполагает производства
сложных вычислений, а направлена на манипулирование информацией, особые
требования к вычислительной мощности персонального компьютера или
рабочей станции, не применяются: для нормальной работы ИС, исходя из
нагрузочных графиков, построенных IDE MS Visual Studio при тестировании
типовых алгоритмов манипулирования данными, такими как запрос в БД,
отображение результатов на форме, фильтрация данных и т.п. - (рисунок 8),
достаточно компьютера с процессором Intel Celeron с процессором 1.7 гГц,
оперативной памятью 512мБ и дисковым пространством в пределах 150гБ.
Рисунок 8. Нагрузочный график, построенный MS Visual Studio
Проанализировав имеющееся техническое обеспечение организации, было
установлено, что на предприятии организована локальная вычислительная сеть,
через которую организован доступ в Интернет с телефонной станции, серверов,
а также со всех рабочих мест, оборудованных персональными компьютерами,
через маршрутизатор с применением NAT.
58
Телефонная станция является IP PBX системой, развернутой на IBM PC
совместимом компьютере с процессором Intel Core i7 3.2 гГц, восьмью гБ
оперативной памяти и дисковым пространством четыре тБ, под управлением
операционной системы Linux CentOS 7, без использования среды графического
пользовательского интерфейса. Станция подключена к локальной сети, через
которую организован доступ в Интернет.
Рабочее место специалиста, ответственного за работу телефонной станции,
оборудовано персональным компьютером с процессором Intel Core i5,
оперативной памятью 8гБ и дисковым пространством 2тБ, под управлением
операционной системы Microsoft Windows 10. Компьютер подключен к
локальной сети, доступ в Интернет организован через данную сеть.
Исходя из анализа существующего технического обеспечения
организации, было выявлено, что для выполнения разрабатываемой
информационной системы и поставленных ей задач не требуется какого-либо
дополнительного технического обеспечения.
А именно, для работы глобального модуля proxy-службы требуется
работающая телефонная станция, базируемая на среде Linux, а также СУБД
MySQL, графическая оболочка не требуется. Как указывалось ранее, телефонная
станция предприятия базируется на Linux CentOS 7 без графической
подсистемы, для обеспечения внутренних процессов работы станции
используется СУБД MySQL 5. Компьютер с развернутой на его базе телефонной
станции подключен к локальной вычислительной сети предприятия с доступом
в сеть Интернет. Указанное обеспечение полностью перекрывает требования
модуля: возможность подключения к телефонной станции, возможность доступа
к СУБД, возможность передачи результатной информации CRM системе.
Для работы глобального модуля графического пользовательского
интерфейса, задача которого организовать наполнение справочников
специалистом, обслуживающем телефонную станцию, а также возможность
отображения результатной информации и справочной системы, требуется
операционная система Windows 7 /10 и доступ к локальной сети предприятия для
59
организации возможности подключения к СУБД MySQL. Данные требования
удовлетворяет рабочее место специалиста по телефонной станции,
оборудованное персональным компьютером хорошей производительности и
подключением к локальной сети предприятия.
Исходя из вышеизложенного, можно сделать вывод о том, что для
использования разрабатываемой информационной системы в ООО УК «Март»,
не требуется дополнительного оснащения: сем указанным требованиям
соответствует существующее техническое обеспечение предприятия.
60
II. ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Разработка программного обеспечения – весьма разнообразный процесс
при участии и взаимодействии специалистов, выполняющих различный
комплекс работ на достижение поставленных задач. Ввиду этого, необходим
постоянный контроль за выполнением проекта. Для осуществления контроля
необходимо использовать стандарты выполнения процесса разработки.
Стандартами разработки являются некий свод правил (без жестких
правил и ограничений), которых рекомендуется придерживаться. У организаций,
специализирующихся на разработке ПО, а также организаций, имеющих
штатных специалистов, выполняющих разработку ПО для внутренних задач,
также существует свод правил, основанный на общепринятых стандартах
разработки.
В данной работе, в качестве свода правил, выбор пал на Государственный
стандарт Российской Федерации - ГОСТ Р ИСО/МЭК 16326 «Программная
инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при
управлении проектом». Указанный стандарт содержит следующие виды
процессов разработки:
• процессы управления проектами;
• процессы, предшествующие разработке программного продукта;
• процессы по разработке программного обеспечения;
• процессы, выполняемые при завершении разработки;
• общие процессы.
Выбор пал на ГОСТ Р ИСО/МЭК 16326 потому, что в данном документе
содержится перечень процессов, удовлетворяющих все модели жизненного
цикла, что, соответственно, разработку проекта.
Что касается модели жизненных циклов, в разрезе программных средств,
наиболее часто используемыми моделями являются каскадная и итерационная.
Реже используется спиральная, имеющая каскадный подход, но более сложная.
61
Каскадная модель предусматривает последовательную организацию работ.
Вся работа по проекту разбивается на этапы, где переход от одного этапа
переходит к последующему при условии завершения всех работ предыдущего
этапа. Каждый этап предполагает выпуск полного комплекта документации с
целью иметь возможность, при необходимости, продолжить разработку.
Вернуться к предыдущему этапу становится возможным при прохождении всей
цепочки.
20
Основные этапы каскадного подхода представлены на его структуре,
изображенной на рисунке 9.
Рисунок 9. Структура каскадного подхода
Итерационная модель имеет иной подход, заключающийся в организации
серии коротких циклов операций, с организацией подобно со схемой
структурного подхода, но с существенным отличием: на каждом из этапов (серий
циклов) существует возможность вернуться на любой из предыдущих этапов для
корректировки действий – рисунок. Отсюда появляется преимущество над
каскадным подходом из-за меньшей трудоемкости. Структура итерационной
модели представлена на рисунке 10.
20
Вдовин В.М., Суркова Л.Е., Шурупов А.А. Предметно-ориентированные информационные системы, с.97
62
Рисунок 10. Структура итерационного подхода
В рамках данной исследовательской работы выбор пал на итерационная
модель жизненного цикла, поскольку он позволит более детально проработать
проект, особенно при малом опыте, так как позволит устранять проблемы,
возникающие на более поздних этапах путем частичного возврата на
предыдущие.
Внедрение разрабатываемой системы предполагается на стадии
эксплуатации, ввиду чего требуется определить одну из стратегий:
• Параллельная стратегия предполагает работу в системах «до» и «после».
• Стратегия скачка предполагает резкий переход с системы «до» в систему
«после» без проверки правильности работы «после», что повышает риски.
• Стратегия пилотного проекта предполагает использование системы
«после» на тестовом участке. В случае успешного прохождения теста
осуществляется переход остальных участков с системы «до» в систему «после».
• Стратегия узкого места предполагает задействование только одного
процесса, которому в системе «до» было уделено наименьшее внимание.
Учитывая вышеизложенное, был сделан вывод, что для разработки
информационной системы, в рамках данной исследовательской работы,
наиболее подходящей является стратегия пилотного проекта, т.к. ИС
ориентирована на аварийно-диспетчерскую службу, являющуюся довольно
ответственной структурой предприятия, которую нельзя подвергать излишнему
риску возникновения перебоев в работе.
63
Учитывая проведенный анализ, был составлен перечень работ
разрабатываемой информационной системы, отраженный на структурной схеме
и представленный в приложении 1.
Следует обратить внимание, что перечень работ разделен на два
нумерованных этапа условно, очередность выполнения – последовательная
(второй этап следует за первым).
Резюмируя, определено, что разработка информационной системы будет
осуществлена в соответствии с Государственным стандартом Российской
Федерации ГОСТ Р ИСО/МЭК 16326 с применением итерационной модели
жизненного цикла и стратегией пилотного проекта.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Важным этапом в каждом процессе работы над проектом является
выявление рисков. Риски проекта можно разделить на три группы: временные,
финансовые и человеческие.
Данные виды рисков взаимосвязаны, например, сотрудник, вовлеченный в
разработку проекта может уволиться, а следственно за его работу возьмется
другой сотрудник, которому придется вникать в существующую разработку, что
приведет к увеличению сроков сдачи проекта. Для исключения такой
возможности руководителю проекта необходимо составить план реагирования
на риски, который позволит на начальных этапах проекта предусмотреть
резервные ресурсы, введенные в процесс на всех этапах разработки.
Также риски могут быть как прогнозируемыми и заранее определены, так
и не идентифицированными, которые не могут быть заранее спрогнозированы.
Для каждого этапа проекта по разработке системы, автоматизирующей
процесс обработки заявок диспетчерской АДС, следует выделить риски и
разработать план реагирования на них.
Рисками этапа анализа могут быть:
Частичное выполнение требований к системе. К ним можно отнести
функциональные и нефункциональные требования;
64
Неточности при формировании этапов и работ проекта.
Данные риски могут привести к потребности в доработке системы,
которые могут возникнуть в процессе эксплуатации данной системы.
Последствия данного риска повлечет не только временные затраты, но и
финансовые. Причем затраты на информационную систему могут быть
полностью определены только по завершении проекта, до этого они могут быть
только оценены.
Для максимальной минимизации по предотвращению вышеизложенных
рисков необходимо использовать средства автоматизации проектирования
информационных систем, например, CASE-средств для моделирования бизнес-
процессов на этапе выявления требований пользователей.
Необходимо детально рассмотреть все стадии рисков на всех
сопутствующих этапах разработки ИС:
Этап проектирования. На данном этапе проектирования
информационной системы критичным риском является некорректный, либо
ошибочный расчет показателей. Данный риск устраняется на этапе тестирования
системы.
Этап реализации. На данном этапе критичным риском представляется
некорректная разработка программного кода. Данный риск возможно исключить
на этапе согласования технического задания. Каждый как раздел, так и подраздел
технического задания должен разъясняться заказчику и по результатам
согласования технического задания необходимо приступать к разработке
системы.
Этапа тестирования. Данные ошибки могут быть выявлены на этапе
эксплуатации, которые потребуют дополнительных затрат на их устранение.
Такая ситуация довольно распространена и минимизация данного риска
возможна с помощью дополнительно привлеченных специалистов,
задействованных не только на этапе тестирования, но и на этапе реализации.
21
21
Лаврищева Е.М. Программная инженерия. Парадигмы, технологии и case-средства, с. 117
65
Такой вариант решения проблемы может увеличить бюджет проекта, но
позволит снизить риск внеплановых не запланированных трат.
Этапа внедрения. На данном этапе критичным является некорректное
тестирование технического обеспечения программных модулей. Устранение
риска производится с помощью дополнительного тестирования.
Этап сопровождения. К данному этапу можно отнести устаревание
программного обеспечения и программных средств, например, вследствие
изменения законодательства. Данный риск можно минимизировать путем
построения гибкой архитектуры проекта. Ответственность за данную группу
риска возлагается на заказчика программного обеспечения.
22
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Рассмотрим аспекты реализации информационной безопасности для
поставленной задачи. Защита системы от внутренних угроз предполагает
добавление в существующую Политику безопасности организации раздела о
разграничении прав доступа к разрабатываемой системе на административном
уровне.
23
Целью обеспечения надежности разрабатываемой системы является
разработка обеспечения защиты информации для автоматизированного процесса
учета телефонных вызовов аварийно-диспетчерской службы предприятия во
всех направлениях: внешние – входящие и исходящие, внутренние – входящие и
исходящие, записи разговоров. В данной работе рассматриваются
потенциальные угрозы безопасности данных, имеющих место в компьютерной
системе организации, и способы обеспечения безопасности.
Разрабатываемая система является однопользовательской –
разрабатываемая ИС служба-посредник (proxy) получает исходные данные от
одного сервиса, обрабатывает их в соответствии с правилами и готовит к
22
Назарова О.Б., Масленникова О.Е. Разработка реляционных баз данных с использованием CASE-средства All
Fusion Data Modeler, с. 53
23
Васильков А.В., Васильков А.А., Васильков И.А. Информационные системы и их безопасность, c. 81
66
передаче другому сервису, передает подготовленные данные другому сервису –
CRM системе. Графический пользовательский интерфейс служит для
подготовки данных и контроля работы ИС ответственным сотрудником ИТ
отдела. Однако, информация, циркулирующая в проектируемой системе, не
имеет ни один из грифов секретности, а носит чисто конфиденциальный
характер.
Как уже говорилось, разрабатываемая система является
однопользовательской, и доступ к ней будет иметь сотрудник ИТ-отдела отдела
предприятия и непосредственно информационная система.
Вся информация, необходимая при работе системы, будет поступать в
режиме онлайн от телефонной станции. Каких-либо требований для хранения
полученных данных не имеется, так как эти данные обрабатываются в
соответствии с правилами и сериализуются для последующей отправки в CRM
систему, где обеспечивается хранение и сохранность CRM системой.
Разрабатываемая система является полностью автономной от участия
пользователей, за исключением ответственного сотрудника отдела ИТ,
единственная зависимость – входные данные от телефонной станции.
Для выполнения разрабатываемой системой своего функционального
назначения, компьютеру, на котором выполняется система, требуется доступ в
Интернет, так как было указано ранее:
ИС целесообразно выполнять непосредственно на телефонной станции;
используемая CRM система на предприятии облачного типа, то есть
работает на удаленном сервере с web доступом.
Следовательно, являясь proxy сервисом, информационной системе
требуется выход в Интернет с телефонной станции для отправки данных в
облачную CRM систему.
Защита информации в рамках данной работы теряет свою актуальность в
виду того, что разрабатываемая ИС анализирует лишь информационные
сообщения телефонной станции и передает эти данные CRM системе,
безопасность которых, в том числе связанная с хранением, обеспечивается