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

Подробности

Опубликовано: 12.01.2021 10:24

Автор: Худяков Сергей Дмитриевич

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

Аннотация: в статье описывается реализация приложения для стоматологии, обеспечивающее электронное хранение информации пациентов и данных, связанных с их лечением. Проводится автоматизация процесса поиска информации о состоянии пациента и совершённых процедурах над конкретными зубами пациента, что позволяет упростить работу врача-стоматолога, сократив время и количество действий.
Скачать: PDF (статья), PDF (выпуск №13).
Ключевые слова: АРМ врача стоматолога, автоматизация стоматологии, спиралевидная модель разработки ПО, автоматизация процессов стоматологии, цикличная модели разработки ПО, спиралевидная модель жизненного цикла ПО, модели жизненного цикла программного обеспечения, спринт разработки, беклог требований к программному обеспечению, беклог продукта.

1. Введение

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

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

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

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

2. Спиралевидная модель внедрения информационных систем

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

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

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

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

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

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

Рис. 1. Схема спиралевидная модели внедрения программного продукта

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

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

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

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

Создание прототипа минимизирует затраты средств и времени, а также позволяет нагляднее понять требования к продукту на этапе разработки. В последующем ведется реализация и написание программного кода продукта, в том числе пользовательского интерфейса. На первой итерации создаётся концепция продукта (Proof Of Concept) [4], необходимая для первоначальной оценки заказчиком, после чего на дальнейших витках спирали создаются готовые версии программы, которые демонстрируют ход работы над проектом, уточняют требования и описывают необходимые исправления на пути к готовому решению. По завершении создания производится тестирование продукта и исправление сопутствующих ошибок.

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

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

Таблица 2.1. Предварительное содержание витков спирали 

3. Идентификация требований и формирование бэклога

Пользовательские требования преимущественно описывают желаемый результат, но никак не учитывают технический аспект осуществления проекта [5]. Требования заказчика к продукту фиксируется исходя из результатов интервью. Для корректности и точности собранной информации необходимо:

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

В процессе выполнения проекта стейкхолдарами выступили директор стоматологии и старшая медсестра. Посредством интервьюирования были получены пользовательские требования, приведенные в табл. 3.1. Идентифицированные требования подвергались процедуре приоритизации с целью выявление первостепенных задач, с последующим определением номера витка спирали для их выполнения. Часто используемыми методами приоритизации на данный момент являются: Кано, MoSCoW, QFD, User Story Mapping и Lean Prioritization [6]. Наиболее наглядным видится метод MoSCoW, суть которого заключается в присваивание к каждому требованию одной из четырёх категорий важности:

• наиболее важное и срочное (Must);
• важное (Should);
• может быть отложено на некоторое время (Could);
• не является приоритетным вообще (Would). 

Совокупность требований и их приоритетов даны в табл. 3.1.

Таблица 3.1. Бэклог требований и их приоритетов 

Для реализации проекта с использованием спиралевидной модели необходимо распределить требования по виткам спирали в соответствии с их важностью. Последовательность шагов реализации приложения принимает вид:

• предварительные действия:
  • проработка предметной области;
  • опрос стейкхолдеров и фиксация требований (таблица 3.1);
  • моделирование бизнес-модели с использованием нотаций ARIS VACD и eEPC;
  • проектирование таблиц баз данных и схемы приложения;
• 1-й виток спирали:
  • проектирование решения для требований 1-6 из таблицы 3.1;
  • оценка возможных рисков и их влияния;
  • разработка требований и проведение модульного испытания;
  • предоставление заказчику разработанной части программы;
• содержание 2-го витка спирали аналогично 1-му, за исключением требований: анализируются результаты предыдущей итерации разработки и реализуется требование 7 из табл. 3.1;
• 3-й виток спирали, его содержание аналогично 2-му витку, однако разрабатывается требование 8 из табл. 3.1;
• содержание 3-го витка аналогично 2-му: реализуются требования 9-11 из табл. 3.1. Ссылка на 2-ю часть статьи. 

Литература 

1. Программы для стоматологий – URL: http://www.livemedical.ru/tools/dental/ (дата обращения 12.12.2018).
2. Карпович Е.Е. Жизненный цикл программного обеспечения – М.: Центр дистанционного обучения. НИТУ «МИСиС», 2016. – 131 с.
3. Кумагина Е.А., Неймарк Е.А. Модели жизненного цикла и технологии проектирования программного обеспечения: учебно-методическое пособие – Нижний Новгород: Изд-во ННГУ, 2016. – 41 с.
4. Гурендо Д. Жизненный цикл разработки ПО – URL: https://xbsoftware.ru/blog/zhiznennyj-tsykl-razrabotki-spiral/ (дата обращения 12.12.2018).
5. Требования. Анализ требований, виды требований – URL: https://intellect.ml/trebovaniya-analiz-trebovanij-vidy-trebovanij-5188 (дата обращения 12.12.2018).
6. Методы приоритизации – URL: https://habr.com/company/hygger/blog/359208/ (дата обращения 12.12.2018).
7. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: теория и практика // Российский технологический журнал. – 2015. – т.8, №3. – c.227-238.
8. Разработка управленческих решений / Ю.Г. Учитель, А.И. Терновой, К.И. Терновой. – 2-е изд., перераб. и доп. – М., 2007. – 383 с.
9. Виды тестирования программного обеспечения – URL: http://www.protesting.ru/testing/testtypes.html (дата обращения 12.12.2018).
10. Куликов С. C. Тестирование программного обеспечения. Базовый курс. – Минск: Четыре четверти, 2017. – 312 с.

Выходные данные статьи

Худяков С.Д. Автоматизация работы стоматологической клиники с использованием спиралевидной модели внедрения информационных систем (часть 1) // Корпоративные информационные системы. – 2021. – №1 (13) – С. 1-10. – URL: https://corpinfosys.ru/archive/issue-13/93-2021-13-dentalautomation.

Об авторе

Худяков Сергей Дмитриевич – студент 4-го курса кафедры оптических и биотехнических систем и технологий физико-технологического института РТУ МИРЭА. Тема выпускной квалификационной работы бакалавра «Автоматизация ключевых бизнес-процессов стоматологической клиники с использованием спиралевидной модели внедрения». Электронная почта: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра..

Статьи выпуска №13

1. Автоматизация работы стоматологической клиники (часть 1);
2. Применение спиралевидной модели внедрения для роботизации больницы;
3. Банкротство юридического лица. Ликвидационный баланс (часть 1);
4. Автоматизация городской больницы (часть 2);
5. Подготовка функциональных спецификаций на примере ABAP-отчета в SAP ERP.