Автоматизация ключевого бизнес-процесса врача терапевта в городской поликлинике на основе спиралевидной модели внедрения информационных систем

Подробности

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

Автор: Дудкин Дмитрий Игоревич

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

Аннотация: в работе реализуется программное обеспечение для использования на рабочем месте врача-терапевта в виде автоматизированной системы. Программное обеспечение позволит сохранять всю информацию о пациенте, его посещениях, историю болезни, облегчить и ускорить работу врача.
Скачать: PDF, PPT, AVI.
Ключевые слова: спиралевидная методология, жизненный цикл ПО, принцип связности, модель жизненного цикла, итерационная модель, дефицит специалистов, золотая сервировка, качественный анализ, количественный анализ, анализ предметной области, сбор требований, назначение приоритетов, моделирование данных, ключевые бизнес-процессы, методология ARIS, value-added chain diagram, UML Activity Diagram.

Введение

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

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

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

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

Разработку такого приложения можно произвести в программе MS Access. Данная среда совместима с операционной системой Microsoft Windows, которая используется на большинстве компьютеров медицинских учреждений, что важно для удобства использования. Таким образом, можно сделать вывод о целесообразности и актуальности проведения данной работы. 

Цель и задачи

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

• произвести детальный анализ спиралевидной методологии внедрения систем;
• идентифицировать требования и сформулировать список требований;
• произвести проектирование процессов и оргструктуры в моделях AS-IS и TO-BE  нотации ARIS VACD и UML AD до 3-4 уровней детализации.

В спиралевидной методологии внедрения систем для каждого витка спирали произвести:

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

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

Раздел 1. Детальный анализ спиралевидной методологии внедрения систем  

1.1. Жизненный цикл программного обеспечения

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

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

Рис. 1.1. Общепринятая модель жизненного цикла ПО

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

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

1.2. Спиралевидная методология внедрения

В данной методологии делается упор на начальные этапы жизненного цикла системы: анализ и проектирование. Спиральная модель (рисунок 1.2) – классический пример применения эволюционной стратегии разработки [2]. Следует отметить, спиралевидную модель нередко рассматривают как частный случай итерационной модели.

Рис. 1.2. Спиралевидная модель 

Из рисунка 1.2 имеем:

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

Как показано на рисунке 1.2, модель определяет четыре действия, каждое из которых соответствует своему квадранту спирали [3]: 

• Планирование – определение целей, вариантов и ограничений.
• Анализ риска – анализ вариантов и распознавание/выбор риска.
• Конструирование – разработка продукта следующего уровня.
• Оценивание – оценка заказчиком результатов конструирования.

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

Спиральная модель позволяет начинать работу над следующим этапом, не дожидаясь завершения предыдущего. Целью данной модели является возможность как можно раньше ознакомить пользователей с работоспособным продуктом, корректируя при необходимости требования к разрабатываемому продукту и каждый "виток" спирали означает создание фрагмента или версии. Основная проблема спирального цикла - определение момента перехода на следующий этап, и возможным ее решением является принудительное ограничение по времени для каждого из этапа жизненного цикла [4]. 

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

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

Основными плюсами данной методологии является:

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

Но также у данной системы есть свои минусы:

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

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

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

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

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

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

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

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

Раздел 2. Идентификация требований

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

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

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

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

• Анализ предметной области. Аналитики должны изучить предметную область, где будет эксплуатироваться система.
• Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.
• Назначение приоритетов. В любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования. Идентификация предварительных требований к новому продукту позволяет, в соответствии с требованиями клиента, определить характеристики нового продукта.

2.1. Анализ предметной области

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

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

В дальнейшем будем работать с такими ключевыми бизнес-процессами, как: «Приём пациента», «Лечение пациента», «Реабилитация пациента». 

2.2. Пользовательские и функциональные требования, их приоритизация

Далее был составлен список выявленных пользовательских требований:

• хранение данных о пациенте (Фамилия, Имя, Отчество, дата рождения и т.д.);
• хранение данных о записи на приём (когда и сколько раз был на приёме, по какой причине);
• хранение данных об истории лечения пациента (какие лекарства были назначены, направление на анализы);
• хранение данных о реабилитации пациента (какими лекарствами происходило лечение, помогли ли они; если не помогли, назначение новых препаратов);
• сведения, полученные путём расспроса пациента (обследуемого);
• управление данными о записи на прием (изменение, удаление, добавление, сортировка);
• управление данными, полученными путём расспроса пациента (изменение, удаление, добавление, сортировка);
• управление данными о лечении пациента (изменение, удаление, добавление, сортировка);
• разграничение доступа (Для того, чтобы защитить данные пациента);
• разработка интерфейса (Для ускорения приема пациентов).

Следующим шагом выявим функциональные требования для того, чтобы выполнить пользовательские требования. Функциональные требования (functional requirements) определяют функциональные возможности разрабатываемого ПО для реализации пользовательских требований. Выделим данные требования для нашего ключевого бизнес процесса:

• база данных, содержащая таблицы «Личные данные пациентов», «Даты посещений», «Причины посещения», «Лечение пациента», «Направление на анализ», «Анализ мочи», «Анализ кала», «Анализ крови», «Реабилитация пациента»; 
• вывод на экран данных из вышеперечисленных таблиц;
• добавление данных о пациенте; 
• редактирование данных о пациенте во всех таблицах;
• поиск конкретного пациента по ФИО во всех таблицах; 
• программа должна корректно работать на всех компьютерах медучреждения; 
• данные хранятся непосредственно в создаваемом приложении; 
• установление пароля на саму базу данных; 
• разработка интерфейса для простоты использования продукта.

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

• Приоритет №1 – данные требования является основой разрабатываемой системы. Без выполнения данного пункта реализовать систему не получится. 
• Приоритет №2 – данные требования критичны для функциональных возможностей системы, но не сильно отразятся на работе программы при их отсутствии.
• Приоритет №3 – данные требования не являются ключевыми для полноценного функционирования самой программы, но их было бы неплохо реализовать. 

2.3. Список требований

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

Таблица 2.3. Список требований для разрабатываемого продукта

2.4. Задание циклов разработки по спиралевидной модели

Разработка программного продукта согласно спиралевидной модели будет производиться в следующем порядке:

• начало:
  • анализ требований (19 требований – см. табл. 2.3);
  • моделирование ключевых бизнес-процессов с помощью нотаций ARIS VACD и UML AD;
  • моделирование данных и интерфейсов программ;
  • анализ рисков на основе полученных требований; 
  • составление плана разработки по спиральной модели.
• 1-й виток спирали:
  • планирование текущего цикла разработки (реализовать требования 1-9 в среде MS Access); 
  • моделирование данных и интерфейсов программ;
  • анализ рисков на основе полученных требований; 
  • реализация требований 1-9 в среде MS Access; 
  • тестирование реализованных возможностей программы; 
  • демонстрация прототипа программы заказчику. 
• 2-й виток спирали:
  • планирование текущего цикла разработки (реализовать требования 10-17 в среде MS Access); 
  • моделирование данных и интерфейсов программ;
  • анализ рисков на основе полученных требований;
  • реализация требований 10-17 в среде MS Access; 
  • тестирование реализованных возможностей программы; 
  • демонстрация прототипа программы заказчику. 
• 3-й виток спирали:
  • планирование текущего цикла разработки (реализовать требование 18-19 в среде MS Access); 
  • анализ рисков на основе полученных требований и всего процесса реализации витков; 
  • реализация требований 18-19 в среде MS Access;
  • тестирование реализованных возможностей программы; 
  • подготовка к релизу (исправление мелких недостатков, ошибок и т.д.); 
  • тестирование конечного продукта; 
  • релиз конечного продукта.

Раздел 3. Проектирование ключевых бизнес-процессов

Бизнес-процесс – это устойчивая целенаправленная последовательность исполнения функций, направленная на создание результата, имеющего ценность для потребителя [6]. При проектировании ключевых бизнес-процессов используют две модели: AS-IS (как есть) и TO-BE (как будет):

• модель AS-IS, которая описывает состояние моделируемой предметной области на момент создания модели;
• модель TO-BE, описывающая возможное будущее состояние предметной области, в которое она перейдёт в результате оптимизации существующей системы и внедрения новых технологий [7].

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

3.1. Проектирование на основе нотации ARIS VACD

Сила методологии ARIS заключается в ее комплексности, которая проявляется во взаимосвязи моделей, построенных в различных нотациях. Методология ARIS позволяет описывать деятельность организации с разных точек зрения, при этом полученные модели в определенной степени связаны между собой [8]. Основными минусами данного подхода является:

• Наличие инструментальной среды ARIS. Она является дорогостоящей и достаточно сложной в использовании. Но существует упрощенная и бесплатная версия под названием ARIS Express.
• Трудно реализуемые задачи на практике, так как влекут большой расход ресурсов (человеческих, материальных и финансовых) в течение длительного времени.

Одной из важнейших нотаций ARIS является нотация Value-added Chain Diagram. Она используется для описания бизнес-процессов организации на верхнем уровне.

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

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

Таблица 3.1. Условные обозначения нотации ARIS VACD

Графическое представление	Наименование	Описание
	Процесс	Описание работ, выполняемых сотрудниками организации
	Входящий или исходящий объект	Элементы, содержащие носители информации
	Организационная единица	Отражает звенья, ответственные за исполнение процесса

3.2. Проектирование на основе нотации UML Activity Diagram

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

Язык UML (Unified Modeling Language), или унифицированный язык моделирования, предназначен для описания, визуализации, проектирования и документирования объектно-ориентированных систем и бизнес-процессов с ориентацией на их последующую реализацию в виде программного обеспечения [9].

Для моделирования процесса выполнения операций в языке UML используются диаграммы деятельности (Activity diagram). Они служат для моделирования последовательности действий, которые выполняются различными элементами, входящими в состав системы. Другими словами, этот вид диаграмм раскрывает детали алгоритмической реализации операций, выполняемых системой, поэтому диаграмма деятельности похожа на обычную блок-схему [10]. Но в отличие от блок-схемы, диаграмма деятельности также показывает одновременно параллельную и последовательную деятельность.

UML AD нотация проста для изучения неподготовленным пользователем, она интуитивно понятна. Данная нотация использует широко известные графические элементы (табл.3.2). В UML AD нотации изображение процессов очень похоже на блок-схемы, то есть многим пользователям изображения в UML AD нотации сразу будут подсознательно ясны. 

Таблица 3.2. Условные обозначения нотации ARIS VACD

Графический элемент	Описание	Графический элемент	Описание
	Начало		Ответственный организационный уровень
	Конец		Условие
	Процесс		Разветвитель
	Входящие/исходящие документы		Соединитель

3.3. Проектирование процессов в моделях AS-IS и TO-BE с помощью UML AD и ARIS VACD

На рисунках 3.2 и 3.3 рассматривается первый уровень проектирования процесса работы врача-терапевта в аннотации ARIS VACD модели «AS-IS», которая подразумевает под собой проектирование процессов в настоящий момент времени и модели «TO-BE» после внедрения электронной базы данных.

Рис. 3.2. Представление процесса в ARIS VACD на первом уровне в модели «AS-IS»

Рис. 3.3. Представление процесса в ARIS VACD на первом уровне в модели «TO-BE»

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

На рисунках 3.4 и 3.5 представлен второй уровень детализации для уточнения процесса «Прием пациента». Второй уровень детализации процессов «Лечение пациента» и «Реабилитация пациента» представлен в приложении (Рис.8.1, Рис.8.2, Рис.8.5, Рис.8.6).

Рис. 3.4. Представление подпроцесса в UML AD на втором уровне в модели «AS-IS» для уточнения процесса «Прием пациента»

Рис. 3.5. Представление подпроцесса в UML AD на втором уровне в модели «TO-BE» для уточнения процесса «Прием пациента»

На рисунках 3.6 и 3.7 представлен третий уровень детализации для уточнения процесса «Приступить к анамнезу». Третий уровень детализации процессов «Лечение пациента» и «Реабилитация пациента» представлен в приложении (Рис.8.3, Рис.8.4, Рис.8.7, Рис.8.8.).

Рис. 3.6. Представление процесса в UML AD на третьем уровне в модели «AS-IS» для уточнения процесса «Приступить к анамнезу» 

Рис. 3.7. Представление процесса в UML AD на третьем уровне в модели «TO-BE» для уточнения процесса «Приступить к анамнезу»

Для более наглядного представления вышеуказанных бизнес-процессов на 1-3 уровнях, построим карту бизнес-процессов в модели «TO-BE» (рисунок 3.8).

Рис. 3.8. Карта бизнес-процессов в модели «TO-BE»

3.4. Архитектура данных разрабатываемой системы

На основе порядка использования данных, рассмотренного выше, всю информацию можно разбить на классы, приведённые в таблице 3.4. 

Таблица 3.4. Классы данных 

Далее необходимо провести процедуру нормализации данных [11]. Стандартно все данные приводят к третьей нормальной форме (НФ), потому как нормализации такого уровня бывает достаточно. Согласно первой НФ, в одном поле таблицы должен храниться только один атрибут. Таким образом, в классе «Личные данные пациентов» и «Даты посещений» данные «ФИО» и «ФИО врача»  необходимо разбить на три отдельные строки: «Фамилия», «Имя», «Отчество». 

Согласно второй НФ, должны соблюдаться условия первой НФ и каждый не ключевой атрибут должен зависеть от ключа. Следовательно, в классы «Личные данные пациентов» и «Даты посещений»  добавляется графа «Код пациента», а в таблицы «Даты посещений» и «Причина посещений» добавляется графа «Код причины посещения». 

В третьей НФ должны соблюдаться условия второй НФ и все не ключевые поля, содержимое которых может относиться к нескольким записям таблицы, должно выноситься в отдельные таблицы. Таким образом, после разделения всех данных на классы и проведения процедуры нормализации, получается нормализованная таблица класса данных (табл.3.5) и архитектура разрабатываемого приложения, приведённая на рисунке 3.9. 

Таблица 3.5. Классы данных (нормализованная) 

Рис. 3.9. Архитектура данных разрабатываемого приложения 

3.5. Описание разрабатываемого приложения

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

Рис. 3.10. Интерфейс базы данных 

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

Рис. 3.11. Интерфейс «Добавление и поиск пациента» 

Рис. 3.12. Интерфейс «Добавление даты посещения»

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

Рис. 3.13. Интерфейс «Добавление причины посещения»

Далее следует внести информации о лекарствах, которые назначил врач пациенту. Для этого следует нажать на кнопку «Добавить лечение пациента». На экране отобразится окно, представленное на рисунке 3.14. После внесения нужной информации она появится в таблице «Лечение пациента».

Рис. 3.14. Интерфейс «Добавить лечение пациента»

Если врач не может точно определить, в чём заключается причина болезни, то пациент направляется на сдачу анализов. Для этого врач-терапевт должен распечатать пациенту направление на анализ. Форма для печати представлена на рисунке 3.15.

Рис. 3.15. Интерфейс «Направление на анализ»

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

Рис. 3.16. Интерфейс «Анализ крови»

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

Рис. 3.17. Интерфейс «Реабилитация пациента»

Для более наглядного представления работы программы, создадим её блок-схему. Компоненты блок-схемы представлены на рисунке 3.18, а сама схема на рисунках 3.19.1 и 3.19.2.

Рис. 3.18. Компоненты блок-схемы

 Рис. 3.19.1. Блок-схема базы данных (Часть 1)

Рис. 3.19.2. Блок-схема базы данных (Часть 2)

Работа программы будет вестись согласно представленной схеме на рисунке 3.20.

 Рис. 3.20. Схема программы

Раздел 4. Разработка приложения  

4.1. Первый прототип программы (I виток спирали)

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

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

На рисунках 4.1 – 4.9 представлены фрагменты таблиц «Личные данные пациента», «Даты посещений», «Причина посещения», «Лечение пациента», «Направление на анализ», «Анализ крови», «Анализ мочи», «Анализ кала», «Реабилитация пациента» созданные в программе MS Access.

Рис. 4.1. Фрагмент таблицы «Личные данные пациента» базы данных

Рис. 4.2. Фрагмент таблицы «Даты посещений» базы данных

Рис. 4.3. Фрагмент таблицы «Причина посещения» базы данных

Рис. 4.4. Фрагмент таблицы «Лечение пациента» базы данных

Рис. 4.5. Фрагмент таблицы «Направление на анализ» базы данных

Рис. 4.6. Фрагмент таблицы «Анализ крови» базы данных

Рис. 4.7. Фрагмент таблицы «Анализ мочи» базы данных

Рис. 4.8. Фрагмент таблицы «Анализ кала» базы данных

Рис. 4.9. Фрагмент таблицы «Реабилитация пациента» базы данных

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

Рис. 4.10. Схема данных

4.2. Второй прототип программы (II виток спирали)

На данном этапе реализовывается возможность просмотра данных, а также возможность изменения, удаления, внесения и поиска информации о пациенте, а также для печати (рисунки 4.11 – 4.19). Для чего создаётся «Форма» – объект, с помощью которого пользователи могут добавлять, редактировать и отображать данные.

Основным риском на данном этапе разработки программы является человеческий фактор-невнимательность врача при внесении данных пациента. Со стороны пользователя ПО - врача необходимо быть более внимательным при работе с персональными данными пациентов.

Рис. 4.11. Форма «Добавление пациента» с возможностью поиска, удаления, добавления пациентов и печати информации

Рис. 4.12. Форма «Добавление даты посещения» с возможностью поиска, добавления и удаления даты посещения пациента

Рис. 4.13. Форма «Добавление причины посещения» с возможностью поиска, добавления и удаления причины посещения пациента

Рис. 4.14. Форма «Лечение пациента» с возможностью поиска, добавления и удаления информации о лечении пациента

Рис. 4.15. Форма «Направление на анализ» с возможностью поиска, добавления, удаления и печати направления на анализ пациента

Рис. 4.16. Форма «Результаты анализа крови» с возможностью поиска и печати результатов анализа пациента

Рис. 4.17. Форма «Результаты анализа мочи» с возможностью поиска и печати результатов анализа пациента

Рис. 4.18. Форма «Результаты анализа кала» с возможностью поиска и печати результатов анализа пациента

Рис. 4.19. Форма «Реабилитация пациента» с возможностью поиска, добавления и удаления истории реабилитации пациента

4.3. Конечный продукт (III виток спирали)

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

Рис. 4.20. Окно для ввода пароля

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

Рис. 4.21. Окно, оповещающее о неправильном вводе пароля

Так же следует создать интерфейс для ускорения приёма пациентов и упрощения работы пользователя (рисунок 4.22).

Рис. 4.22. Главное меню приложения

Первая кнопка – «Добавление и поиск пациента», при нажатии на эту кнопку происходит переход в форму с информацией о пациентах. Форма представлена на рисунке 4.11. В ней можно произвести поиск информации о нужном нам пациенте, добавить нового при нажатии на кнопку «Добавить пациента», удалить пациента, либо отредактировать данные, которые уже существуют в этой форме.

Вторая кнопка – «Добавление даты посещения». При нажатии на неё происходит переход в форму с датами посещений пациентов. В ней можно посмотреть даты посещений пациентов и добавить новые. Данная форма представлена на рисунке 4.12.

Третья кнопка – «Добавление причины посещения». При нажатии на неё происходит переход в форму с причинами посещений всех пациентов. В ней можно посмотреть историю болезней пациентов, а также добавить новые. Данная форма представлена на рисунке 4.13.

Четвертая кнопка – «Добавить лечение пациента». При нажатии на неё происходит переход в форму со всей информацией об истории лечения пациентов. В ней можно посмотреть историю лечения пациента, а также добавить новое, в случае необходимости. Данная форма представлена на рисунке 4.14.

Пятая кнопка – «Направление на анализ». В этой форме можно сделать направление пациенту на какой-либо анализ, распечатать его и поставить печать. Данная форма представлена на рисунке 4.15.

Шестая - восьмая кнопки - «Анализ крови/мочи/кала». При нажатии на эти кнопки будет происходить переход в формы результатами анализов пациентов. В ней можно посмотреть информацию о результатах анализов для принятия решения о том, чем производить лечение пациента. Данные формы представлены на рисунках 4.16 – 4.18.

Девятая кнопка – «Реабилитация пациента». При нажатии на эту кнопку будет происходить переход в форму, содержащую информация о том, как происходить реабилитация пациента. В ней можно посмотреть как происходит реабилитация пациента. В случае осложнения/ухудшения состояния назначить новые лекарства. Данная форма представлена на рисунке 4.19. Десятая кнопка – «Выход». При нажатии на неё происходит выхода из приложения.

Раздел 5. Тестирование разработанного приложения

Тестирование программного обеспечения – процесс анализа программного продукта и сопутствующей документации с целью выявления недостатков в работе и повышения его качества [13]. Обычно для проверки работоспособности разработанной программы проводят три вида тестирования: функциональное, интеграционное и нагрузочное.

Функциональное тестирование (Functional testing) – вид тестирования, направленный на проверку корректности работы функциональности приложения (корректность реализации функциональных требований). Описание разработанных модулей программы, соответствующих требованиям (табл. 2.3) приведено в п. 4.1 – 4.3. Функциональное тестирование данных модулей показало их полную работоспособность и отсутствие ошибок, т.е. все функциональные требования были успешно реализованы.

Интеграционное тестирование (integration testing) направлено на проверку взаимодействия между несколькими частями приложения. Данное тестирование проводится в случае, когда происходит взаимодействие модулей программы (II виток спирали). Данная проверка оказалась успешной. В частности, в процессе записи пациента на прием происходит добавление в таблицу «Личные данные пациентов» данных, введенных в форму для добавления пациента (рис.4.5). Данный процесс выполняется без сбоев в работе программы. Аналогично можно рассмотреть процесс добавления причины посещения пациента. В процессе добавления причины посещения для пациента с помощью нужной формы (рис.4.6), соответствующая запись появляется в таблице «Причины посещения». Данный процесс также работает без сбоев.

Нагрузочное тестирование (load testing, capacity testing) – исследование способности приложения сохранять заданные показатели качества при нагрузке в допустимых пределах и некотором превышении этих пределов (определение «запаса прочности») [14]. Нагрузочное тестирование проводилось для исследования быстродействия таких процессов, как, например, запись пациента на прием (поскольку этот процесс призван уменьшить время ожидания пациентов в очередях, то предполагается, что его выполнение не должно занимать много времени) и поиск записи. Для тестирования было выбрано следующее количество записей: 5 (в среднем посетителей за час работы), 50 ( в среднем посетителей за день) и 500 ( в среднем посетителей на 2 недели). Результаты нагрузочного тестирования приведены в табл.6.

Вначале 5 раз проводится проверка отклика системы на различные действия, ее результаты вносятся в соответствующие строки столбцов t1-t5. Далее рассчитывается среднее арифметическое всех измерений по формуле (1):

                                                                                                                      (1)

Результат заносится в столбец «Среднее время отклика» таблицы. В следующем столбце находятся соответствующие средние квадратические отклонения, рассчитанные по формуле (2):

                                                                                                               (2)

Погрешность измерений рассчитывалась по формуле (3) и заносилась в столбец «Погрешность измерений», где n – число измерений, – доверительный коэффициент Стьюдента, равный 0.95, - абсолютная погрешность электронного секундомера равная 0,005.

                                                                                                             (3)

В столбце «Время отклика» – итоговое время отклика. Оно рассчитывалось по формуле (4):

                                                                                                                   (4) 

Таблица 6. Результаты нагрузочного тестирования

Как видно из табл. 6, время отклика не превышает 0,5 с и почти не замечается пользователем. Таким образом, можно сделать вывод, что нагрузочное тестирование проведено успешно. 

 Заключение

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

• В процессе работы были проанализированы пользовательские требования (19 требований), полученные путем опроса и изучения документации.
• Были определены приоритеты полученных требований. 
• На основе пользовательских требований были составлены функциональные требования, которые должны быть реализованы в разрабатываемом приложении.
• Составлен список требований, связывающий вместе пользовательские, функциональные требования, их приоритет, а также программные компоненты, отвечающие за реализацию данных требований; 
• После формирования списка требований произошло деление всех требований на 1-3 уровни спирали. 
• После того, как требования были проанализированы, проводилось составление моделей AS-IS и TO-BE ключевых бизнес-процессов организации в нотациях ARIS VACD (0-1 уровни) и UML Activity Diagram (2-3 уровень), и проведено их сопоставление на каждом уровне. Это позволило определить структуру разрабатываемого приложения. 
• Разработка приложения производилась в среде MS Access, где поэтапно были реализованы все указанные требования, исправлены недочеты и ошибки в работе программы. Эта программа является простой и понятной в обращении; является полностью совместимой с системой Windows и обладает огромными возможностями по импорту и экспорту данных.
• После каждого этапа (витка спирали) разработки проводилось функциональное тестирование разработанных модулей программы, показавшее их работоспособность и соответствие заявленным требованиям. 
• При завершении заключительного этапа разработки проведено интеграционное тестирование для проверки взаимодействия программных модулей, также показавшее их полную работоспособность. 
• Затем было проведено нагрузочное тестирование при различном количестве записей в БД, свидетельствующее о высокой производительности программы.  

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

1. Е.А. Кумагина, Е.А. Неймарк. «Модели жизненного цикла и технологии проектирования программного обеспечения». Учебно-методическое пособие, Нижний Новгород, 2016 - 250 с.
2. Орлов С. А. Технологии разработки программного обеспечения. Учебник для вузов. 4-е издание. Стандарт третьего поколения / С. А. Орлов, Б. Я. Цилькер. – М.: Издательский дом «Питер», 27 февр. 2012 г. – 608 с.
3. Елочкин М.Е., Брановский Ю.С., Николаенко И.Д. «Информационные технологии». Издательство «Оникс», Москва, 2009. 389 с.
4. Родигин Л. А. Оценка совокупной стоимости владения туристским интернет-проектом. / Л. А. Родигин, К. В. Наймарк. // Litres. – 5 сент. 2017 г.
5. Boehm B.W. A spiral model of software development and enhancement / Boehm B., Egyed A. // IEEE Computer, May 1988, 250 с.
6. А.В. Варзунов, Е.К. Торосян, Л.П. Сажнева. «Анализ и управление бизнес-процессами» .Учебное пособие, 2010 – 212 с.
7. И.В.Абрамов. Методические указания по дисциплине «Модели и методы информационно-управляющих систем». Ижевск, 2004 – 314 с.
8. Владимир Репин, Виталий Елиферов. «Процессный подход к управлению». Моделирование бизнес-процессов. Издательство «Манн, Иванов и Фербер», Москва, 2013 – 215 с.
9. Ю.А.Ларина. «Основы объектно ориентированного моделирования с использованием языка UML». Учебное пособие, Ярославль, 2010 – 152 с.
10. Ю.А.Ларина. «Основы объектно ориентированного моделирования с использованием языка UML». Учебное пособие, Ярославль, 2010 – 152 с.
11. Дейт К. Дж. Введение в системы баз данных / пер. с англ. и ред. К. А. Птицына – 8-е изд. – М.: Вильямс – 2016. – 327 с.
12. Епанешников А.М., Епанешников В.А. Практика создания приложений в Access. – 2009. – 440 с.
13. Штенников Д.Г. Разработка информационных систем в образовании. Учебное пособие. – СПб: СПбГУ ИТМО, 2012. – 242 с.
14. Куликов С. С. Тестирование программного обеспечения //Базовый курс: практ. пособие. Минск: Четыре четверти. – 2015. – 136 с.

Приложение А

Рис. 8.1. Представление процесса в UML AD на втором уровне в модели «AS-IS» для уточнения процесса «Лечение пациента»

Рис. 8.2. Представление процесса в UML AD на втором уровне в модели «TO-BE» для уточнения процесса «Лечение пациента»

Рис. 8.3. Представление процесса в UML AD на третьем уровне в модели «AS-IS» для уточнения процесса «Приступить к лечению»

Рис. 8.4. Представление процесса в UML AD на третьем уровне в модели «TO-BE» для уточнения процесса «Приступить к лечению»

Рис. 8.5. Представление процесса в UML AD на втором уровне в модели «AS-IS» для уточнения процесса «Реабилитация пациента»

Рис. 8.6. Представление процесса в UML AD на втором уровне в модели «TO-BE» для уточнения процесса «Реабилитация пациента»

Рис. 8.7. Представление процесса в UML AD на третьем уровне в модели «AS-IS» для уточнения процесса «Продолжить наблюдения»

Рис. 8.8. Представление процесса в UML AD на третьем уровне в модели «TO-BE» для уточнения процесса «Продолжить наблюдения»

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

Дудукин Д.И. Автоматизация ключевого бизнес-процесса врача терапевта в городской поликлинике на основе спиралевидной модели внедрения информационных систем: диплом бакалавра / МИРЭА. –  М., 2019. –  74 с. – URL: https://stepanovd.com/training/20-vkr/98-vkrb-2019-3-dudkin.