Роботизация работы городской больницы на основе спиралевидной модели внедрения информационных систем

Подробности

Опубликовано: 10.07.2020 11:29

Автор: Чепров Евгений Дмитриевич

Просмотров: 4589

Аннотация: в работе реализуется роботизация работы городской больницы с применением спиралевидной методологии внедрения медицинских информационных систем с использованием MS Access и UiPath. Практическая ценность данного исследования заключается в том, что при некотором расширении функционала и доработок программы возможно получить и внедрить разрабатываемого робота в работающую больницу.
Скачать: PDF, PPT, MP4.
Ключевые слова: UiPath, нотация BPMN SLD, collaborative minds blog, эволюционная стратегия разработки, интегрирующий аспект спиральной модели, графическая нотация, соподчинённость объектов, стандартный набор условных обозначений, роботизированная база данных, декомпозиция по нотациям.

Введение

Одним из проблемных вопросов в работе лечебных учреждений, которые сдерживают качество и своевременность предоставления медицинских услуг в настоящее время, являются трудности при обработке информации о пациентах и персонале. Основными из них являются:

• длительный и трудоемкий процесс поиска необходимых сведений о пациентах в медицинских картах;
• отсутствие или несоблюдение единого формата внесения данных о пациенте в карту, в записи поставленного диагноза, написании отчета о проведенном лечении и др.
• случаи потерь бумажных носителей информации в процессе работы больницы.

Рост количества пациентов, обращающихся в лечебные учреждения за помощью, не должен снижать качества и своевременности предоставления медицинских услуг. Поэтому целесообразным является автоматизировать отдельные бизнес-процессы в работе лечебных учреждений (больниц). Этого можно достичь за счет разработки приложения с помощью систем управления базами данных (СУБД), например, MS Acces и применения его в практике работы лечебных учреждений. Разрабатываемая программа значительно упростит процесс обработки информации, сделает его куда более быстрым и удобным. Данное приложение совместимо с операционной системой Microsoft Windows, которая используется на большинстве компьютеров медицинских учреждений. Кроме того, программа доступна для работы  пользователям без специальных знаний, навыков и подготовки. Затем при помощи создания робота на основе UiPath проведем роботизацию базы данных. Данное программное обеспечение позволяет создавать процессы автоматизации любых сложностей. Это даст возможность избавить человека от необходимости делать все лично и передать часть задач по работе с базой данных для выполнения на компьютер. Целью данной выпускной квалификационной работы является демонстрация применения спиралевидной методологии внедрения медицинских информационных систем с использованием MS Access и UiPath на примере роботизации работы городской больницы.

Для выполнения данной задачи была выбрана спиралевидная модель внедрения программных решений, для чего необходимо разбить разработку программного продукта на 4 этапа, которые называются “витками”. Выполнение поставленной цели заключается в реализации следующих задач:

• Проанализировать спиралевидную методологию внедрения информационных систем и подходы к роботизации работы городской больницы.
• Идентифицировать требования к процессам первичного приема пациента, постановки диагноза и проведения лечения. 
• Спроектировать процессы в IDEF0 и BPMN SLD для модели AS-IS и TO-BE до 3-4 уровней детализации; данные – UML CD, включая нормализацию таблиц; структуру приложения для каждого витка спирали.
• Реализовать и количественно оценить программное приложение для автоматизации работы больницы в средах MS Access и UiPath.

Практическая ценность данного исследования заключается в том, что при некотором расширении функционала и доработок программы возможно получить и внедрить разрабатываемого робота в работающую больницу.

Раздел 1. Обзор литературных источников

Первый источник – статья из сборника «Роль науки в развитии общества». В сборнике опубликованы статьи международной научно-практической конференции проходившей 20 декабря 2015 года в городе Казань. В работе использовалась статья «Применение технологии IDEF для моделирования медицинских СУБД» за авторством Д.А. Половодова, Е.А. Половодовой, С.Е. Сергина, магистров Кубанского государственного университета.

В этой статье авторы раскрывают интересующую нас информацию сразу в нескольких отраслях. В ней изложена и нотация IDEF. В данной статье так же рассмотрена та предметная область, в которой нам предстоит разработать программное решение. Плюс ко всему в данной публикации затрагивается  тема баз данных, что также является предметом нашей работы.

Касательно баз данных, авторы осветили современное положение дел в этой области программного обеспечения. Отметили важность их использования в медицине в тандеме с применением технологии интернет. Развили специфику использования медицинских баз данных, таких как:

• Предоставление пользователю только результата поиска.
• Полнота представления запрошенной информации.
• Высокая скорость обновления, доступа.
• Интерактивность.
• Терминальная (локальная) и удаленная работа пользователя.

Тезисным в работе авторов является следующее. Наиболее удобным языком моделирования бизнес – процессов является IDEF0, где система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной – функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет четко сформулировать процессы, происходящие в интересующей нас отрасли вне зависимости от того, что это за отрасль.

Вторым литературным источником является электронный ресурс. Это конспект лекций Дальневосточного государственного университета путей сообщений, подготовленный Анисимовым Владимиром Викторовичем.

В отличие от книги или статьи, конспект лекций хорошо подходит для курсового изучения. А тот факт, что это электронный ресурс в виде гипертекста, делает его удобным справочником, позволяющим уточнить интересующую тему. Особенно стоит отметить наличие блоков вопросов и рекомендаций. Проходя путь от понятия информационной системы до модели её реализации, читатель имеет возможность самоконтроля и валидации приобретенных знаний.

Третьим литературным источником так же является электронный ресурс. Это статья, посвященная нотации BPMN, размещенная на сайте компании занимающейся разработкой и продажей бизнес- приложений.

Раздел, в котором находится интересующая нас информация, называется – Collaborative Minds Blog. Преимуществом данного ресурса являются одновременно полнота изложения материала о данной нотации и простота для понимания. Это преимущество является одним из ключевых, так как информации по данной нотации понятной для начинающих постигать решения для декомпозиции бизнес-процессов, не так много. 

Раздел 2. Теоретическая часть

2.1. Понятие жизненного цикла и его модели

Информационные системы должны удовлетворять интересам бизнеса, а также быть легко модифицируемыми и недорогими. Плохо спроектированная система, в конечном счете, требует больших затрат и времени для ее содержания и обновления. Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). Жизненный цикл определяется как развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения. Модель жизненного цикла – структура процессов и действий, связанных с жизненным циклом, организуемых в стадии, которые также служат в качестве общей ссылки для установления связей и взаимопонимания сторон. 

2.2. Спиралевидная модель и ее особенности

Существует множество различных моделей жизненного цикла ПО, одна из них – спиральная модель. В ней делается упор на начальные этапы ЖЦ системы: анализ и проектирование. Спиральная модель – классический пример применения эволюционной стратегии разработки [6]. Особенность данной модели заключается в том, что прикладное программное обеспечение создается не сразу, а по частям (модулям) с использованием метода прототипирования. В данной модели прототип – действующее программное обеспечение, реализующее отдельные функции и внешний интерфейс пользователя [7]. Как показано на рисунке 2.1, модель определяет четыре действия, каждое из которых соответствует своему квадранту спирали:

• Подготовка – сбор требований и ограничений.
• Планирование – формирование плана проекта и анализ рисков.
• Моделирование и конструирование (разработка) – подготовка моделей и реализация продукта следующего уровня.
• Развертывание – оценка заказчиком текущей версии продукта.

Рис. 2.1. Спиралевидная модель: 1 – начальный сбор требований проекта; 2 – та же работа, но на основе рекомендаций заказчика; 3 – планирование проекта и анализ риска с использованием начальных требований; 4 – планирование и анализ риска реакции заказчика; 5 – переход к комплексной системе; 6 – начальный макет системы; 7 – версия системы следующего уровня; 8 – разработанная система; 9 – оценивание заказчиком

Разработка здесь отображается движением по разворачивающейся спирали (по часовой стрелке), причем старт проекта происходит в первом квадранте. Интегрирующий аспект спиральной модели очевиден при учете радиального измерения спирали. С каждым витком по спирали (продвижением от центра к периферии) строятся все более полные версии ПО [6].

Спиральная модель позволяет начинать работу над следующим этапом, не дожидаясь завершения предыдущего. При необходимости на каждом цикле можно корректировать требования к разрабатываемому продукту. Главная проблема спиралевидной модели – определение момента перехода на следующий этап. Возможным её решением является жестких временных рамок для каждого цикла [8].

Отличительной особенностью этой модели является особое детальное рассмотрение рисков, влияющих на организацию жизненного цикла. Барри Боэм, автор модели, в своей работе [9] формулирует десять наиболее распространённых (по приоритетам) рисков:

• Дефицит специалистов.
• Нереалистичные сроки и бюджет.
• Реализация несоответствующей функциональности.
• Создание неправильного пользовательского интерфейса.
• Перфекционизм, «золотая сервировка», ненужная оптимизация и оттачивание деталей.
• Непрерывный поток изменений.
• Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.
• Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
• Недостаточная производительность получаемой системы.
• Разрыв между квалификацией специалистов и требованиями проекта.

Достоинства спиральной модели:

• Позволяет быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований.
• Допускает изменение требований при разработке информационной системы, что характерно для большинства проектов, в том числе и типовых.
• Обеспечивает гибкость в управлении проектом.
• Позволяет получить более надежную и устойчивую систему. По мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации.
• Позволяет совершенствовать процесс разработки – анализ, проводимый в каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации.
• Уменьшаются риски у заказчика. Заказчик может с минимальными для себя финансовыми потерями завершить развитие неперспективного проекта.

Недостатки модели:

• Увеличивается неопределенность у разработчика в перспективах развития проекта. Этот недостаток вытекает из предыдущего достоинства модели.
• Затруднены операции временного и ресурсного планирования всего проекта в целом. Для решения этой проблемы необходимо ввести временные ограничения на каждую из стадий жизненного цикла. 
• Переход осуществляется в соответствии с планом, даже если запланированная работа не выполнена. План составляется на основе статистических данных, полученных в предыдущих проектах и личного опыта разработчиков.

Фундаментальным принципом реинжиниринга (реорганизации) является рассмотрение деятельности компании не с точки зрения функционирования ее структурных подразделений, а с точки зрения организации и протекания в ней бизнес-процессов. Бизнес-процесс – это связанное множество внутренних видов деятельности компании, заканчивающихся созданием продукции или услуги, необходимой потребителю. Термин «потребитель» следует понимать в широком смысле – это может быть просто клиент, а может быть и другой процесс, протекающий во внешнем окружении, например, у партнеров или субподрядчиков.

Бизнес-модель – это описание бизнес-процессов, характеризующее их основные элементы и связи между этими элементами, позволяющее создать упрощенное целостное представление о бизнес-процессе и отразить его наиболее существенные характеристики. Моделирование бизнес-процессов является значимой составной частью проектов по реинжинирингу бизнес-процессов и внедрению крупномасштабных систем ПО. Отсутствие таких моделей является одной из главных причин неудач многих проектов.

Ориентирование на процессы является основным фактором успешного реинжиниринга. Другим, не менее важным фактором, является переход предприятия на использование новых информационных технологий. Применение новых информационных технологий может привести не только к принципиальным изменениям в деятельности сотрудников, но и к полной замене существующих бизнес-процессов.

На начальных этапах создания программного решения необходимо понять, как работает организация, которую собираются автоматизировать. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но может не знать, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель, которая будет адекватна предметной области и содержать в себе знания всех участников бизнес-процессов организации.

При проектировании ключевых бизнес-процессов используют две модели: AS-IS (как есть) и TO-BE (как будет). Модель AS-IS (как есть) основана на совокупности должностных инструкций, отчетов, приказов, нормативной документации и т.д., относящейся к предприятию. Она позволяет выяснить, «что мы делаем сегодня» перед тем, как перейти к тому, «что мы будем делать завтра». Анализ модели позволяет выявить слабые места в структуре организации, в чем будут состоять преимущества новых процессов и насколько глубоким изменениям подвергнется существующая организация деятельности предприятия.

Найденные в модели недостатки исправляются в модели TO-BE: модели новой организации работы предприятия. Модель TO-BE нужна для анализа альтернативных путей решения задачи и выбора наилучшего из них.

2.3. Сбор требований пользователя

Для реализации программного продукта нам необходимо собрать требования пользователя к продукту. Этот этап является одним из важнейших в нашем проекте. Без понимания требований заказчика невозможно создать адекватное программное обеспечение. На данном этапе были определены следующие требования:

• Хранение информации:
  • Пациенты.
  • Персонал.
  • Больничная карта.
  • Операции.
• Работа с информацией:
  • Добавление записей.
  • Удаление записей.
  • Изменение записей.
• Автоматическое открытие элементов БД:
  • Открытие главного экрана БД при запуске бота.
  • Переход к выбранным записям.
  • Автоматический ввод данных при добавлении новой записи.
  • Автоматическое переключение при вводе информации.
  • Автоматическое сохранение изменений.
  • Автоматическое закрытие элементов БД.
  • Автоматический выход из СУБД.

Для того чтобы реализовать наш проект, разобьем требования заказчика на 4 витка спирали. Это позволит, постепенно создавая программу, соотносить каждый промежуточный этап с ожиданиями клиента. На первом витке будет добавлена функция хранения информации путем создания таблиц для хранения информации. А затем, в ходе конструирования базы данных содержание этих таблиц будет оптимизировано и будут созданы связи между таблицами. На следующем этапе будет создан пользовательский интерфейс, который позволит комфортно работать с информацией. На третьем витке будет реализована работа с отдельными элементами базы данных в автоматическом режиме. А на заключительном этапе созданный мною «бот» будет запускать автоматизированные алгоритмы в соответствии с указаниями пользователя, а также сможет копировать информацию из стороннего источника. Работа с требованиями подвела к созданию сводной таблицы с описанием пользовательских требований и соотносящихся с ними функциональными требованиями. Данная таблица позволит удобно обработать требования пользователя и значительно облегчит дальнейшие шаги по созданию программного обеспечения для роботизации городской больницы. Результат создания списка требований представлен в таблице 2.1.

Таблица 2.1. Список требований 

2.4. Способы проектирования

IDEF0 – методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность [2].

Стандарт IDEF0 представляет организацию как набор модулей. Здесь существует правило – наиболее важная функция находится в верхнем левом углу. Кроме того существуют правила сторон:

• Стрелка входа всегда приходит в левую кромку активности.
• Стрелка управления – в верхнюю кромку.
• Стрелка механизма – нижняя кромка.
• Стрелка выхода – правая кромка.

Описание выглядит как «чёрный ящик» с входами, выходами, управлением и механизмом, который постепенно детализируется до необходимого уровня. Также для того чтобы быть правильно понятым, существуют словари описания активностей и стрелок. В этих словарях можно дать описания того, какой смысл вы вкладываете в данную активность либо стрелку [2].

Также, отображаются все сигналы управления, которые на DFD (диаграмме потоков данных) не отображались. Данная модель используется при организации бизнес-процессов и проектов, основанных на моделировании всех процессов: как административных, так и организационных.

Хоть нотация IDEF0 имеет множество преимуществ, но использовать только ее не представляется возможным из-за того, что она охватывает лишь верхние уровни построения бизнес модели. И для реализации нашего программного продукта необходимо использовать ещё одну нотацию. В данном случае это будет BPMN SLD.

Рис. 2.2. Графические элементы нотации IDEF0

Спецификация BPMN раскрывает условные обозначения и их описание в XML для отображения бизнес-процессов в виде диаграмм бизнес-процессов. Для этого как язык использует базовый набор интуитивно понятных элементов, которые позволяют определять сложные семантические конструкции. Кроме того, спецификация BPMN определяет, как диаграммы, описывающие бизнес-процесс, могут быть трансформированы в исполняемые модели. Основная цель BPMN — создание стандартного набора условных обозначений понятных всем пользователям. Следовательно, BPMN служит связующим звеном между фазой дизайна бизнес-процесса и фазой его реализации [14].

Рис. 2.3. Графические элементы нотации BPMN SLD

2.5. Проектирование процессов в AS-IS с помощью IDEF0 и BPMN SLD

Проектирование в модели AS-IS позволяет показать функциональную схему медицинского учреждения в том виде, как она выглядит на данный момент. Функционирование поликлиники в представлении IDEF0 на нулевом уровне заключается в выполнении трех бизнес-процессов: А1 – «Нанять сотрудника», А2 – «Положить пациента в стационар», А3 – «Вылечить пациента». Эти процессы, а также связи между ними показаны на рисунке 2.4.

Рис. 2.4. Ключевые бизнес-процессы на начальном уровне описания AS-IS

Подвергнем процессы А1 и А3 декомпозиции, получив описание IDEF0 на 1 уровне для каждого из них соответственно (рисунки 2.5 и 2.6).

Рис. 2.5. Бизнес-процесс А1 на 1 уровне описания AS-IS

Рис. 2.6. Бизнес-процесс вылечить пациента на 1 уровне описания AS-IS

Подпроцесс А3-3 – «Провести лечение» нуждается в более подробном рассмотрении. Это можно сделать, подвергнув его декомпозиции. Однако выполнить моделирование 2 уровня детализации, с помощью нотации IDEF0, невозможно, так как в процесс вовлекаются хранилища данных, связывающие между собой подпроцессы 2 уровня в единую цепь (поток данных). В таком случае для моделирования хорошо подходит нотация BPMN SLD, о которой было сказано выше. Результат декомпозиции – описание 2 уровня с помощью нотации BPMN SLD представлено на рисунке 2.7.

Рис. 2.7. Результат декомпозиции процесса А3-3 в нотации BPMN SLD AS-IS

2.6. Проектирование процессов в TO-BE с помощью IDEF0 и BPMN SLD

Проектирование в модели TO-BE позволяет увидеть, как будут выглядеть ключевые бизнес-процессы функционирования медицинского учреждения после внедрения разрабатываемого приложения. Данная особенность проектирования будущих процессов позволяет разработчику представить себе схему работы его приложения на конкретном объекте бизнеса. Важной составляющей разрабатываемого приложения является база данных, призванная заменить все бумажные носители информации. Аналогично модели AS-IS, опишем ключевые бизнес-процессы на разных уровнях с помощью нотаций IDEF0 и BPMN SLD. Описание нулевых уровней бизнес-процесса TO-BE представлено на рисунках 2.8 - 2.11.

Рис. 2.8. Ключевые бизнес-процессы на начальном уровне описания TO-BE

Рис. 2.9. Бизнес-процесс А1 на 1 уровне описания TO-BE

 Рис. 2.10. Бизнес-процесс вылечить пациента на 1 уровне описания TO-BE

Как говорилось выше, для моделирования бизнес-процессов на более высоких уровнях декомпозиции IDEF0 недостаточно, поэтому я проведу моделирование третьего бизнес-процесса в нотации BPMN SLD.

Рис. 2.11. Результат декомпозиции процесса А3-3 в нотации BPMN SLD TO-BE 

Как видно из рисунков приведенных выше, разрабатываемое приложение способно реально упростить работу медперсонала и избавить его от необходимости заполнять значительное количество документов с риском их  потерять. Карта процесса является незаменимым инструментом для визуализации работы конкретных бизнес процессов на предприятии заказчика. На рисунке 2.12. представлена карта процессов.

Рис. 2.12. Карта процессов в модели TO-BE 

Раздел 3. Программно-алгоритмическая часть

На основе проведенного моделирования бизнес-процессов мною был сделан вывод о целесообразности создания базы данных для больницы с последующей роботизацией. Разработка будет проводиться  по спиралевидной модели внедрения. 

3.1. Разработка основы базы данных (1 виток спирали)

На первом витке мною была разработана структура базы данных, а затем нормализована. При проектировании структуры базы данных и её нормализации были учтены требования к наполнению таблиц. После конструирования базы данных она была реализована в СУБД MS Access. Результаты данного этапа разработки показаны на рисунках 3.1 - 3.2.

Рис. 3.1. Результат конструирования базы данных

Рис. 3.2. Демонстрация первого прототипа программы

Во время конструирования базы данных были сконструированы все таблицы. В результате конструирования отдельных таблиц были выбраны размеры и типы данных для каждого поля, которое входит в определенный класс. Результат разработки таблиц продемонстрирован в таблице 3.1.

Таблица 3.1. Список и состав классов 

3.2. Разработка пользовательского интерфейса (2 виток спирали)

На втором этапе разработки был создан пользовательский интерфейс, который позволит пользователю с относительным комфортом взаимодействовать с данным приложением. Данный этап является не менее ответственным, чем предыдущий, так как мало создать табличную базу данных, для базы данных нужен пользовательский интерфейс. Результаты разработки показаны на рисунках 3.3 - 3.9.

Рис. 3.3. Предполагаемый вид главного меню

Рис. 3.4. Главное меню

Рис. 3.5. Предполагаемый вид меню анамнеза

Рис. 3.6. Меню анамнеза

Рис. 3.7. Предполагаемый вид формы для работы с операциями

Рис. 3.8. Форма для работы с операциями

Рис. 3.9. Схема приложения в MS Access

3.3. Разработка элементов роботизации (3 виток спирали)

На третьем этапе разработки были созданы последовательности действий для робота в отдельных элементах интерфейса исходной базы данных. Сначала был создан скрипт, открывающий нашу БД, представлен на рисунке 5.5. После этого были созданы последовательности для работы с данными в базе данных. Так же была добавлена возможность брать информацию из Excel. На данном этапе так же было добавлено закрытие базы данных и сохранение всех изменений внесенных в базу потом. Результаты представлены на рисунках 3.10 - 3.13.

Рис. 3.10. Открытие БД

Рис. 3.11. Удаление записи

Рис. 3.12. Фрагмент последовательности добавления записи

Рис. 3.13. Закрытие БД

3.4. Объединение элементов в целого робота (4 виток спирали)

На данном этапе разработки отдельные последовательности были объединены в целую программу при помощи инструмента «Блок-схема». Для работы с каждым разделом базы данных создана своя блок-схема. Это позволило выбирать какие действия делать в конкретном разделе, но при этом отдельная блок-схема для каждого процесса упростила внесение правок в ходе разработки. Блок-схемы для каждого раздела БД выглядят одинаково, так как вилка возможных действий от раздела к разделу никак не меняется. Затем эти блок-схемы были объединены в одну, что позволило выбирать уже между разделами разработанной базы данных. Результаты разработки представлены на рисунках 3.14 - 3.16.

Рис. 3.14. Основная блок-схема робота

Рис. 3.15. Одна из 4 дополнительных блок-схем отвечающих за отдельный раздел

Рис. 3.16. Выбор раздела для работы

3.5. Нагрузочное тестирование

Нагрузочное тестирование – исследование способности приложения сохранять заданные показатели качества при нагрузке в допустимых пределах, а так же при некотором превышении этих пределов [18]. Проведем тестирование, позволяющее оценить работоспособность разработанного программного обеспечения при поиске и добавлении различного числа записей.

Для проведения теста было выбрано следующее количество записей: 1,50,100. Для того, что бы определить время отклика программы необходимо произвести расчет следующих параметров:

• Среднее арифметическое всех значений времени отклика для конкретного числа записей.
• Среднее квадратичное отклонение.
• Погрешность измерений.
• Время отклика.

Проведем проверку отклика программы и запишем результат проверки, как время отклика в секундах – t₁, t₂, t₃ (таблица 3.2). Рассчитаем среднее арифметическое всех значений времени отклика для конкретного числа записей. Найдем среднее арифметическое по формуле:

                                                         (3.1)

Рассчитав среднее арифметическое всех значений времени отклика, необходимо рассчитать среднеквадратичное отклонение. Воспользуемся формулой для нахождения среднеквадратичного отклонения:

                                                               (3.2)

Далее необходимо рассчитать погрешность измерения по формуле:

                                           (3.3)

где t_a(N-1) – доверительный коэффициент Стьюдента, равный 0.95, t_p – абсолютная погрешность электронного секундомера, которым проводилось измерение равная 0.005.

Таким образом, найдем время отклика приложения при обработке следующего числа записей: 1,50,100 по формуле:

                                                   (3.4)

Таблица 3.2. Определение времени отклика программы 

Раздел 4. Организационно – экономическая часть

В данной выпускной квалификационной работе описано проведение проектирования программного обеспечения для роботизации работы городской больницы. Работа относится к технологическому направлению, поэтому необходимо:

• Оценить актуальность и новизну проектирования программного обеспечения для роботизации работы городской больницы; рассчитать смету затрат на реализацию проекта.
• Данная работа по целевой направленности относится к проекту внутреннего развития.

4.1. Оценка актуальности и новизны

В России согласно  Указу Президента РФ от 09.05.2017 г. N 203 «О Стратегии развития информационного общества в Российской Федерации на 2017 - 2030 годы» была принята стратегия развития информационного общества в России. Целью формирования и развития информационного общества в Российской Федерации, согласно принятой стратегии развития, является повышение качества жизни граждан, обеспечение конкурентоспособности страны, развитие экономической, социально-политической, культурной и духовной сфер жизни общества, совершенствование системы государственного управления на основе использования информационных и телекоммуникационных технологий. К числу основных задач, требующих решения для достижения поставленной цели, относятся:

• формирование современной информационной и телекоммуникационной инфраструктуры, предоставление на ее основе качественных услуг и обеспечение высокого уровня доступности для населения информации и технологий;
• повышение качества образования, медицинского обслуживания, социальной защиты населения на основе развития и использования информационных и телекоммуникационных технологий;
• совершенствование системы государственных гарантий конституционных прав человека и гражданина в информационной сфере;
• развитие экономики Российской Федерации на основе использования информационных и телекоммуникационных технологий и другие.

Задача перевода системы здравоохранения страны на новые информационные и телекоммуникационные технологии отнесена к группе основных задач, заложенных в стратегии развития информационного общества РФ. Роботизация лечебных учреждений в свою очередь не просто переведет работу больниц на компьютерные системы, но значительно облегчит и упростит работу персонала, позволит оптимизировать численность сотрудников, которые занимаются работой с информацией и базами данных о пациентах и сотрудниках. 

4.2. Расчет затрат труда на разработку и оформление документации

Определим трудоемкость каждого этапа и отразим в таблице 4.1. Расчет трудоемкости каждого этапа произведем по формуле (4.1).

                                                    (4.1)

где t_max – продолжительность работы при неблагоприятных условиях. н.час., t_min – продолжительность работы при благоприятных условиях, н.час. 

Таблица 4.1. Трудоемкость этапов

Определив трудоемкость каждого этапа, рассчитаем длительность выполнения работы по формуле (4.2) и запишем в таблицу (4.2):

                                                        (4.2)

где t_ож – ожидаемая продолжительность в норм/час, W_p – количество работников, участвующих в выполнении этапа, чел., q – продолжительность рабочего дня в часах (8 часов), f – коэффициент перевода рабочих дней в календарные (1,2 – 1,3), К_н – планируемый коэффициент выполнения норм по этапу (К_н  = 1,1).

Таблица 4.2. Определение длительности этапов 

4.3. Расчет затрат на программное обеспечение, электроэнергию и амортизацию оборудования

Затраты на лицензионное ПО формируются исходя из цен их приобретения без НДС. Затраты на лицензионное ПО в таблице 4.3.

Таблица 4.3. Затраты на программное обеспечение 

Затраты на электроэнергию рассчитывается по формуле (4.3) 

                                                   (4.3)

где Р – потребляемая мощность оборудования, кВт/ч, Ц_эл – стоимость одного кВт/ч, руб., Т_и – время использования оборудования при проведении работ, ч. Расчет затрат на электроэнергию приведен в таблице 4.4.

Таблица 4.4. Расчет затрат на электроэнергию 

Так как в ВКР предполагается, что специальное оборудование может быть использовано и для других исследований, в статью расходов включается только сумма затрат на амортизацию за время использования конкретного вида оборудования для исследований по рассматриваемой теме. Сумма амортизационных отчислений определяется по следующей формуле (4.4):

                                             (4.4)

где Ф_перв – первоначальная стоимость оборудования и приборов, руб., Т_и – время использования конкретного прибора для исследования, мес. Н_а – годовая норма амортизации:

                                                               (4.5)

где Т_пи – срок службы оборудования, лет. Срок службы компьютера – 2-3 года (на 2018 г.), тогда норма амортизации:

                                                     (4.6)

Таблица 4.5. Затраты на амортизацию оборудования 

4.4. Расчет затрат на оплату труда

Затраты на оплату труда включают зарплату основную (З_осн) и зарплату дополнительную (З_доп). Основная зарплата начисляется исходя из ставки разработчика и времени, затрачиваемого на выполнение работы.

Работу выполнял 1 человек, его ставка составляет 50000 руб./мес. Временные затраты на реализацию проекта составляют – 8 дней (таблица 4.2). Рассчитаем затраты на заработную плату при условии, что количество рабочих дней в месяце равно 22.

                                  (4.7)

Если дополнительная заработная плата составляет 15% от основной, тогда:

ЗП_доп = 0,15 * 18181,8 = 2727,2 руб.                                            (4.8) 

Фонд оплаты труда составит:

Ф_зп = ЗП_осн + ЗП_доп = 18181,8  + 2727,2 = 20909 руб.                              (4.9)

Общие прямые затраты составят следующую сумму:

З_прям = З_м + Ф_зп + А_нир= (10000 + 87,52) + 20909 + 556,87= 31553,39 руб.           (4.10) 

4.5. Прочие расходы

Страховые взносы составляют 30,2% от величины фонда оплаты труда.

 С_взн = 20909 * 0,302 = 6314,52 руб.                                                (4.11)

Таким образом, прочие расходы оставят:

З_пр = С_взн = 6314,52 руб.                                                    (4.12)

Итого, затраты на разработку составят:

З = З_прям + З_пр = 31553,39+ 6314,52= 37867,91 руб.                          (4.13)

Составим смету затрат (таблица 4.6).

Таблица 4.6. Смета затрат 

Представим на диаграмме структуру затрат по проекту (рисунок 4.1).

Рис. 4.1. Затраты на реализацию проекта

Таким образом, больше половины затрат, необходимых на реализацию проекта, составляют затраты на заработную плату. Прочие затраты составляют 16,68% от общей суммы затрат по проекту. Затраты на ПО – 26,4%, амортизацию оборудования – 1,47%, электроэнергию – меньше  одного процента.

Заключение

По итогам данной работы, и в целом учитывая тенденции развития информационного общества, можно с уверенностью утверждать, что переход медицинских учреждений на цифровые решения при обработке информации, с которой они работают, это объективная реальность ближайшего будущего, можно сказать – уже настоящего. 

После декомпозиции по нотациям и сравнении AS-IS и TO-BE можно сделать вывод, что переход от применяемых сегодня методов ведения документооборота в лечебных учреждениях к использованию баз данных приведет к заметному повышению скорости и эффективности их работы.

В ходе разработки программного решения с использованием спиралевидной модели внедрения данных можно сделать вывод, что данный подход весьма эффективен при разработке приложений, которые задействуют сразу несколько связанных между собой программ. Так же данная модель позволяет тестировать создаваемый программный продукт в ходе разработки и сопоставлять результаты промежуточных этапов разработки с требованиями заказчика, что в свою очередь дает возможность сэкономить значительные средства на окончательной доработке приложения и доведения его до вида, который требуется заказчику. Но помимо несомненных плюсов данной модели, в ходе практического ее применения были подтверждены минусы, указанные в ее описаниях. В ходе разработки приходилось ставить четкие сроки для каждого этапа разработки программного обеспечения. Также  в момент разработки  неоднократно была пересмотрена сама концепция работы робота. На третьем этапе разработки пришлось «добавлять» в робота расширенный функционал. Однако, несмотря на минусы спиралевидной модели можно сказать, что она весьма удобна при поэтапной разработке объемного программного обеспечения.

Практическая часть данной работы производилась в СУБД MS Access и в программе для создания процессов автоматизации UiPath. Данные программы имеют существенный плюс в виде простоты создания стандартных решений для автоматизации работы с документооборотом. В MS Access интуитивно понятный процесс создания баз данных. А UiPath в свою очередь позволяет создавать роботов без знания синтаксиса языков программирования. Построение последовательностей и разветвлений действий происходит путем добавления блоков, с понятным графическим обозначением действий за которые они отвечают, а связи между отдельными блоками строятся в пару кликов. Поэтому можно сказать, что данные программные решения сильно упростили создание софта для роботизации городской больницы.

По итогам работы по теме выпускной квалификационной работы мною наработан определенный опыт в разработке сложных многоступенчатых программных решений, которые значительно эффективнее не только архаичных методов ведения бизнес-процессов, но и простых решений по автоматизации работы различных бизнес-структур. Основной результат работы для меня – это понимание не только теоретическое, но и подкрепленное практическими разработками при создании ПО, что система автоматизирующая работу с информацией позволяет значительно оптимизировать расходы организации на сотрудников, работающих с информацией. Это возможно путем сокращения затрат на обработку данных, которая заносится не в бумажные каталоги или обычные базы данных, а в разработанный и изложенный мною в  данной работе программный продукт.  

Список литературы

1. Половодов Д. А., Половодова Е. А., Сергин С. Е. Применение технологии IDEF для моделирования медицинских СУБД // Роль науки в развитии общества. – 2015. – С. 7.
2. РД IDEF0 – 2000. Методология функционального моделирования IDEF0.
3. Степанов Д. Ю. Анализ, проектирование и разработка корпоративных информационных систем: уровень бизнес-процессов / МИРЭА. – М., 2017.
4. Обучающий портал по работе с UiPath. UiPath Academy/ URL: https://academy.uipath.com.
5. Дейт К. Дж. Введение в системы баз данных / пер. с англ. и ред. К. А. Птицына – 8-е изд. – М.: Вильямс – 2016. – 327 с.
6. Орлов С. А. Технологии разработки программного обеспечения. Учебник для вузов. 4-е издание. Стандарт третьего поколения / С. А. Орлов, Б. Я. Цилькер. – М.: Издательский дом «Питер», 27 февр. 2012 г. – 608 с.
7. Невлюдов И. Ш., Евсеев В. В., Бортникова В. О. Модели жизненного цикла программного обеспечения при разработке корпоративных информационных систем технологической подготовки производства. – 2011.
8. Родигин Л. А. Оценка совокупной стоимости владения туристским интернет-проектом. / Л. А. Родигин, К. В. Наймарк. // Litres. – 5 сент. 2017 г.
9. Boehm B.W. A spiral model of software development and enhancement / Boehm B., Egyed A. // IEEE Computer, May 1988, pр. 61-72.
10. Карчевский Е. М., Филиппов И. Е., Филиппова И.А. Access 2010 в примерах. Учебное пособие – К.: Казанский университет – 2012. – 140 с.
11. Фуллер Л. У., Кук К., Кауфельд Д. Microsoft Office Access 2007 для “чайников” / пер. с англ. и ред. А. Г. Сысонюк – М.: Вильямс – 2007. – 384 с.
12. Одиночкина С. В. Разработка баз данных в Microsoft Access 2010 – СПб.: НИУ ИТМО – 2012. – 83 с.
13. Бекаревич Ю. Б., Пушкина Н. В. Самоучитель Microsoft Access 2013 – СПб.: БХВ-Петербург – 2014. – 464 с.
14. Нотация BPMN 2.0: ключевые элементы и описание. URL: https://www.comindware.com/ru/blog-нотация-bpmn-2-0-элементы-и-описание.
15. Анисимов В. В. Проектирование информационных систем. Конспект лекций. М.: Дальневосточный государственный университет путей сообщения. URL: https://sites.google.com/site/anisimovkhv/publication/umr/pris
16. INTERNATIONAL STANDARD ISO/IEC/IEEE 24765. Systems and software engineering – Vocabulary – 2010. – 410 с.
17. Требования. Анализ требований, виды требований – URL: https://intellect.ml/trebovaniya-analiz-trebovanij-vidy-trebovanij-5188.
18. Куликов С. C. К90 Тестирование программного обеспечения. Базовый курс / С. С. Куликов. – Минск: Четыре четверти, 2017. – 312 с.
19. Виды тестирования программного обеспечения – URL: http://www.protesting.ru/testing/testtypes.html.
20. Ларина Ю.А. “Основы объектно-ориентированного моделирования с использованием языка UML”. Учебное пособие, Ярославль, 2010 – 152 с.

Выходные данные

Чепров Е.Д. Роботизация работы городской больницы на основе спиралевидной модели внедрения информационных систем: диплом бакалавра / МИРЭА. – М., 2020. – 51 с. – URL: https://stepanovd.com/training/20-vkr/102-vkrb-2020-1-cheprov.