26
1.3.3. Выбор и обоснование способа приобретения ИС для автоматизации
задачи
Рассмотрим существующие способы приобретения информационных
систем для автоматизации бизнес-процесса. Приобретение информационных
систем может осуществляться одним из перечисленных способов:
1. Покупка готовой специализированной ИС.
2. Разработка ИС своими силами.
3. Разработка ИС сторонней фирмой.
4. Покупка системы и её доработка.
Рассмотрим вариант покупки готовой информационной системы,
автоматизирующей бизнес-процесс управления сервисным обслуживанием.
Ранее были рассмотрены программные продукты, представленные на рынке, и
был сделан вывод о том, что они не в полной мере удовлетворяют
потребностям организации, поэтому покупка готовой информационной
системы не потребуется.
Рассмотрим вариант с покупкой системы и ее доработкой. Доработка
информационной системы под потребности организации является трудоемкой и
добавление необходимого информационных систем под нужды компании
потребует внесения значительных изменений исходного кода и бизнес-логики.
Поэтому оба варианта приобретения информационной системы были
отклонены.
Следующая группа вариантов приобретения информационных систем
подразумевает разработку информационной системы, удовлетворяющей
требованиям организации. Поскольку в организации есть подразделение,
отвечающее за эксплуатацию информационной инфраструктуры, и сотрудники,
работающие в нем, имеют опыт разработки программного обеспечения,
подходящим вариантом разработки системы является разработка системы
своими силами.
27
1.4. Обоснование проектных решений
1.4.1. Обоснование проектных решений по информационному
обеспечению
В проектируемой системе необходимо создать следующие справочники:
1. Контрагент – перечень контрагентов организации.
2. Вид оборудования - перечень видов оборудования.
3. Наименование оборудования – перечень моделей оборудования.
4. Сотрудник – перечень сотрудников ремонтного отдела.
5. Статус ремонта – перечень стадий ремонта оборудования.
6. Ремонтные работы - перечень ремонтных работ.
В рассматриваемой задаче отсутствуют входные документа. Выходными
документами процесса являются акт приема-передачи оборудования, акт
выполненных работ и отчет. Акт приема-передачи оборудования имеет
унифицированную форму, поэтому проектирование оригинальной формы
документа не потребуется. В акте содержатся данные о наименовании
оборудования, данные контрагента и дате приема оборудования.
Акт выполненных работ содержит данные о выполненных работах по
каждой единице оборудования. Документ имеет унифицированную форму,
поэтому проектирование оригинальной формы документа не потребуется. В
акте содержатся данные о наименовании оборудования, данные о клиенте и
перечне работ, выполненных в рамках сервисного обслуживания.
Отчет не имеет унифицированной формы, он содержит перечень
принятого за заданный временной интервал оборудования со статусами
ремонта.
Для каждого факта передачи оборудования для сервисного обслуживания
должны быть предусмотрены следующие статусы, которые будут давать
пользователям системы возможность отслеживания этапов ремонта:
1. Принятое оборудование.
2. Диагностика.
28
3. Не подлежит ремонту.
4. Ремонт.
5. Выдача.
6. Выдано.
Перечисленные стадии прохождения ремонта должны входить в состав
справочника «Статус обслуживания».
Статусы прохождения ремонта будут выставляться специалистами
ремонтного отдела.
1.4.2. Обоснование проектных решений по программному
обеспечению
Информационные системы позволяют пользователям осуществлять сбор
и обработку данных. Для хранения данных используются базы данных.
Различают следующие виды баз данных [12]:
1. Иерархические.
2. Сетевые.
3. Реляционные.
В настоящее время широко применяются реляционные базы данных в
связи со следующими факторами [17]:
Они обладают простотой, поскольку в реляционной модели данных
существует всего одна информационная конструкция, формализующая
табличное представление данных.
Наличие теоретически обоснованных методов нормализации
отношений позволяет получать базу данных с заданными характеристиками.
Независимость данных заключается в том, что при необходимости
внесения изменений в структуру реляционной базы данных, требуется внесение
минимальных изменений.
Помимо перечисленных достоинств, в организации уже используется
реляционная СУБД. Поэтому, с целью минимизации конфликтов в процессе
интеграции, для разработки информационной системы будет использована
реляционная база данных [16].
29
Для управления реляционной базой данных используется реляционная
СУБД. На рынке широко представлены как коммерческие, так и бесплатные
СУБД. Наиболее востребованными на рынке являются следующие СУБД:
Microsoft SQL Server;
PosgreSQL;
IBM DB2;
Oracle database.
СУБД Microsoft SQL Server обладает большим пакетом инструментов,
стабильностью работы и низкими затратами на администрирование [19].
Недостаток системы заключается в том, что она работает только на платформе
Windows. Реляционная СУБД с открытым исходным кодом «PostgreSQL»
основана на языке SQL, поэтому поддерживает множество возможностей
стандарта SQL:2011. СУБД IBM DB2 является кроссплатформенной,
обеспечивает стабильную работу базы данных. Недостатками системы
являются высокая стоимость и низкая производительность. СУБД Oracle
обладает высокой производительностью, легкостью интегрирования
приложений и устойчивостью к большим потокам данных. Недостатком
является высокая стоимость, необходимость приобретения мощного
оборудования и персонала для поддержки СУБД. На основании перечисленных
характеристик для разработки системы была выбрана СУБД PostgreSQL.
Для разработки информационной системы будет использован объектно-
ориентированный подход, поскольку он позволяет осуществлять
конструирование из компонентов, обладающих простыми инструментами, что
дает возможность абстрагироваться от деталей реализации [10]. При этом
данные и операции вместе образуют определенную сущность, и они не
«размазываются» по всей программе, как это нередко бывает в случае
процедурного программирования. Использование локализации программного
кода и данных улучшает наглядность и удобство сопровождения программного
обеспечения.
30
В качестве языка программирования был выбран язык программирования
c++. Который поддерживает объектно-ориентированный подход и обладает
множеством встроенных библиотек.
Разработка информационной системы будет осуществляться в среде
программирования MS Visual Studio Community, которая является бесплатным
инструментом, поддерживающим выбранный язык программирования.
Проектируемая система должна функционировать в среде операционной
системы Windows 10, поскольку эта операционная система используется для
работы сотрудников организации.
1.4.3. Обоснование проектных решений по техническому
обеспечению
Для того, чтобы определить необходимость приобретения технического
обеспечения для решения поставленной задачи, необходимо рассмотреть
характеристики оборудования, которое имеется в организации. Характеристика
оборудования представлена в таблице 5.
Таблица 5
Характеристика компонентов сервера
Наименование
Спецификация
Сервер
Процессор
Intel Core i9 9900X 3500 МГц
Частота процессора
3500 МГц
Оперативная память
DDR4 DIMM 16 ГБ
Жесткий диск
Seagate Barracuda ES.2, 1000GB
Персональные компьютеры
Процессор
Intel Xeon E5345
Частота процессора
4 ГГц
Оперативная память
4 ГБ RAM
Объем жесткого диска
500 ГБ HDD
В результате анализа технического обеспечения организации был сделан
вывод о том, что оно имеет достаточный уровень производительности для
функционирования разрабатываемой информационной системы, в связи с чем
не подлежат модернизации.
31
ВЫВОДЫ ПО ГЛАВЕ 1
Результаты деятельности ГБУ Управление МТСО по итогам 2019 года
показывают эффективность деятельности. После изучения бизнес-процессов
организации был выявлен ряд недостатков в процессе сервисного
обслуживания. А именно: отсутствие единого хранилища данных о каждой
заявке и высоких временных затратах на формирование документооборота.
Чтобы оптимизировать бизнес-процесс, были рассмотрены программные
продукты, представленные на рынке. Однако они обладали низкими
показателями функциональности и не соответствовали поставленным
критериям. Поэтому было принято решение о разработке информационной
системы. Для этого были обоснованы проектные решения по
информационному, программному и техническому обеспечению.
32
2. ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Процесс разработки информационной системы, автоматизирующей
процесс управления сервисным обслуживанием, будет осуществляться
согласно стандарту ГОСТ Р ИСО/МЭК 12207-2010 «Информационная
технология. Системная и программная инженерия. Процессы жизненного цикла
программных средств».
Этот стандарт содержит комплекс процессов, разделенных на следующие
группы [1]:
1. Процессы соглашения.
2. Процессы организационного обеспечения проекта.
3. Процессы проекта.
4. Технические процессы.
5. Процессы реализации программных средств.
6. Процессы поддержки программных средств.
7. Процессы повторного применения программных средств.
Жизненный цикл информационной системы соответствует V-образной
модели жизненного цикла. Ее структура представлена на рисунке 7.
Рисунок 7. V-образная модель жизненного цикла программного
обеспечения
33
Таким образом, процесс разработки информационной системы будет
включать в себя следующие этапы [3]:
1. Анализ требований.
2. Описание функций.
3. Проектирование архитектуры.
4. Кодирование.
5. Проверка кода.
6. Проверка архитектуры.
7. Проверка функций.
8. Проверка требований.
Внедрение информационной системы может осуществляться согласно
одной из следующих стратегий:
Параллельная стратегия предполагает, что сотрудники предприятия
будут одновременно работать и в старой системе, и в новой. Успех внедрения
системы будет заключаться в согласовании выходных документов обоих
систем.
Стратегия скачка предполагает, что старая система снимается с
эксплуатации и пользователи начинают работать с новой системой без
предварительной проверки ее работоспособности.
Стратегия пилотного проекта предполагает, что новая система
будет внедрена на каком-то одном участке работ, что позволит минимизировать
риски и показывает большую надежность.
Стратегия узкого места предполагает, что автоматизация затронет
только один выполняемый процесс и деятельность сотрудников, которые в нем
задействованы.
Из перечисленных стратегий внедрения была выбрана стратегия узкого
места потому, что процесс управления сервисным обслуживанием ранее не был
автоматизирован и система будет автоматизировать работу только сотрудников
ремонтного отдела.
34
Таким образом разработка информационной системы будет
осуществляться согласно стандарту ГОСТ Р ИСО/МЭК 12207-2010, V-образной
модели жизненного цикла и стратегии внедрения «узкое место».
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
В процессе планирования проекта по разработке системы необходимо
проанализировать риски и разработать план реагирования на риски. Выявим
риски, которые могут быть выявлены на этапах жизненного цикла системы.
Рисками этапа анализа требований являются [11]:
недостаточное определение свойств проектируемой системы,
которые требуются для решения задачи;
неверный выбор процессов автоматизации.
Последствиями этих рисков может стать необходимость доработки
системы, выявленная на этапе опытной эксплуатации, что повлечет за собой
дополнительные финансовые затраты.
Предотвратить перечисленные риски возможно с помощью применения
CASE-средств при моделировании бизнес-процессов на этапе выявления
требований пользователей.
Основным риском этапа описания функций системы является
неправильное определение функций системы. Вследствие этого может
возникнуть риск неправильного выбора способа приобретения системы.
Предотвращение риска возможно с помощью проведения тщательного анализа
всех способов приобретения системы.
Если риск все-таки осуществился, необходимо провести повторный
анализ вариантов выбора системы. Предыдущий риск взаимосвязан с риском
неправильного определения функций системы и стратегии автоматизации [23].
Устранение этого риска возможно с помощью применения CASE-средств в
процессе анализа предметной области.
Рассмотрим риски этапа проектирования архитектуры системы. Одним из
рисков этого этапа является разработка неэффективного плана-графика
35
проекта, которое заключается в использовании лишних ресурсов или в
дефиците ресурсов. Этот риск является финансовым, его устранение возможно
с помощью использования программного обеспечения, автоматизирующего
процесс планирования проекта по разработке системы (например, MS Project).
Повторное появление этого риска устраняется с помощью повторной
корректировкой плана-графика работ.
Рисками этапа кодирования являются разработка неправильной
информационной модели и неудобных для пользователя прототипов экранных
форм. Этот риск можно предотвратить с помощью согласования прототипов
экранных форм с пользователями системы. Устранение риска осуществляется
при помощи доработки экранных форм.
Еще одним риском является некорректная разработка программного кода.
Этот риск устраняется на этапе согласования технического задания. Каждый
раздел технического задания должен быть разъяснен заказчику и только после
полного согласования технического задания стоит приступать к разработке
системы.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
К организационно-правовым методам обеспечения информационной
безопасности относятся внесение изменений в Политику информационной
безопасности [6]. В Политику информационной безопасности необходимо
добавить раздел, в котором перечислены права доступа к разрабатываемой
системе.
Для этого нужно выделить круг пользователей системы. Работать с
разрабатываемой системой будут все сотрудники ремонтного отдела, которые
будут фиксировать прием и этапы ремонта оборудования. Кроме того, с
системой будут работать сотрудники юридического отдела, которым
необходим будет доступ к документам, формируемым в системе (акт приема-