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

Подробности

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

Автор: Катасонова Наталья Сергеевна

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

Аннотация: в статье проведена пошаговая разработка согласно методологиям внедрения, составлен план разработки, затем оформлен перечень требований, представленных к реализации, осуществлено моделирование процессов до 3-го уровня в нотациях ARIS VACD и ARIS eEPC в модели TO-BE, и составлены соответствующие карты процессов. Проведено проектирование архитектуры данных и схемы взаимодействия пользовательских интерфейсов в среде MS Visio. На основе полученных данных проведена разработка веб-приложения с использованием языков PHP, HTML и JavaScript, а также проведено функциональное и нагрузочное тестирования.
Скачать: PDF (статья), PDF (выпуск №13).
Ключевые слова: цифровая больница будущего, SAP ASAP методология, методология внедрения accelerated SAP, методологии разработки ПО RAD, RAD-разработка, инструмент быстрой разработки приложений, методологии Agile Waterfall Scrum и Kanban, чем Waterfall отличается от Scrum, цифровая медицина в России, цифровая трансформация государственной системы, кибер-медицина, цифровая медицина будущего.

4.3. Реализация 3-го спринта: требований 5-7 бэклога

Ссылка на 1-ю часть статьи. На данном спринте необходимо было реализовать схожие с ранее созданными функции поиска и редактирования содержимого таблиц, а также создать объединяющую их выгрузку данных по конкретному пациенту. Для понимания изменений, которые вносит разрабатываемая система в структуру процессов организации, необходимо рассмотреть процессы на 2-м (рисунки 4.13-4.14) и 3-м (рисунки 4.15-4.16) уровнях детализации модели «TO-BE». На основе полученных данных обновлялась карта процессов в модели «TO-BE» (рисунок 4.17).

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

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

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

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

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

В данном спринте добавляются схожие с описанными на прошлом этапе формы просмотра и редактирование данных из таблиц БД MySQ. Однако для каждой новой формы появляется новая схема взаимодействия с соответствующей таблицей. Для этого дано дополнение к схеме взаимодействия пользовательских экранов (рисунок 4.18).

Рис. 4.18. Обновленная схема взаимодействия экранов при редактировании таблиц

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

Рис. 4.19. Форма редактирования данных из таблицы «Температурный лист»

И в завершении проведено нагрузочное тестирование, аналогичное методологии ASAP, но с добавлением в тест новых, разработанных в рамках Agile Scrum, веб-страниц. Результаты нагрузочного тестирования занесены в таблицу 4.4. Тестирование проводилось по аналогии с главой 3 по формулам 3.1-3.4.

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

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

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

5. Реализация бизнес-процесса «Выписать пациента» на основе спиралевидной модели с использованием методологии RAD

Разработка оставшейся части программного обеспечения будет производиться в последовательности, приведенной в таблице 5.1 согласно методологии Rapid Application Development [15].

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

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

Таблица 5.2. Перечень требований

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

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

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

Таблица 5.3. Таблица отслеживания качественных рисков

Для первого риска проведем расчет Ранга по формуле 5.1:

Ранг = Вероятность * Критичность.                                                 (5.1)

При этом изменений ни в архитектуру имеющихся данных, ни в пользовательские интерфейсы вносить не нужно , достаточно воспользоваться стандартными инструментами PHP и HTML для разметки необходимого текста на веб-странице и написание самой страницы. Также необходимо реализовать шифрование паролей для защищенного их хранения в таблице «Персонал». Для реализации требований добавлена страница SVEDENIA.PHP, внешний вид которой представлен на рисунке 5.2.

Рис. 5.2. Информационный блок страницы сведений о медицинской организации

5.1. 2-й таймбокс: реализация требований 8-11 бэклога

Разработка на 2-м ведется для функции поиска и выгрузки информации по карте пациента, а также общему функционалу сайта. Также к бэклогу витка добавлены работы по устранению дефектов из 1-го витка. На основе данных до 2-го уровня описания процесса «Выписать пациента» и ранее реализованной карте процессов можно составить итоговую карту в модели «AS-IS» (рисунок 5.3).

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

На данном этапе разработки имеется несколько рисков: связанные с формой поиска информации о пациенте: возможны некорректные запросы к БД MySQL и таблицам внутри, либо ошибка в коде самой страницы; c оставшимися на данном спринте требованиями некорректное отображение веб-страниц. Они маловероятны по причине изначальной направленности при разработке сайта на гибкий функционал и удобные средства разработки и интерфейс. В связи с высоким, но некритичным уровнем приоритета требований, соответствующие риски получат оценки 8 и 7 соответственно по шкале воздействия. При этом у первого риска достаточно высокая вероятность (8) возникновения по причине ранее реализованных механизмов поиска и выгрузки информации по картам пациентов, а у второго риска – достаточно низкая (2). Риск связанный с доступностью маловероятен (2), т.к. на тестовом сервере Denwer он доступен для всей внутренней сети, при этом при развертывании в продуктивной среде станет доступен и извне, но при этом риск достаточно критичен в связи с необходимостью в предоставлении информации пациентов (8). Имеющиеся риски внесены на таблицу отслеживания рисков? представленную в таблице 5.4. Расчет рангов рисков проведен по формуле 5.1.

Таблица 5.4. Таблица отслеживания рисков

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

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

Для реализации требований исходного бэклога необходимо создание веб-формы поиска, вывода на экран и на печать медицинской карты (рисунок 5.5) пациента. Для вывода медицинской карты будут использованы формы и методы, аналогичные представленным ранее в главе 4, но урезанные только до номера карты, для получения данных самим пациентом. Для исключения рисков реализована страница DBCONNECT.PHP для вызова и подключения к БД MySQL.

Рис. 5.5. Результат поиска карты пациента

5.2. 3-й таймбокс: реализация требований 12-19 бэклога

Третий виток содержит оформление веб-сайта и реализацию карты сайта на языке XML. Также здесь необходимо реализовать законодательные требования, которые требуются для предоставления информации о сотрудниках и о веб-сайте, а также общему функционалу сайта. На рисунке 5.6 представлено описание данного бизнес-процесса в модели «TO-BE».

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

Рисунок 5.7 содержит карту процессов в модели «TO-BE» с учетом всех вносимых в организацию изменений. 

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

На данном этапе разработки имеется несколько негативных рисков:

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

Риски 1-3 получат оценки уровня воздействия 9, 3 и 1 соответственно. При этом у первого риска достаточно низкая вероятность (2) возникновения по причине ранее реализованных (на 1-м витке) механизмов поиска и выгрузки информации, у второго риска – средняя (6), у третьего – низкая (2) по причине уже реализованных в целом имеющихся требований.
Имеющиеся риски внесем на карту рисков представленную в таблице 5.5. Риски 3-5 получат оценки уровня воздействия 9 и 9 соответственно по причине законодательной природы этих требований. При этом у первого риска достаточно низкая вероятность (3) возникновения по причине ранее реализованного веб-интерфейса, соответствующего законодательным требованиям, а второго риска – достаточно низкая (4), в связи с имеющейся схемой взаимодействия интерфейсов, описанной в четвертой главе.

Таблица 5.5. Таблица отслеживания рисков

Изменений в архитектуре данных не будет, но требуется добавление нового интерфейса – страница, наполненная картой сайта на языке XML. В рамках текущего витка планируется добавить карту сайта в подвал сайта на всех представленных интерфейсах (рисунок 5.8).

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

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

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

Список URL-адресов сайта был отсканирован при помощи Xenu и внесен в текстовый файл. Далее для реализации требований добавлена страница MAP.PHP с гипертекстовой разметкой выявленных адресов. Внешний вид страницы представлен на рисунке 5.10.

Рис. 5.10. Карта разработанного сайта

Для реализации оставшихся требований добавлена страница STAFF.PHP, а на страницу контактной информации внесен e-mail и телефон для обратной связи.
Требование 23 удалено в связи с тем, что проведена ручная индексация сайта для реализации карты и в случае необходимости можно добавить ее в поисковые системы. Для оценки успешности реализации проведено функциональное тестирование, в результате которого все тесты были пройдены: исправлены ошибки в HTML-коде, добавлены данные для обратной связи в контактную информацию. Также для проверки реализованных разработок выполнено нагрузочное тестирование, расчеты которого проводились по формулам 3.1-3.4, а результаты внесены в таблицу 5.6.

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

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

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

6. Сравнение методологий внедрения

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

Рис. 6.1. Сравнение результатов нагрузочных тестов для использованных методологий

Таблица 6.1. Сравнение результатов функционального тестирования

Рис. 6.2. Накопительная диаграмма ошибок в функциональном тестировании

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

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

Заключение

В рамках данной работы изучены каскадный, итерационный и спиралевидный методы внедрения ИС, их достоинства и недостатки и доказана целесообразность применения в разработке системы для автоматизации ключевых бизнес-процессов городской больницы, проведен сбор требований с помощью опроса персонала, изучения существующей документации и анализа полученных данных, на основе которых были сформулированы пользовательские и функциональные требования к разрабатываемой системе и определен их приоритет в разработке.
На основе рассмотренных материалов в среде ARIS Express смоделированы ключевые бизнес-процессы учреждения, каждый из которых рассмотрен с углублением до 3-го уровня, а затем составлены бизнес-процессы в модели «TO-BE» для того, чтобы показать, какие изменения привнесет разрабатываемая система на каждом из уровней организации. По причине того, что создание системы предполагало работу с БД, проведена классификация классов данных, их нормализация и спроектирована архитектура данных. Далее на базе собранных и проанализированных данных созданы соответствующие таблицы с использованием БД MySQL, установлены связи между соответствующими ключевыми полями, после чего выполнена разработка непосредственно сайта и его верстка. Далее проведено его функциональное и системное тестирование, показавшее работоспособность и готовность каждого элемента в отдельности и всей системы в целом. 

Литература 

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.

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

Катасонова Н.В. Применение каскадной, итерационной и спиралевидной моделей внедрения информационных систем для автоматизации городской больницы (часть 2) // Корпоративные информационные системы. – 2021. – №1(13). – С. 61-92. – URL: https://corpinfosys.ru/archive/issue-13/128-2021-13-hospitalautomation.

Об авторе

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

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

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