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

Аннотацияв работе реализуется роботизация работы городской больницы с применением спиралевидной методологии внедрения медицинских информационных систем с использованием 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, модель определяет четыре действия, каждое из которых соответствует своему квадранту спирали:

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

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

Рис. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Название класса

Поля данных

Тип данных

Размерность

Анамнез Код анамнеза (ключевое поле) Счётчик Длинное целое
Код пациента (внешний ключ) Числовой Длинное целое
Диагноз Текстовый 255
Лечение Текстовый 255
Жалобы пациента Текстовый 255
Ход реабилитации Текстовый 255
Дата Дата/время 255
Пациенты Код пациента (ключевое поле) Счетчик Длинное целое
Фамилия пациента Текстовый 255
Имя пациента Текстовый 255
Отчество пациента Текстовый 255
Номер телефона Числовой Длинное целое
Номер страхового полиса Числовой Длинное целое
Дата рождения Дата/время 255
Пол Текстовый 255
Операции Код (ключевое поле) Счетчик Длинное целое
Код врача (внешний ключ) Числовой Длинное целое
Дата операции Дата/время 255
Время операции Дата/время 255
Код пациента (внешний ключ) Числовой Длинное целое
Персонал Код врача (ключевое поле) Счетчик Длинное целое
Фамилия Текстовый 255
Имя Текстовый 255
Отчество Текстовый 255
Должность Текстовый 255
Специальность Текстовый 255
Пол Текстовый 255
Номер телефона Числовой Длинное целое

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

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

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

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

Главное меню

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

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

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

Меню анамнеза

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

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

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

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

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

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

Рис. 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. Основная блок-схема робота

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

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

Выбор раздела для работы

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

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

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

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

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

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

                                                         (3.1)

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

                                                               (3.2)

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

                                           (3.3)

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

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

                                                   (3.4)

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

Количество записей

Действие

t1, c.

t2, c.

t3, c.

Среднее время отклика

Средне- квадратичное отклонение

Погреш. измерений ∆t

Время отклика, tоткл

1 Запись 0,05 0,06 0,07 0,06 0,006 0,005  0,06±0,005
Поиск 0,06 0,06 0,05 0,056 0,005 0,003  0,056±0,003
50 Запись 0,1 0,09 0,11 0,1 0,008 0,01  0,1±0,01
Поиск 0,08 0,09 0,1 0,09 0,007 0,008 0,09±0,008
100 Запись 0,15 0,14 0,11 0,133 0,01 0,02 0,133±0,02
Поиск 0,16 0,14 0,13 0,143 0,014 0,018 0,143±0,018

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

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

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

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

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

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

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

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

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

                                                    (4.1)

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

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

Сотрудник

Продолжительность работы, норм/час
tmin

tmax

tож

 Обзор литературы 10 15 12,0
 Конструирование базы данных 7 10 8,2
 Изучение ПО MS Access 6 10 7,6
 Изучение ПО UiPath 6 10 7,6
 Создание базы данных в MS Access 5 9 6,6
 Создание робота в UiPath 10 15 12
 Проведение тестирования получившегося ПО 3 6 4,2
Выводы по результатам тестирования  3 7 4,6
Оформление отчёта о проделанной работе  12 20 15,2

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

                                                        (4.2)

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

Таблица 4.2. Определение длительности этапов 
Название этапа tож , н./час

Wp , чел.

Тэ, календ. дней

 Обзор литературы 12,0 1 1,14
 Конструирование базы данных 8,2 1 0,78
 Изучение ПО MS Access 7,6 1 0,69
 Изучение ПО UiPath 7,6 1 0,69
 Создание базы данных в MS Access 6,6 1 0,63
 Создание робота в UiPath 12 1 1,14
 Проведение тестирования получившегося ПО 4,2 1 0,38
Выводы по результатам тестирования  4,6 1 0,44
Оформление отчёта о проделанной работе  15,2 1 1,43
Итого 8

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

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

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

Наименование ПО

Стоимость единицы в рублях

Количество, шт. 

Сумма, руб.

MS Office 10000 1 10000
UiPath Community Cloud 0 1 0
Итого 10000

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

                                                   (4.3)

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

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

Наименование оборудования

Мощность электрооборудования, кВт/ч.

Время использования, ч.

Цена одного кВт/ч, руб.

Сумма затрат на эл. энергию, руб.

Персональный компьютер 0,12 192 5,47 126,03
Итого 126,03

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

                                             (4.4)

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

                                                               (4.5)

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

                                                     (4.6)

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

Наименование оборудования

Первоначальная стоимость оборудования и приборов, руб.

Норма амортизации

Время использования конкретного прибора для исследования, мес.

Сумма амортизационных отчислений, руб.

Персональный компьютер 75000 0,33 0,27 (8 дней) 556,87
Итого 556,87

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. Смета затрат 

Наименование калькуляционных статей расходов

Сумма, руб.

Удельный вес, %

Затраты на ПО 10000 26,4
Затраты на электроэнергию 126,03 0,33
Затраты на заработную плату 20909 55,15
Затраты на амортизацию оборудования 556,87 1,47
Прочие затраты 6314,52 16,66
Итого затраты на реализацию проекта 37906,42 100,0

Представим на диаграмме структуру затрат по проекту (рисунок 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.