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

Корпоративные информационные системы и учетная политика организации при применении автоматизированной формы ведения учета

Аннотация: в статье рассмотрены и исследованы каскадная, итерационная и спиральная модели внедрения информационных систем. Для каждой модели выбрана соответствующая методология (ASAP – для каскадной, Scrum – для итерационной, и RAD – для спиралевидной) и расписаны основные шаги при проведении разработки. Опираясь на изученные данные, проведено описание ключевых бизнес-процессов городской больницы в модели «AS-IS» и составлена карта процессов. Также собран перечень пользовательских и законодательных требований к разрабатываемой системе.
СкачатьPDF (статья), PDF (выпуск №12).
Ключевые слова: методология ASAP, accelerated SAP, Rapid Application Development, опытно-промышленная эксплуатация, конкретизация процессов, декомпозиция бизнес-процессов, лечение пациента, программа Denwer, регистрация пациента, выполнение спринта, бэклог спринта, описание процесса, пользовательские интерфейсы, форма регистрации.

Введение

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

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

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

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

Изучению вопросов автоматизации ИС посвящены труды Маглинец Ю.А. [1, 2]. В них рассматриваются различные понятия, относящиеся с ИС, требования к этим системам и всевозможные стандарты. Моделирование бизнес-процессов описывает руководитель компании IDS Scheer – производителя системы ARIS, А.В. Шеер [3, 4]. Подобные задачи решались в выпускных квалификационных работах (ВКР) Орешкиной А.М. [5], Катасоновой Н.С. [6]. Применение автоматизации бизнес-процессов в сфере телекоммуникационных систем рассматривается в книге Самуйлова К.Е. [7], в бизнесе – в книге Старовойтовой Т. Ф. [8], в строительстве – в книге Теличенко В. И. [9]. Суммируя все вышесказанное можно с уверенностью заявить, что разработка данной системы будет весьма актуальной и поможет объединить и улучшить предыдущие достижения в этой области.

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

Цель и задачи

Целью данной работы состоит в разработке программного обеспечения средствами PHP для автоматизации ключевых бизнес-процессов городской больницы на основе каскадной, итерационной и спиралевидной модели внедрения информационных систем. При разработке будет использована система управления базами данных (СУБД) MySQL, и для программной реализации – HTML и PHP. В процессе реализации необходимо воплотить в жизнь следующие задачи:

  • описать различия моделей внедрения ИС; 
  • провести проектирование бизнес-процессов до 3 уровня описания при помощи нотаций ARIS VACD и ARIS eEPC в моделях AS-IS и TO-BE;
  • спроектировать архитектуру данных, структуру приложений с помощью MS Visio;
  • реализовать ключевые бизнес-процессы с применением PHP по выбранным методологиям;
  • провести нагрузочное тестирование;
  • сравнить методологии внедрения ИС.

1. Сравнение методологий внедрения информационных систем

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

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

Таблица 1.1. Сравнение моделей внедрения ИС

Характеристика

проекта

 

Модель (стратегия)

Каскадная Итерационная Спиральная
Новизна разработки и обеспеченность ресурсами Типовой. Хорошо проработаны технология и методы решения задачи Нетиповой (новаторский). Нетрадиционный для разработчика
Ресурсов заказчика и разработчика хватает для реализации проекта в длительные сроки Ресурсов заказчика или разработчика не хватает для реализации проекта в сжатые сроки
Масштаб проекта Средние и крупные проекты Малые и средние проекты Любые проекты
Сроки выполнения проекта До нескольких лет. Разработка одной версии может занимать срок от нескольких недель до года
Заключение отдельных договоров на отдельные версии Заключается один договор. Версия и есть итоговый результат проекта Заключение отдельных договоров на отдельные версии Заключается один договор. Версия и есть итоговый результат проекта
Определение основных требований в начале проекта Да Определение основных требований в начале проекта Да
Изменение требований по мере развития проекта Нет Изменение требований по мере развития проекта Нет
Разработка итерациями (версиями) Нет Разработка итерациями (версиями) Нет
Распространение промежуточного ПО Нет Распространение промежуточного ПО Нет

Рассмотрим три наиболее популярных прикладных метода, расширяющих классические модели внедрения информационных систем, к ним относятся: ASAP, Agile Scrum и Rapid Application Development.

На сегодняшний день немецкая компания SAP AG является одним из крупнейших в мире поставщиков ИС. Многие решения SAP многофункциональны, поскольку охватывают все бизнес-процессы предприятия. В связи с этим компания разработала методологию внедрения, которая получила название Accelerated SAP, или, сокращенно, ASAP. Методология ASAP состоит из множества списков контрольных вопросов, таблиц, опросных листов, ответов, шаблонов документов, рекомендаций и т. д. Кроме того, в ASAP предусмотрены руководства, средства обучения и акселераторы по огромному диапазону технических вопросов, связанных с инфраструктурой, установкой и операциями SAP. Различные обзоры и списки контрольных вопросов, имеющиеся в распоряжении ASAP, контролируют не только ход собственно проекта, но также стабильность и интеграцию системы на всех стадиях проекта.

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

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

Идея Rapid Application Development зародилась в 1980-х годах как альтернатива устаревающей каскадной модели. Каскадная модель программирования уже тогда воспринималась как перегруженная формальностями и недостаточно гибкая. Заказчик выдавал разработчику техническое задание и не видел результата до тех пор, пока программа не «сходила с конвейера» уже готовой, а ожидания пользователя зачастую не оправдывались. Продукт мог оказаться слишком сложным, неудобным, а мог и устареть за время разработки. Методология разработки информационных систем, основанная на использовании средств быстрой разработки приложений и непрерывном анализе негативных рисков, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки приложений Rapid Application Development.

2. Идентификация и анализ требований, а так же бизнес-процессов

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

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

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

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

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

Таблица 2.1. Перечень пользовательских и законодательных требований 

Пользовательское требование

1 Возможность вывода данных о пациенте
2

Возможность просмотра информации о персонале:

  • Фамилия, Имя, Отчество специалиста;
  • занимаемая должность;
  • порядок записи к специалисту;
  • график приема специалистом;
  • данные сертификата специалиста – специальность, срок действия сертификата, соответствие занимающей должности;
  • дополнительные данные сертификата – кем выдан, когда выдан, уровень образования, квалификация
3 Возможность для заведения медицинской карты
4 Возможность для удаления медицинской карты
5 Возможность просмотра и редактирования данных из БД «Пациенты»
6 Возможность просмотра и редактирования данных из БД «Эпикриз»
7 Возможность просмотра и редактирования данных из БД «Анамнез»
8 Возможность просмотра и редактирования данных из БД «Температура»
9 Возможность просмотра и редактирования данных из БД «Назначения»
10 Возможность просмотра и редактирования данных из БД «Дневник»
11 Возможность просмотра и редактирования данных из БД «Персонал»
12 Возможность печати карты при выписке
13 Возможность поиска медицинской карты по ее номеру или фамилии пациента
14 Возможность работы на любом устройстве
15 Возможность хранения данных
16 Доступность
17 Легкость в использовании
18 Наличие базы данных для температурных листов пациентов
19 Наличие базы данных для учета лечебных назначений
20 Наличие базы данных для хранения врачебных заключений
21 Наличие базы данных для хранения данных о пациенте после его поступления
22 Наличие базы данных для хранения информации о медицинском персонале
23 Наличие базы данных для хранения медицинских карт пациентов
24 Наличие базы данных для эпикриза пациентов
25 Наличие данных об анамнезе пациента
26 Невозможность подмены пациентом данных о себе
27 Работа системы в любом месте
28 Удобный интерфейс на мобильных устройствах
29 Доступность данных
30 Конфиденциальность персональных данных
31 Осуществление медицинской деятельности и медицинских услуг
32 Дата гос. регистрации учреждения
33 Полные сведения об учредителях
34 Структура организации, как осуществляется управление
35 Контактные данные, а именно – почтовый адрес, телефон, электронный адрес, схема проезда
36 Полное наименование предприятия 
37 Информация о подразделениях, филиалах, корпусах
38 Режим работы учреждения
39 Правила внутреннего распорядка
40 Лицензии организации на ведение медицинской деятельности, представленные в электронном виде
41 Виды оказываемой медицинской помощи
42 Правила записи на прием, обследование, консультацию, диагностику
43 Правила подготовки к проведению диагностических манипуляций
44 Правила диспансеризации и госпитализации
45 Стоимость оказываемых медицинских услуг, с приложением утвержденного документа с ценами в электронном виде
46 Графики приема врачей, контактные данные специалистов или организации – электронная почта, телефон
47 Информация об органах охраны здоровья, надзору в сфере здравоохранения, надзору защиты прав потребителей (почтовый адрес, телефоны, электронный адрес)
48 Информация об страховых учреждениях, с которыми заключены договора на оказание и оплату мед. услуг по ОМС
49 Обязательно должна быть размещена информация о возможности проведения независимой оценки качества оказываемых услуг
50 Карта сайта для работы с ресурсом и удобной навигации
51 Версия сайта для слабовидящих людей
52 Иные инструменты, обеспечивающие удобную работу с ресурсом пользователя
53 Язык сайта (меню, карта сайта, информация на сайте) обязательно должен быть русским

2.2. Ключевой бизнес-процесс в модели «AS-IS»

Модель «AS-IS» («как есть») делает возможным отображение настоящего положения дел, классифицирование происходящих в учреждении процессов и потоков информации в их пределах. С помощью этой модели определяются проблемные места при реализации и взаимодействии процессов. В ходе моделирования бизнес-процессов производится анализ их нынешнего состояния и варианты улучшения. Для определения эффективности процессов производится их разложение до простейших операций. Благодаря этому возможно нахождение частей процессов, препятствующих их плодотворному осуществлению:

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

Конкретизация процессов в модели «AS-IS» дает возможность обнаружить недочеты в проверяемой сфере деятельности, учитываемые при разработке модели «TO-BE» («как должно быть»), т.е. модели улучшенной организации процессов [13].

Обнаруженные в модели «AS-IS» недочеты устраняются в модели «ТО-ВЕ». Производство и ввод в эксплуатацию ИС позволяет изменить условия осуществления единичных операций, устройство процессов и компании в целом. Это служит источником потребности в преобразование системы норм на предприятии, изменения служебных правил работников.

Функциональная модель «TO-BE» дает возможность на ранних этапах выявить преобразования в системе. Ее применение делает возможным не только сжатие сроков внедрения ИС, но и понижение рисков, взаимосвязанных с невосприимчивостью сотрудников к высоким технологиям. Она необходима для исследования иных способов реализации и создания документации будущей деятельности фирмы. 

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

2.3. Описание ключевого бизнес-процесса

На рисунке 2.1 представлен верхний (0-й) уровень описания ключевых бизнес-процессов городской больницы.

Верхний уровень описания ключевых бизнес-процессов

Рис. 2.1. Верхний уровень описания ключевых бизнес-процессов

При рассмотрении первого уровня описания бизнес-процессов (рисунок 2.2) возможно проанализировать документацию и ответственных за 3 ключевых бизнес-процессах: «Принять пациента», «Лечить пациента» и «Выписать пациента» [14]. Для более точного понимания текущей ситуации в городской больнице необходимо углубиться в рассмотрение бизнес-процесса «Лечить пациента» на 2-м (рисунки 2.3-2.4) и 3-м уровнях описания процессов (рисунки 2.5-2.6).

Первый уровень описания процессов ARIS VACD в модели «AS-IS»

 Рис. 2.2. Первый уровень описания процессов ARIS VACD в модели «AS-IS»

Процесс «Лечить пациента» в модели ARIS eEPC «AS-IS» ч. 1 (2 уровень)

Рис. 2.3. Процесс «Лечить пациента» в модели ARIS eEPC «AS-IS» ч. 1 (2 уровень)

Процесс «Лечить пациента» в модели ARIS eEPC «AS-IS» ч. 2 (2 уровень)

Рис. 2.4. Процесс «Лечить пациента» в модели ARIS eEPC «AS-IS» ч. 2 (2 уровень)

Процесс «Лечить пациента» в модели ARIS eEPC «AS-IS» ч. 1 (3 уровень)

Рис. 2.5. Процесс «Лечить пациента» в модели ARIS eEPC «AS-IS» ч. 1 (3 уровень)

Процесс «Лечить пациента» в модели ARIS eEPC «AS-IS» ч. 2 (3 уровень)

Рис. 2.6. Процесс «Лечить пациента» в модели ARIS eEPC «AS-IS» ч. 2 (3 уровень) 

После декомпозиции бизнес-процессов до 3-го уровня можно составить карту процесса, данную на рисунке 2.7.

Карта бизнес-процессов в модели «AS-IS»

 Рис. 2.7. Карта бизнес-процессов в модели «AS-IS» 

3. Реализация ключевого бизнес-процесса «Лечить пациента» на основе каскадной модели внедрения, используя методологию ASAP

Используя методологию ASAP и описания ключевого бизнес-процесса продолжается составление концептуального проекта. Для этого реализуемые требования заносятся в матрицу отслеживания требований разрабатываемого решения, что позволит автоматизировать ключевые бизнес-процессы городской больницы (таблица 3.1). 

Таблица 3.1. Матрица отслеживания требований  

Пользовательское требование

Компонент покрытия

1 Доступность данных Веб-сайт – Главная страница
2 Возможность для заведения медицинской карты Форма регистрации пациента
3 Возможность хранения данных База данных MySQL
4 Наличие таблицы для температурных листов пациентов Таблица «Температурный лист» в БД
5 Наличие таблицы для учета лечебных назначений Таблица «Лечебные назначения» в БД
6 Наличие базы данных для хранения врачебных заключений Таблица «Врачебные заключения» в БД
7 Наличие базы данных для эпикриза пациентов Таблица «Эпикриз» в БД
8 Осуществление медицинской деятельности и медицинских услуг Веб-сайт – Страница «О нас»
9 Дата гос. регистрации учреждения Веб-сайт – Страница «О нас»
10 Полные сведения об учредителях Веб-сайт – Страница «О нас»
11 Структура организации, как осуществляется управление Веб-сайт – Страница «О нас»
12 Контактные данные, а именно – почтовый адрес, телефон, электронный адрес, схема проезда Веб-сайт – Страница «Контакты»
13 Полное наименование предприятия Веб-сайт – Страница «Сведения»
14 Информация о подразделениях, филиалах, корпусах Веб-сайт – Страница «Контакты»
15 Режим работы учреждения Веб-сайт – Страница «Контакты»
16 Правила внутреннего распорядка Веб-сайт – Страница «Сведения»
17 Лицензии организации на ведение медицинской деятельности, представленные в электронном виде Веб-сайт – Страница «Сведения»
18 Виды оказываемой медицинской помощи Веб-сайт – Страница «Сведения»
19 Правила записи на прием, обследование, консультацию, диагностику Веб-сайт – Страница «Сведения»

На основе назначения данных, приведённых выше, всю информацию можно разбить на классы, приведённые в таблице 3.2. После разделения всех данных на классы и их нормализации до 3НФ, получаем архитектуру данных разрабатываемой системы, продемонстрированную на рисунке 3.1.

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

Класс данных

Поле

Тип данных

Количество символов

Эпикриз 🔑Номер записи Счетчик 10
Номер карты Числовой 10
Код сотрудника Числовой 10
Эпикриз Текст 1000
Врачебные заключения 🔑Номер записи Счетчик 10
Номер карты Числовой 10
Код сотрудника Числовой 10
Заключение Текст 1000
Лечебные назначения 🔑Номер записи Счетчик 10
Номер карты Числовой 10
Код сотрудника Числовой 10
Назначение Текст 1000
Температурный лист 🔑Номер записи Счетчик 10
Номер карты Числовой 10
Код сотрудника Числовой 10
Дата Дата 8
Время Время 6
Дыхание Числовой 10
Температура Числовой 10

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

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

Для удобства использования системы как пациентами, так и медицинским персоналом необходимо разработать доступный для понимания новыми пользователями интерфейс. Для этого воспользуемся программой MS Visio. С ее помощью формируем общее понимание проектируемой системы, для чего составлена схема взаимодействия пользовательских интерфейсов (рисунок 3.2). Важно отметить, что на ней обозначены элементы (1 и 2), которые будут добавлены на более поздних этапах разработки, а также не добавлены таблицы из БД по причине временного отсутствия связи их с сайтом.

Схема взаимодействия пользовательских экранов

 Рис. 3.2. Схема взаимодействия пользовательских экранов

Для описания того, каким должен быть ключевой бизнес-процесс «Лечить пациента» в будущем на 2-м и 3-м уровнях декомпозиции, воспользуемся моделью «TO-BE» в ARIS eEPC (рисунки 3.3 – 3.5).

Процесс «Лечить пациента» в модели ARIS eEPC «TO-BE» ч.1 (2 уровень)

 Рис. 3.3. Процесс «Лечить пациента» в модели ARIS eEPC «TO-BE» ч.1 (2 уровень)

Процесс «Лечить пациента» в модели ARIS eEPC «TO-BE» ч.2 (2 уровень)

 Рис. 3.4. Процесс «Лечить пациента» в модели ARIS eEPC «TO-BE» ч.2 (2 уровень)

Процесс «Лечить пациента» в модели ARIS eEPC «TO-BE» (3 уровень)

Рис. 3.5. Процесс «Лечить пациента» в модели ARIS eEPC «TO-BE» (3 уровень)

В итоге, после описания ключевого бизнес-процесса «Лечить пациента» в модели «TO-BE» можно составить карту бизнес-процессов (рисунок 3.6).

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

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

Далее при помощи программы Denwer была создана БД в phpMyAdmin для хранения данных о пациентах и персонале городской больницы. Средствами PHP разрабатывался пользовательский интерфейс. Допустим, медсестре, зайдя на PHP-сайт, необходимо зарегистрировать нового пациента. Тогда, нажав на кнопку регистрация нового пациента, она перейдет на новую страницу, на которой будет находиться анкета-формуляр медицинской карты стационарного больного (рисунок 3.7).

Форма регистрации пациента

 Рис. 3.7. Форма регистрации пациента

Проверка качества разработанной части программного решения, было проведено нагрузочное тестирование в 5-ть этапов для 1, 10, 25, 50, 100, 250, 500, 1000, 2500 и 5000 пользователей с одновременным входом. Данные о проведенных тестах занесены в таблицу 3.3. Суть тестирования сводилась к следующему. В начале 5-ть раз проводилась проверка отклика системы на различные действия. Далее рассчитывалось среднее арифметическое всех измерений по формуле (3.1):

                                                (3.1)

после чего вычислялось средние квадратические отклонения по формуле (3.2):

                                   (3.2)

А также погрешность измерений согласно (3.3):

                                    (3.3)

где n – число измерений, tα(n-1) – доверительный коэффициент Стьюдента, равный 0.95, а А – абсолютная погрешность прибора (в данном случае – электронного секундомера JMeter, который считает данные с точностью до десятитысячной доли секунды), округленная до тысячных долей и равная 0,0005. Итоговое время отклика записывается по формуле (3.4):  

 .                                             (3.4)

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

Кол-во 
польз.

t1, c

t2, c

t3, c

t4, c

t5, c

tср.ариф
c

tср.ариф
c

Δt, с

tотк, с

1 0,035 0,07 0,07 0,042 0,028 0,049 0,0198 0,00843 0,049±0,008
10 0,028 0,014 0,014 0,014 0,007 0,0154 0,00767 0,0033 0,015±0,003
25 0,014 0,014 0,021 0,014 0,014 0,0154 0,00313 0,00142 0,015±0,001
50 0,022 0,006 0,005 0,008 0,005 0,0092 0,00726 0,00312 0,009±0,003
100 0,007 0,009 0,038 0,167 0,029 0,05 0,06672 0,02835 0,067±0,028
250 0,035 0,075 0,519 0,103 0,05 0,1564 0,20434 0,08681 0,156±0,087
500 0,079 0,028 0,041 0,055 0,406 0,1218 0,15999 0,06798 0,122±0,068
1000 1,248 1,602 1,034 1,729 2,156 1,5538 0,43571 0,18511 1,554±0,185
2500 5,127 4,913 4,033 4,854 5,036 4,7926 0,4377 0,18596 4,793±0,438
5000 10,11 8,135 8,911 8,547 8,555 8,8516 0,75521 0,32085 8,852±0,755

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

Зависимость среднеарифметического времени отклика от числа пользователей

Рис. 3.8. Зависимость среднеарифметического времени отклика от числа пользователей 

4. Реализация бизнес-процесса «Принять пациента» на основе итерационной модели, используя Agile Scrum

Разработка программного обеспечения будет производиться в последовательности, приведенной в таблице 4.1, что соответствует методологии Agile Scrum.

Таблица 4.1. Этапы разработки ПО с использованием Agile Scrum

№ действия \ Этап разработки

Начало

Первый спринт (реализация требований 8-11 бэклога)

Второй спринт (реализация требований 1-4 бэклога)

Третий спринт (реализация требований 5-7 бэклога)

1 Формирование бэклога продукта (таблица 4.2) Описание ключевого бизнес-процесса «Принять пациента» в модели «AS-IS» Описание ключевого бизнес-процесса «Принять пациента» в модели «AS-IS» Описание ключевого бизнес-процесса «Принять пациента» в модели «TO-BE» 
2   Проектирование данных Проектирование данных Проектирование данных
3   Проектирование пользовательских интерфейсов Проектирование пользовательских интерфейсов Проектирование пользовательских интерфейсов
4   Реализация процессов средствами PHP Реализация процессов средствами PHP Реализация процессов средствами PHP
5   Тестирование  Тестирование  Тестирование 
6       Оценка результатов

Для формирования бэклога продукта из таблицы 2.1 были взяты требования, относящиеся к бизнес-процессу «Принять пациента» и занесены в таблицу 4.2 с указанием приоритета (также отсортированные по нему) и номера спринта (продолжительность одного спринта равна 1-й недели), на котором требование планируется к реализации.

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

№ 

Пользовательская история

Компонент покрытия

Приоритет

№ 
спринта

1 Как врачу мне необходимо место для хранения информации обо мне, а также для авторизации Таблица «Персонал» в БД Высокий 1
2 Как врачу мне необходимо место для хранения карты пациента Таблица «Пациенты» в БД Высокий 1
3 Как врачу мне необходимо место для хранения информации об анамнезе пациента Таблица «Анамнез» в БД Средний 1
4 Как врачу мне необходимо не допустить возможность для изменения данных в карте пациента Формы регистрации и авторизации персонала Высокий 1
5 Как врачу мне необходима возможность для удаления карты пациента Форма удаления медицинской карты Средний 2
6 Как врачу мне необходимо редактировать данные из карты пациента Форма просмотра и редактирования медицинской карты Средний 2
7 Как врачу мне необходимо добавлять и редактировать эпикриз пациента Форма просмотра и редактирования медицинской карты Средний 2
8 Как врачу мне необходимо добавлять и редактировать анамнез пациента при поступлении Форма просмотра и редактирования медицинской карты Средний 2
9 Как врачу мне необходимо добавлять и редактировать данные о температуре пациента Форма просмотра и редактирования медицинской карты Средний 3
10 Как врачу мне необходимо добавлять и редактировать врачебные назначения Форма просмотра и редактирования медицинской карты Средний 3
11 Как врачу мне необходимо добавлять и изменять данные в «Дневнике» пациента Форма просмотра и редактирования медицинской карты Средний 3

4.1. Реализация 1-го спринта: требований 8-11 бэклога

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

Процесс «Принять пациента» в модели ARIS eEPC «AS-IS» ч.1 (2 уровень)

 Рис. 4.1. Процесс «Принять пациента» в модели ARIS eEPC «AS-IS» ч.1 (2 уровень)

Процесс «Принять пациента» в модели ARIS eEPC «AS-IS» ч.2 (2 уровень)

Рис. 4.2. Процесс «Принять пациента» в модели ARIS eEPC «AS-IS» ч.2 (2 уровень) 

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

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

Класс данных

Поле

Тип данных

Количество символов

Пациент 🔑Номер карты Счетчик 10
Фамилия Небольшой текст 25
Имя Небольшой текст 25
Отчество Небольшой текст 25
Пол Небольшой текст 5
Возраст Числовой 5
Постоянное место жительства (ПМЖ) Средний текст 255
Место работы, профессия или должность Средний текст 255
Сотрудник 🔑Код сотрудника Счетчик 10
Фамилия Небольшой текст 25
Имя Небольшой текст 25
Отчество Небольшой текст 25
Должность Небольшой текст 25
Порядок записи Средний текст 100
График приема Дата и время 14
Данные сертификата специалиста Средний текст 255
Дополнительные данные сертификата Средний текст 255
E-mail Средний текст 255
Пароль Средний текст 255
Анамнез 🔑Номер записи Счетчик 10
Номер карты Числовой 10
Код сотрудника Числовой 10
Анамнез пациента Текст 1000

Архитектура классов данных

  Рис. 4.3. Архитектура классов данных

Далее в среде MS Visio спроектированы формы регистрации и авторизации персонала для разделения доступа между сотрудником и пациентом. Поскольку в архитектуру данных и пользовательские интерфейсы вносятся изменения, необходимо отразить их на ранее приведенной (рисунок 3.2) схеме взаимодействия пользовательских экранов, т.е. в элементе 1 (рисунок 4.4). Кроме того, интерфейс пополнится связью между формой регистрации нового пациента и добавляемой в данном спринте таблицей. 

Дополнение к схеме взаимодействия пользовательских экранов

 Рис. 4.4. Дополнение к схеме взаимодействия пользовательских экранов

Новая таблица «Анамнез» и другие ранее созданные таблицы и их взаимодействие с веб интерфейсом будут описаны в 2-3 спринтах.

Фрагменты реализованных БД и соответствующие элементы пользовательского интерфейса представлены на рисунках 4.5-4.6. Данные в таблицы вносились через СУБД MySQL вручную.

Данные в таблице «Пациенты»<

 Рис. 4.5. Данные в таблице «Пациенты»

Форма регистрации персонала

Рис. 4.6. Форма регистрации персонала

4.2. Реализация 2-го спринта: требований 1-4 бэклога

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

Проводилось углубленное описание процесса до 3-го уровня детализации (рисунки 4.7-4.8). На основе рассмотренных за два спринта процессов можно дополнить ранее представленную на рисунке 2.6 карту процессов (рисунок 4.9).

Процесс «Оказать квалифицированную медицинскую помощь» в модели ARIS eEPC «AS-IS» ч.1 (3 уровень)

 Рис. 4.7. Процесс «Оказать квалифицированную медицинскую помощь» в модели ARIS eEPC «AS-IS» ч.1 (3 уровень)

Процесс «Оказать квалифицированную медицинскую помощь» в модели ARIS eEPC «AS-IS» ч.2 (3 уровень)

Рис. 4.8.  Процесс «Оказать квалифицированную медицинскую помощь» в модели ARIS eEPC «AS-IS» ч.2 (3 уровень) 

Карта процессов в модели «AS-IS»

Рис. 4.9.  Карта процессов в модели «AS-IS»  

На рисунке 4.10 дана схема формы просмотра и редактирования данных из таблиц с данными для карты пациента, а на рисунке 4.11 – взаимодействие реализуемых в данном спринте форм с уже созданными таблицами.

Схема взаимодействия форм редактирования с таблицами БД

 Рис. 4.10.  Схема взаимодействия форм редактирования с таблицами БД

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

Рис. 4.11.  Схема взаимодействия пользовательских экранов при поиске и удалении карты пациента  

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

Рис. 4.12.  Форма редактирования записи из таблицы 

При выполнении спринта с помощью средств PHP и HTML добавлена веб-форма запроса данных пациента и регистрации карточки (рисунок 4.12). Ссылка на 2-ю часть статьи.

Литература 

  1. Маглинец Ю.А. Анализ требований к автоматизированным информационным системам: учебное пособие – Москва: Интуит НОУ, 2016. – 192 c.
  2. Маглинец Ю.А. Разработка информационных систем. Часть 1, Структурные методы. – Красноярск: Кларитеанум, 2004. – 120 с.
  3. Шеер А.-В. Бизнес-процессы: основные понятия, теории, методы. – М.: Просветитель, 1999.
  4. Шеер А.В. Моделирование бизнес-процессов – М.: Серебряные нити, 2014. – 219 c.
  5. Орешкина А.М. Анализ, проектирование, разработка и тестирование приложения для автоматизации городской больницы: диплом бакалавра / МИРЭА. – М., 2017. – 49 с.
  6. Катасонова Н.С. Автоматизация ключевых бизнес-процессов городской больницы на основе каскадной модели внедрения / МИРЭА. – М., 2018. – 55 с. – URL: https://stepanovd.com/training/20-vkr/64-vkrb-2018-2-katasonova.
  7. Самуйлов К.Е. Бизнес-процессы и информационные технологии в управлении телекоммуникационными компаниями / К.Е. Самуйлов. – М.: Альпина Паблишер, 2014. – 220 c.
  8. Старовойтова Т. Ф. Информационные системы в бизнесе / Т.Ф. Старовойтова, А.Н. Лавренов. – М.: Академия управления при Президенте Республики Беларусь, 2015. – 150 c.
  9. Теличенко В. И. Информационное моделирование технологий и бизнес-процессов в строительстве / В.И. Теличенко, А.А. Лапидус, А.А. Морозенко. – М.: Издательство Ассоциации строительных вузов, 2017. – 144 c.
  10. Модели жизненного цикла: учеб. пособие / Д.Б. Берг, Е.А. Ульянова, П.В. Добряк. – Екатеринбург: Издательство Уральского университета, 2014. – 74 с.
  11. Шматалюк А. и др. Моделирование бизнеса. Методология ARIS. Практическое руководство. – М.: Серебряные нити, 2001.
  12. Репин В. В. Бизнес-процессы компании: построение, анализ, регламентация. – М.: Стандарты и качество, 2007.
  13. Учебное пособие по работе со средствами ARIS Express - http://library.miit.ru/methodics/29.09.17/Уч-мет.ARIS.pdf
  14. Гулиев Я.И., Белышев Д.В., Михеев А.Е. Моделирование бизнес-процессов медицинской организации: классификация процессов: научная статья – (Институт программных систем им. А.К. Айламазяна РАН, Переславль-Залесский, Россия, ГБУ «Инфогород», Москва, Россия).
  15. Гудков Е.А. Применение спиралевидной модели внедрения информационных систем в городской поликлинике / МИРЭА. – М., 2018. – 45 с. – URL: https://stepanovd.com/training/20-vkr/63-vkrb-2018-1-gudkov.

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

Катасонова Н.В. Применение каскадной, итерационной и спиралевидной моделей внедрения информационных систем для автоматизации городской больницы (часть 1) // Корпоративные информационные системы. – 2020. – №4(12). – С. 52-90. – URL: https://corpinfosys.ru/archive/issue-12/127-2020-12-hospitalautomation.

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

Об авторе

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

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

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