Для реализации графического интерфейса пользователя было принято
решение использовать среду разработки Embracadero Delphi 10. Данный
выбор был обоснован тем фактом, что данная среда разработки позволяет
разработчикам создавать пользовательский интерфейс очень быстро и
удобно, предоставляя широкий набор компонентов и функций [2]. Согласно
множеству исследований было доказано, что более половины времени
разработки программного продукта занимает разработка графического
интерфейса пользователя. Поэтому среда разработки Embracadero Delphi 10
позволяет сэкономить временные затрат за счет генерации фрагментов кода
программного продукта [7].
В процессе ввода и редактирования данных должен производиться
контроль корректности введенных значений. В случае ввода неверных или
ошибочных значений система должна предупредить об этом пользователя.
Пользовательский интерфейс должен быть эргономичным, без лишних
элементов, отвлекающих внимание пользователя во время работы.
В состав программного модуля должны быть включены следующие
модули:
− модуль доступа к базе данных;
− главный модуль программы;
− модуль работы со справочниками [22].
Для обеспечения информационной безопасности набор базового
программного обеспечения в обязательном порядке должен быть проверен на
наличие известных уязвимостей, а также к отказам.
При выполнении операций по монтажу, наладке, эксплуатации,
обслуживанию и ремонту средств технического обеспечения
информационной системы необходимо соблюдать требования
электробезопасности.
Внешние элементы технических средств информационной системы,
находящиеся под напряжением, в обязательном порядке должны иметь
47
элементы защиты от случайного прикосновения, а также подключены к
заземляющему контуру.
Средства электропитания должны обеспечить защитное отключение в
случае перегрузок или коротких замыканий в электросети, а также иметь
механизмы аварийного ручного отключения.
Требования пожарной безопасности должны быть составлены в
соответствии с основными нормами на бытовое элеткрооборудование,
которое при горении не должно выделять ядовитый газ или дым. После
отключения напряжения допускается использование любых средств
пожаротушения.
1.4.3. Обоснование проектных решений по техническому
обеспечению
Под техническим обеспечением при автоматизации задачи понимают
совокупность технических средств, выполняющих переработку и
отображение информации, управление и передачу данных. Выбор состава
используемых технических средств напрямую влияет на дальнейшую
эффективность всего проекта автоматизации задачи.
Следовательно, для успешного функционирования системы связи
необходимо наличие следующего технического обеспечения: процессор с
тактовой частотой не ниже 2,5GHz; оперативная память не менее 1024 Mb;
свободное пространство на жестком диске 500Mb; монитор и графический
адаптер, принтер, клавиатура, манипулятор типа «мышь».
Техническое обслуживание и ремонт системы не предусматривается.
Хранение компонентов системы должно осуществляться на носителях,
обеспечивающих свободное считывание и запись информации при работе с
базой данных (БД).
В процессе эксплуатации ИС техническое обеспечение может быть
модернизировано для достижения более высоких показателей
быстродействия.[20]
48
49
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
На текущий момент времени можно назвать несколько основных
стандартов, применяемых при проектирования информационных систем:
− стандарт ISO/IEC 12207 представляет собой стандарт на
организацию процессов и жизненного цикла информационной системы,
распространяемый на все виды программных продуктов;
− методология RUP относится к интерактивным методологиям
разработки;
− методология RAD является методологией быстрой реализации
программных продуктов и представляющая разработчику набор специальных
инструментов для быстрой развертки графического интерфейса
пользователя;
− методология CDM является специализированной методологией,
применяемой для разработки информационных систем, в основе которых
лежит применение компонентов Oracle.
Для любой информационной системы можно выделить следующие
основные этапы жизненного цикла:
1) Аналитический этап. Включает анализ требований заказчика, учет
требований и рекомендаций регуляторов отрасли (Минздрав, ФФОМС и
т.д.), стратегии развития продуктов, выработанной соответствующей
компанией-разработчиком, совещания и различные обсуждения и т.д.
2) Этап проектирования. Включает составление ТЗ, экизов, требований
к ПО или новой функции, уточнение применяемых алгоритмов, образцов
экранных и отчетных форм, требований к реализации и т.д.
3) Этап разработки включает непосредственное создание ИС или новой
функции – (программирование), который в свою очередь состоит из
следующих этапов:
− Написание кода.
50
− Тестирование.
− Доработка по результатам различных методов тестирования.
− Документирование [14].
4) Этап внедрения, включающий передачу (установку) ПОна
промышленную инфраструктуру, настройку и обучение пользователей. Этап
внедрения всегда разделяется на 3 обязательных под этапа:
− Инсталляция.
− Опытная эксплуатация.
− Промышленная эксплуатация.
5) Этап сопровождения, который подразумевает прием от
пользователей различных обращений и предложений, их анализ и учет в
дальнейшем развитии продукта
6) Вывод из эксплуатации, включая экспорт накопленных данных,
деинсталляция ПО, уничтожение конфиденциальной информации при
необходимости и т.д. [29]
Моделью жизненного цикла информационной системы называют
совокупность этапов по разработке информационной системы и методики их
организации. Для реализации программного продукта было принято решение
об использовании каскадной модели жизненного цикла.
Перед началом проекта, необходимо определить качество стандартов,
которые необходимы для достижения целей проекта. Стандарт качества —
это показатель, который применяется для определения успеха реализации
проекта или его результатов.
Стандарты качества, применяются с целью удовлетворить все цели
проекта, а также избежать ошибок, обеспечивают ресурсы, необходимых для
завершения проекта, достижения целей проекта, повышения
производительности.
К проекту применимы перечисляемые далее стандарты качества:
51
− Политика качества организации. Политики качества выражают
направление на качество. Ими описывается способ усилить качества
реализуемого проекта.
− Подробное описание конечного результата. При грамотной
организации описаний продукта может быть достигнут наилучший результат.
− Изучение перечня стандартов, в той или иной степени
затрагивающих реализуемый проект.
− Конечные результаты проекта являются материальными
результатами, обеспечивающих уровень качества для клиента; они должны
удовлетворить потребности клиента.
Исследуя влияние качества на область охвата проекта, возможно,
придется проанализировать следующие аспекты:
− При необходимости можно сократить область охвата проекта для
соблюдения даты окончания или бюджета. Или после создания плана
проекта, возможно, потребуется больше времени или денежных средств, чем
ожидалось. В любом случае можно изменить область охвата проекта.
− Когда требуется сократить область охвата, обычно допускается
возможность удалить некоторые задачи или уменьшить длительность задач.
Задачи, которые удалили из проекта, может быть не влияют на конечный
результат, но это может повлиять на уровень качества проекта.
− Если возникает попытка сократить расходы для соблюдения
бюджета, более дорогие ресурсы могут замените более дешевыми. Ресурсы
более высокого качества, оборудования и материалов, чаще всего более
дороги. Замена менее дорогими ресурсами может означать снижение
трудозатрат, навыков или снижение стоимости материалов и оборудования.
Исходя из того, что для разработки программного продукта было
принято решение о применении среды разработки Delphi, наиболее
оптимальным будет использование методологии RAD. В качестве модели
жизненного цикла информационной системы была выбрана каскадная модель
жизненного цикла – разработка программы будет осуществляться поэтапно.
52
Для внедрения информационной системы будет использована стратегия
«Узкое место», что позволит автоматизировать деятельность экономиста
операционного зала без каких-либо потерь и затруднений для организации.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Внедрение любой информационной системы является непростым
процессом, что требует от всех лиц, задействованных в данном процессе
приложения максимальных усилий, чтобы достичь максимально
положительного результата. Положительный результат процесса внедрения
информационной системы прямо зависит от уровня своевременного и
эффективного снятия основных рисков проекта [26].
Наиболее распространенным рискам, возникающим при внедрении
информационной системы, называют следующие риски:
− осуществление автоматизации бизнес процессов, которые
являются нерегламентированными;
− возникновение необходимости выполнить частичную, либо
полную реорганизацию структуры организации;
− возникновение необходимости осуществляться корректировки
текущей технологии ведения бизнеса в различных аспектах;
− возможные негативные настроения у персонала организации;
− наличие временного увеличение нагрузок на персонал
предприятия в период этапа внедрения системы;
− возникновение требований по формированию специальной
группы сотрудников, занимающихся вопросами внедрения информационной
системы [18].
На основании выделенного перечня типовых рисков следует описать
возможные риски при внедрении автоматизированного рабочего места
экономиста операционного зала. На текущий момент времени данная система
в работе отсутствует, все данные клиентов хранятся на отдельных
банковских базах данных. Для функционирования системы потребуется
53
перенос всей требуемой информации в базу данных, что может вызвать
некоторые трудовые и временные затраты на выполнение данного процесса.
Как было отмечено ранее, при внедрении информационной системы
может возникнуть рад типовых рисков. Для оценки последствий данных
рисков используют пятибалльную шкалу, где 1 - очень низкая значимость
последствий риска, 5 - очень высокий уровень значимости последствий
риска. В таблице 2.1 перечислены основные риски, которые могут
возникнуть в связи с реализацией внедрения информационной системы.
Таблица 2.1 – Оценка рисков
Риски
Вер-ть
риска
Оценка
последствий
риска
Оценка
риска
1. Организация автоматизации ранее не
регламентированных бизнес
-процессов
0,2
2
0,4
2. Необходимость пере рассмотрения
организационной структуры комитета
0,2
2
0,4
3. Необходимость изменения технологии
бизнеса в различных аспектах
0,1
5
0,5
4. Сопротивление сотрудников предприятия
0,1
3
0,3
5. Временное увеличение нагрузки на
сотрудников во время внедрения системы
0,5
5
2,5
6. Необходимость в формировании
квалифицированной группы внедрения
0,2 5 1
Приведенный расчет является качественным анализом возможных
рисков проекта. Далее необходимо выполнить количественный анализ
рисков для дальнейшей оценки вероятности возникновения данных рисков, а
также размеров причиняемого ими ущерба. Далее будет выполнен
количественный анализ трех рисков, выявленных в результате качественного
анализа, являющихся наиболее значимыми.
54
На рисунке 2.1 представлен количественный анализ риска
необходимости изменения технологии ведения рабочего процесса в
различных аспектах.
Необходимость изменения
технологии ведения рабочего
процесса
Ничего не делать
Привлечь специалиста
по реинжинирингу
рабочих процессов
Не реализация
40%
Затраты отсутствуют
Реализация 60%
Провал проекта
Затраты на
реализацию проекта
928 600
Не реализация
30%
З/п специалиста +
затраты на простой
998 600
Реализация 70%
З/п специалиста
70 000
Рисунок 2.1 – Количественный анализ риска необходимости изменения
технологии ведения рабочего процесса в различных аспектах
Выполним расчет финансовых потерь для каждого из решений по
устранению данного риска:
1. 0,7 * 70 000+ 0,3*998 600 = 49 000 + 299 580 = 348 580
2. 0,6 * 928 600 + 0,4*0 = 557 160
Таким образом, наиболее оптимальным решением по минимизации
данного риска является привлечение специалиста по реинжинирингу бизнес
процессов.
На рисунке 2.12 представлен количественный анализ риска
необходимости формирования квалификационной группы внедрения ИС.
55
Необходимость формирования
квалифицированной группы
внедрения ИС
Ничего не делать
Привлечь группу
внедрения от
обслуживающей
организации
Не реализация 20%
Затраты отсутствуют
Реализация 80%
Провал проекта
Затраты на
реализацию проекта
928 600
Не реализация 85%
Оплата услуг
организации +
затраты на простои
360 000
Реализация 15%
Оплата услуг
организации
210 000
Привлечь собственного
специалиста
Не реализация 30%
З/п специалиста +
затраты на простой
260 000
Реализация 70%
З/п специалистов
24 000
Рисунок 2.12 – Количественный анализ риска необходимости
формирования квалификационной группы внедрения ИС
Выполним расчет финансовых потерь для каждого из решений по
устранению данного риска:
1. 0,15 * 510 000+ 0,85*360 000 = 76 500 + 288 000 = 364 500
2. 0,7 * 140 000 + 0,3*260 000 = 98 000 + 78 000 = 176 000
3. 0,8 * 928 600 + 0,2 *0 = 742 880
Таким образом, наиболее оптимальным решением по минимизации
данного риска является привлечение собственного специалиста организации.
На рисунке 2.3 представлен количественный анализ риска увеличения
нагрузки на сотрудников в период внедрения ИС.
56