Разработка автоматизированного рабочего места врача-невролога с использованием метода Agile Scrum

Подробности

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

Автор: Деревнина Ангелина Михайловна

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

Аннотация: реализуется приложение на основе MS Access для автоматизированного рабочего места врача невролога на основе метода Agile Scrum. Проводится анализ требований позволяющий сформировать бэклог продукта, а также задать и определить бэклог спринтов. Идентифицированные ключевые бизнес-процессы врача невролога проектируются в нотации UML Activity Diagram с разным уровнем детализации, кроме того, ведется задание архитектуры данных. Смоделированные процессы и данные реализуются в среде MS Access. Проводятся функциональное и интеграционные виды испытаний разработанного приложения.
Скачать: PDF, PPT.
Ключевые слова: гибкая agile scrum, agile scrum проект, agile scrum разработка, арм врача невролога, рабочее место врача невролога, бизнес процессы врача невролога, обследование врача невролога, медико информационные системы, медицинские информационные системы, ЕГИСЗ, классификация медицинских информационных систем, информационная модель лечебно-диагностического процесса, автоматизация неврологии, диаграмма деятельности UML, диаграмма активности UML Actvity Diagram, диаграмма классов UML Class Diagram, осмотр врача невролога, неврологический осмотр пациента, осмотр невропатолога.

Введение

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

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

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

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

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

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

• описать и применить методологию внедрения ИС при помощи методологии Agile Scrum;
• идентифицировать требования, предъявляемые к приложению;
• спроектировать процессы, данные и программы;
• разработать приложение в среде MS Access;
• провести тестирование.

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

Раздел 1. Описание модели внедрения программных продуктов Agile Scrum

1.1. Гибкая методология разработки Agile

Разработка программного обеспечения – это труд, который требует своевременного принятия правильных решений. Но все принимаемые решения нужно как-то «упорядочить». Сегодня одним из ценных качеств руководителя при построении современного бизнес-процесса считается умение управлять командами, работающими над проектом в целом и над отдельными продуктами. Для этого требуется особый гибкий подход, доверие коллегам и готовность к изменениям рынка. Принципы гибкого управления включены в концепцию Srum и Agile, разработанную компаниями, занятыми в сфере IT.

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

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

1.2. Методология Scrum

К отдельному Agile-подходу относится Scrum – «подход структуры».  То есть это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени циклы, называемые спринтами (Sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость. В основе методологии Scrum лежит простая идея. Когда бы ни был запущен проект, вам ничто не мешает регулярно проверять ход работ и последовательно выяснять: справляетесь ли вы с заданием; в нужном ли направлении движетесь; создаете ли именно то, что на самом деле хочет получить заказчик. Вам также ничто не мешает постоянно поднимать следующие вопросы: есть ли способы усовершенствовать методы разработки и выполнять работу наиболее качественно и быстро; существуют ли факторы, препятствующие вашим задачам [1].

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

• первым делом надо выбрать «Владельца продукта» (Product owner) – человека, способного видеть то, что вы собираетесь создать или достигнуть.  Он является связующим звеном между командой разработки и заказчиком. Его задачей является максимальное увеличение ценности разрабатываемого продукта и работы команды;
• затем нужно собрать «Команду разработки» (Development team), в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь. А также следует иметь такие качества и характеристики, как самоорганизация и многофункциональность;
• далее необходимо выбрать «Скрам-мастера» (Scrum master) - того, кто будет следить за ходом реализации проекта и помогать команде устранять препятствия на пути достижения цели;
• приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели, упорядоченный по их степени важности, подлежащих реализации. Пункты этого списка должны быть расставлены по приоритету. Список носит название «Бэклог продукта» (Product Backlog). Он может развиваться и изменяться на протяжении всего срока реализации проекта;
• участники команды должны оценить по своей системе оценок каждый пункт на предмет сложности и затрат, которые потребуются для его выполнения. Затем участники, скрам-мастер и владелец продукта должны провести первое скрам-собрание, на котором они запланируют спринт - определенное время для выполнения части заданий. Продолжительность его не должна превышать один месяц. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Бывает такое, что приходится останавливать спринт, но это происходит в исключительных ситуациях. Спринт может быть остановлен до того, как закончатся отведенные дни, или его может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить владелец продукта, если необходимость в достижении цели спринта исчезла;
• команда должна всё время стремиться к тому, чтобы превзойти в новом спринте свои собственные результаты за предыдущий спринт;
• по завершении спринта команда делает его обзор - проводит встречу, на которой участники рассказывают, что сделано за спринт;
• после показа результатов работы за спринт участники проводят ретроспективное собрание, на котором обсуждают, что команда делала хорошо, что можно сделать лучше, что можно улучшить прямо сейчас.

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

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

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

• быстрый запуск;
• быстрое реагирование на изменения - гибкость и адаптивность;
• связь в реальном времени между командой и клиентом,

а также минусы:

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

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

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

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

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

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

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

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

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

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

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

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

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

• Must have this – это обязательно должно быть. «Must» требования не подлежат обсуждению и в любом случае должны быть реализованы. Если они не поставлены пользователю в ближайших релизах, тогда весь проект не имеет смысла.
• Should have this if at all possible – следует сделать, если это только возможно. Данные задачи также важны для пользователя и\или заказчика, однако, сроки их поставки не так критичны, как для «Must». В эту категорию входят требования, которые критичны для функционала, но не для текущего релиза. 
• Could have this if it does not affect anything else – можно сделать, если это не повлияет на что-то другое. Эта категория требований, которую желательно включить, но она не влияет на релиз успеха.
• Will not have this time but would like in the future – сейчас на это нет времени, но хотелось бы сделать в будущем. Для этой категории ключевым моментом является то, что данные требования могут быть также важны (также, как и «Must»), однако, их можно оставить для более поздних поставок продукта. 

Используя этот метод, можно определить приоритеты:

• Must have this – требование 1. Поскольку именно это требование является основой ко всему ПО.
• Should have this if at all possible – требования 5-6. Это те требования, позволяющие производить непосредственно работу врача.
• Could have this if it does not affect anything else – требования 2-4. В MS Office Access можно создать формы, которые позволяют просматривать данные. Это выглядит удобнее и приятнее, но просмотреть данные можно и просто в таблицах, открыв окно редактирования.
• Will not have this time but would like in the future – требование 8. Это требование можно оставить на потом.

Следующим шагом выявим функциональные требования (определяют функциональность (поведение) программной системы, чтобы выполнить пользовательские требования):

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

2.2. Бэклог продукта

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

Таблица 2.1. Бэклог продукта

 2.3. Задание циклов разработки согласно Agile Scrum

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

• Начало:
  • анализ требований;
  • моделирование ключевого бизнес-процесса с помощью нотации UML AD.
• Первый спринт:
  • хранение информации о пациентах, их лечении, о диагнозах, симптомах, о посещениях врача, о типах обследования, о препаратах. Для этого создадим нужные таблицы в определенной среде разработки;
  • тестирование реализованных возможностей программы;
  • демонстрация прототипа программы заказчику.
• Второй спринт:
  • возможность просмотра личных данных пациента, то есть ведение определенной таблицы (или таблиц), содержащей информацию об общем осмотре, о типах обследования; возможность изменения внесения информации; 
  • тестирование реализованных возможностей программы;
  • демонстрация прототипа программы заказчику.
• Третий спринт:
  • возможность поиска данных определенной информации о пациенте и возможность печати информации на бумажный носитель;
  • тестирование реализованных возможностей программы;
  • демонстрация прототипа программы заказчику.
• Четвертый спринт:
  • создание простого и легкого интерфейса; защита от несанкционированного входа;
  • исправление ошибок;
  • тестирование реализованных возможностей программы;
  • демонстрация прототипа программы заказчику.

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

Главным принципом развития любого дела является управление, построенное на бизнес – процессах. При процессном управлении ключевые показатели эффективности кардинально улучшаются [2]. Бизнес-процесс – это устойчивая целенаправленная последовательность исполнения функций, направленная на создание результата, имеющего ценность для потребителя [3].

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

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

Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ. Эта модель от предыдущей будет отличаться не кардинально, а только в небольшой своей части, то есть в каких-то нюансах. Модель ТО-ВЕ нужна для оценки последствий внедрения информационной системы и анализа альтернативных путей выполнения работы и документирования того, как система будет функционировать в будущем. По итогу прототип и потом конечный вариант информационной системы строится только на основе разработанной модели TO BE.

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

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

На схеме бизнес-процесса узлы процесса можно изображать различными образами. Способ изображения узлов и переходов важен, так как от этого зависит легкость или сложность понимания бизнес-процесса людьми. Согласованные наборы графических элементов, из которых строятся схемы бизнес-процессов, называются графическими нотациями изображения бизнес-процессов. В данной работе был выбран UML (Universal Modelling Language) – универсальный язык моделирования графического описания, предназначенный для объектного моделирования в области разработки программного обеспечения.

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

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

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

3.2. Проектирование процессов в модели AS-IS с помощью UML AD

На рис.3.1 рассматривается первый уровень проектирования процесса работы врача-невролога в аннотации UML AD модели «AS-IS», которая подразумевает под собой проектирование процессов в настоящий момент времени. На данном этапе проектирования описываются основной и вспомогательный бизнес-процессы врача-невролога. 

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

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

В модели TO-BE, если сравнить рис.3.2 и рис.3.3, можно заметить, что вместо медицинской карты на бумажном носителе, направлений и справок, можно использовать электронную базу данных. В неё каждый сотрудник может вносить нужную информацию о пациенте: личную информацию, жалобы на состояние здоровья, результаты осмотра врачом. 

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

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

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

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

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

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

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

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

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

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

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

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

4.2. Прототип программы (второй спринт)

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

Рис. 4.3. Форма «Общий осмотр» с возможностью выбора для изменения данных 

4.3. Прототип программы (третий спринт)

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

Рис. 4.4. Окно поиска посещений конкретного пациента

Рис. 4.5. Таблица с выданным запросом по поиску посещений на пациентку Ильченко

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

Рис. 4.6. Отчёт «Личные данные пациентов»

4.4. Конечная программа (четвертый спринт)

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

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

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

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

Рис. 4.8. Форма для добавления нового пациента

Рис. 4.9. Таблица «Лечение пациентов» с возможностью выбора изменения данных и кнопками навигации

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

Рис. 4.10. Всплывающее окно при открытии базы данных

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

Тестирование является неотъемлемой частью разработки приложений. Это проверка соответствия между реальным и ожидаемым поведением программы, которая осуществляется на конечном наборе тестов, выбранном определённым образом. В данной работе при проектировании программного обеспечения была выбрана методология Agile Scrum, именно по этой причине невозможно не упомянуть об Agile-тестировании. Как было сказано в начале данной работы, Agile – гибкая методология, требующая командной работы со всеми участниками проекта. В этой методике каждый член команды несёт ответственность в соответствии со своей ролью и работой, также на протяжении всей разработки необходимы требования клиента и, самое главное, гибкий подход позволяет вносить изменения почти на любом этапе проектирования. Это значит, что в Agile Scrum тестировать необходимо в каждом итерации, что и было сделано в течение всей работы: тестирование проводилось в каждом спринте.

5.1. Функциональное тестирование

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

Таблица 5.1. Функциональное тестирование

Функциональное требование	Программный компонент	Графическое представление
База данных, содержащая таблицы «Личные данные пациентов», «Лечение пациентов», «Посещения», «Общий осмотр»	Разрабатываемое ПО
Вывод на экран данные из таблицы «Личные данные пациентов»	Программа по выводу данных на экран о личных данных пациента
Вывод на экран данные из таблицы «Лечение пациента»	Программа по выводу данных на экран о лечении пациента
Вывод на экран данные из таблицы «Общий осмотр»	Программа по выводу на экран данных из таблицы «Общий осмотр»
Вывод на экран данные из таблицы «Посещения»	Программа по выводу данных на экран о посещениях пациентов
Добавление данных о новом пациенте	Программа по вводу данных о новом пациенте
Редактирование данных о пациенте в таблице «Общий осмотр»	Средство для изменения информации
Редактирование данных о пациенте в таблице «Личные данные пациентов»	Средство для изменения информации
Редактирование данных о пациенте в таблице «Лечение пациента»	Средство для изменения информации
Поиск конкретного пациента из таблицы «Посещения»	Программа по выводу на экран запрашиваемых данных
Поиск конкретного пациента по ФИО	Программа по выводу на экран запрашиваемых данных
Печать отчёта, содержащего личные данные пациента, общий осмотр и посещения программа должна корректно работать на всех компьютерах медучреждения	Средство для вывода информации
Данные хранятся непосредственно в создаваемом приложении	Разрабатываемое ПО
Установление пароля на саму базу данных	Разрабатываемое ПО

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

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

Любое программное обеспечение должно работать под нагрузкой длительное время. Сбои и отказы системы могут привести к убыткам, потере клиентов и другим неприятным последствиям. Нагрузочное тестирование позволяет определить, как и с какой скоростью работает программа под определенной нагрузкой. Посредством нагрузочного тестирования оценивается соответствие производительности продукта требованиям, сформулированным в задании. Для тестирования было выбрано следующее количество записей: 1, 10 и 100 (примерное количество пациентов за месяц). Данные по нагрузочному тестированию приведены в табл.5.2. На основе полученных результатов можно сказать, что нагрузочное тестирование прошло успешно.

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

Заключение

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

Целью данной работы являлось создание автоматизированного рабочего места для врача-невролога. Необходимо было оптимизировать рабочий процесс с целью экономии времени сотрудника. Таким образом, в рамках данной работы была изучена и применена одна из самых популярных методологий гибкой разработки Scrum. В следующим пункте создания приложения были составлены модели AS-IS ключевого бизнес-процесса с помощью нотации UML Activity Diagram. Далее для реализации ПО были идентифицированы способы анализа требований и выявлены пользовательские и функциональные требования, а также создана матрица отслеживания требований. Еще в этой таблице был выявлен приоритет с помощью метода «MuSCoW». После этого был составлен план создания программного обеспечения, согласно методологии SCRUM. Всего получилось 4 спринта. 

Разработка приложения производилась в среде создания и обработки баз данных MS Access. Эта программа является простой и понятной в обращении; имеет возможность внесение данных из программы Microsoft Excel, в которой ранее велась часть баз данных; является полностью совместимой с системой Windows и обладает огромными возможностями по импорту и экспорту данных. По итогу были в MS Access были реализованы требования, выявлены недочеты и исправлены ошибки.

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

1. Джефф Сазерленд. Scrum. Революционный метод управления проектами Scrum. The art of doing twice the work in half the time. – Манн, Иванов и Фербер, 2016. – 288 с. 
2. Орел А.А., Ромакина О.М. Учебное пособие по курсу «Проектирование бизнес – процессов» для студентов механико-математического факультета, 2007. – 123 с.
3. А.В. Варзунов, Е.К. Торосян, Л.П. Сажнева. Анализ и управление бизнес-процессами .Учебное пособие, 2010 – 212 с.
4. Скоромец А.А., Скоромец А.П., Скоромец Т.А., Неврологический статус и его интерпретация.  Оформление, оригинал-макет. Издательство «МЕДпресс-информ», 2009. – 439 с.
5. Г.Н. Жданов. Схема истории болезни неврологического больного, 2008. – 128 с.
6. Лайза Криспин, Джанет Грегори. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд Agile Testing: A Practical Guide for Testers and Agile Teams. –  М.: «Вильямс», 2010. –  464 с.
7. Назаренко Г. И., Гулиев Я. И., Ермаков Д. Е. Медицинские информационные системы: теория и практика. – М.: Физматлит, 2005. – 320 с.
8. Шеер А.В. Моделирование бизнес-процессов. – М.: Весть-МетаТехнология, 2000. – 224 c.
9. Буч Г, Рамбо Дж. Введение в UML от создателей языка. – 2015. – 493 c.
10. Карл И. Вигерс. Разработка требований к программному обеспечению. –  М.: Русская редакция, 2005. – 576 c.
11. Соммервилл И. Инженерия программного обеспечения. 2005. –   624 с.
12. Вендеров А.М. CASE технологии. Современные методы и средства проектирования информационных систем М.: Финансы и статистика, 2005. – 352 c.
13. Ульман, Дж. Основы систем баз данных / Дж. Ульман. – М.: Финансы и статистика, 2017. - 292 c.
14.  Дейт К.Дж. Введение в системы баз данных / пер. с англ. и ред. Птицына К.А. – М.: Вильямс – 2016. – 1327 с.
15. Королюк И.П. Медицинская информатика – Самара: Офорт, 2012. – 244 с.
16. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: уровень приложений / МИРЭА. - М., 2017.
17. Епанешников А.М., Епанешников В.А. Практика создания приложений в Access. – 2009. – 440 с.
18. Бекаревич Ю., Пушкина Н. Самоучитель MS Office Access 2016. – 464 с.
19. Варзунов А. В., Торосян Е. К., Сажнева Л. П., Анализ и управление бизнес- процессами // Учебное пособие. – СПб: Университет ИТМО, 2016. – 112 с.
20. Федоров И.Г. Системный подход к выявлению бизнес-процессов методом «сверху вниз» // Прикладная информатика. — 2012. №5 (41), – C.5-13.
21. Криницкий, Н.А. Автоматизированные информационные системы / Н.А. Криницкий, Г.А. Миронов, Г.Д. Фролов. – М.: Наука, 2016. – 382 c.
22. Хаббард, Дж. Автоматизированное проектирование баз данных / Дж. Хаббард. – М.: Мир, 2014. – 296 c.
23. Малюк А.А. Введение в защиту информации в автоматизированных системах. Учебное пособие – М.: Горячая линия – Телеком, 2012. - 148 c.
24. Ларман Крэг. Применение UML и шаблонов проектирования. – М.: Вильямс, 2015. – 624 c.
25. Мюллер, Р.Дж. Базы данных и UML. Проектирование / Р.Дж. Мюллер. – М.: ЛОРИ, 2017. – 420 c.
26. Базы данных (MS Access, MySQL) / А.А. Аббакумов, В.Л. Акимов, А.И. Егунова, К.А. Лещанкин, В.М. Таланов. – Саранск: СВМО. – 2011. – 112 с.
27. Кузин, А.В. Базы данных: учеб. пособие для студ. высш. учеб. заведений / А.В. Кузин, С.В. Левонисова. – 2-е изд., стер. – М.: Академия. – 2008. – 320 с.
28. Гурвиц Г.А. Microsoft Access 2010. Разработка приложений на реальном примере. – СПб.: БХВ-Петербург, 2010. – 497 с.
29. Интернет-портал по MS Access (https://accesshelp.ru/).
30. Интернет-портал  по неврологии (http://www.neuroplus.ru/).

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

Деревнина А.М. Разработка автоматизированного рабочего места врача-невролога с использованием метода Agile Scrum / МИРЭА. - М., 2018. - 44 с. – URL: http://stepanovd.com/training/20-vkr/66-vkrb-2018-3-derevnina.