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

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

Аннотация: в статье проведена пошаговая разработка согласно методологиям внедрения, составлен план разработки, затем оформлен перечень требований, представленных к реализации, осуществлено моделирование процессов до 3-го уровня в нотациях ARIS VACD и ARIS eEPC в модели «TO-BE», и составлены соответствующие карты процессов. Проведено проектирование архитектуры данных и схемы взаимодействия пользовательских интерфейсов в среде MS Visio. На основе полученных данных проведена разработка веб-приложения с использованием языков PHP, HTML и JavaScript, а также проведено функциональное и нагрузочное тестирования.
СкачатьPDF (статья), PDF (выпуск №13).
Ключевые слова: БД MySQL, методология RAD, таймбокс, чекбокс, распределение по итерациям, бэклог продукта, выписка пациента, уровни детализации, отслеживание качественных рисков, стратегия реагирования, инструменты PHP и HTML, взаимодействие пользовательских экранов, Xenu, накопительная диаграмма ошибок, ARIS Express.

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

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

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

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

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

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

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

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

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

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

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

Рис. 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. Результаты нагрузочного тестирования после автоматизации

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

t1, c

t2, c

t3, c

t4, c

t5, c

tср.ариф
c

tср.ариф
c

Δt, с

tотк, с

1 0,22 0,21 0,21 0,21 0,21 0,212 0,004  0,005 0,212±0,005
10 0,23 0,23 0,23 0,23 0,23 0,23 0,005 0,230±0,005
25 0,23 0,23 0,23 0,27 0,23 0,238  0,016 0,008 0,238±0,008
50 0,29 0,31 0,29 0,34 0,28 0,302 0,021  0,01 0,302±0,010
100 0,61 0,64 0,63 0,59 0,61 0,616 0,017  0,009 0,616±0,009
250 1,8 1,83  2,09 1,83 1,75 1,86 0,119  0,051 1,860±0,051
500 4,82 4,38  4,29 4,25 4,5 4,448  0,205 0,087 4,448±0,087
1000 12,67 10,59  9,94 9,72 10,09 10,602 1,073  0,456 10,602±0,456
2500 18,82 17,36  17,45 17,11 17,93 17,734 0,604  0,257 17,734±0,257
5000 31,15 30,93  30,52 31,2 31,2 30,73 0,501  0,213 30,730±0,213

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

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

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

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

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

Таблица 5.1. Этапы разработки ПО с использованием RAD
№ действия \ Этап разработки Начало Первый таймбокс [38], [39] (реализация требований 1-7 бэклога) Второй таймбокс (реализация требований 8-11 бэклога Третий таймбокс (реализация требований 12-15 бэклога) Четвертый таймбокс (реализация требований 16-19 бэклога)
Планирование Анализ требований (19 требований – таблица 5.1) Планирование текущего цикла разработки Планирование текущего цикла разработки Планирование текущего цикла разработки Планирование текущего цикла разработки
Составление плана разработки по спиральной модели Описание ключевого бизнес-процесса «Выписать пациента» в модели «AS-IS» Описание ключевого бизнес-процесса «Выписать пациента» в модели «AS-IS» Описание ключевого бизнес-процесса «Выписать пациента» в модели «AS-IS» Описание ключевого бизнес-процесса «Выписать пациента» в модели «AS-IS»
  Анализ рисков на основе полученных требований Анализ рисков на основе полученных требований Анализ рисков на основе полученных требований Анализ рисков на основе полученных требований
Пользовательское проектирование   Проектирование данных Проектирование данных Проектирование данных Проектирование данных
  Проектирование пользовательских интерфейсов Проектирование пользовательских интерфейсов Проектирование пользовательских интерфейсов Проектирование пользовательских интерфейсов
Конструирование   Реализация процессов средствами PHP Реализация процессов средствами PHP Реализация процессов средствами PHP Реализация процессов средствами PHP
  Тестирование Тестирование Тестирование Тестирование
      Подготовка к релизу (исправление мелких недостатков, ошибок и т.д.); Подготовка к релизу (исправление мелких недостатков, ошибок и т.д.);
      Тестирование конечного продукта Тестирование конечного продукта
Переключение       Релиз конечного продукта Релиз конечного продукта

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

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

№ 

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

Приоритет

Чекбокс

1 Правила подготовки к проведению диагностических манипуляций Высокий 1
2 Правила диспансеризации и госпитализации Высокий 1
3 Стоимость оказываемых медицинских услуг, с приложением утвержденного документа с ценами в электронном виде Высокий 1
4 Конфиденциальность персональных данных Высокий 1
5 Информация об органах охраны здоровья, надзору в сфере здравоохранения, надзору защиты прав потребителей (почтовый адрес, телефоны, электронный адрес) Высокий 1
6 Информация об страховых учреждениях, с которыми заключены договора на оказание и оплату мед. услуг по ОМС Высокий 1
7 Обязательно должна быть размещена информация о возможности проведения независимой оценки качества оказываемых услуг Высокий 1
8 Возможность вывода данных о пациенте Высокий 2
9 Доступность Высокий 2
10 Легкость в использовании Высокий 2
11 Работа системы в любом месте Высокий 2
12 Карта сайта для работы с ресурсом и удобной навигации Высокий 3
13 Версия сайта для слабовидящих людей Высокий 3
14 Иные инструменты, обеспечивающие удобную работу с ресурсом пользователя Высокий 3
15 Язык сайта (меню, карта сайта, информация на сайте) обязательно должен быть русским Высокий 3
16

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

  • Фамилия, Имя, Отчество специалиста;
  • занимаемая должность;
  • порядок записи к специалисту;
  • график приема специалистом;
  • данные сертификата специалиста – специальность, срок действия сертификата, соответствие занимающей должности;
  • дополнительные данные сертификата – кем выдан, когда выдан, уровень образования, квалификация
Средний 4
17 Возможность печати карты при выписке Средний 4
18 Удобный интерфейс на мобильных устройствах Низкий 4
19 Графики приема врачей, контактные данные специалистов или организации – электронная почта, телефон Средний 4

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

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

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

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

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

Требование

Описание риска

Вероят
ность (1…10)
Критич
ность (1…10)
Ранг (1…100) Стратегия реагирования Описание стратегии
Создание и оформление веб-страниц Невыполнение требований законодательства РФ 1 9 9 Исключение -
Наличие и доступность правил диспансеризации и госпитализации Несоответствие требованиям законодательства и МинЗдрава 1 10 10 Исключение -
Конфиденциальность персональных данных Утечка персональных данных 4 9 36 Исключение Шифрование данных в БД

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

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

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

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

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

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

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

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

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

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

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

Требование

Описание риска

Вероят
ность (1…10)
Критич
ность (1…10)
Ранг (1…100) Стратегия реагирования Описание стратегии
Форма поиска информации о пациенте Некорректные запросы к БД MySQL и таблицам или ошибка в коде 8 8 64 Понижение вероятности Необходимо организовать единую форму запроса к БД MySQL на основе уже созданных запросов 
Удобство функционала и оформления Некорректное отображение веб-страниц 2 7 14 Исключение -
Доступность Отсутствие возможности доступа к сайту извне сети 3 8 24 Исключение -

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

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

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

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

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

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

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

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

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

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

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

Карта процессов в модели «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. Таблица отслеживания рисков

Требование

Описание риска

Вероят
ность (1…10)
Критич
ность (1…10)
Ранг (1…100) Стратегия реагирования Описание стратегии
Оформление сайта Непонятность сайта для людей с ограниченными возможностями 3 9 27 Исключение -
Оформление карты сайта Нерабочие ссылки, ошибки синтаксиса и пр. 4 9 36 Понижение вероятности Для исключения ошибок применить ранее использованное ПО Xenu для формирования перечня страниц для карты
Языковое оформление сайта Непонятность сайта большинству пользователей 1 8 8 Исключение -
Вывод информации о сотрудниках Ошибки в запросе либо в коде самой страницы 2 9 18 Исключение -
Форма печати карты пациента Некорректный вывод данных 6 5 30 Понижение вероятности Использовать для вывода на печать ранее реализованную форму вывода карты пациента
Функционал сайта Несоответствие требованиям качества предоставления услуг 2 8 16 Исключение -

Изменений в архитектуре данных не будет, но требуется добавление нового интерфейса – страница, наполненная картой сайта на языке 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. Результаты нагрузочного тестирования

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

t1, c

t2, c

t3, c

t4, c

t5, c

tср.ариф
c

tср.ариф
c

Δt, с

tотк, с

1 0,11 0,15 0,07 0,13 0,17 0,126 0,03847 0,01635 0,126±0,016
10 0,1 0,11 0,13 0,07 0,11 0,104 0,02191 0,00932 0,104±0,009
25 0,12 0,15 0,1 0,08 0,11 0,112 0,02588 0,01101 0,112±0,011
50 0,22 0,2 0,15 0,18 0,15 0,18 0,03082 0,0131 0,18±0,013
100 0,17 0,19 0,18 0,17 0,19 0,18 0,01 0,00428 0,18±0,004
250 0,15 0,15 0,19 0,13 0,15 0,154 0,02191 0,00932 0,154±0,009
500 0,19 0,18 0,11 0,15 0,16 0,158 0,03114 0,01324 0,158±0,013
1000 0,58 0,6 0,53 0,72 0,56 0,598 0,07294 0,03099 0,598±0,031
2500 1,12 1,41 1,03 1,85 1,03 1,288 0,35074 0,14901 1,288±0,149
5000 5,11 5,11 5,91 5,55 5,17 5,374 0,34969 0,14857 5,374±0,149

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

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

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

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

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

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

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

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

Методология

RAD

Scrum

ASAP

Число ошибок 2 1 0 2 2 2 8
Этап 1 2 3 1 2 3 1

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

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

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

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

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

проекта 

Прикладная методология

ASAP Agile Scrum RAD
Новизна разработки и обеспеченность ресурсами Типовой. Хорошо проработаны технология и методы решения задачи
Ресурсов достаточно по причине проработки процесса разработки со стороны SAP Достаточное число ресурсов в виду адаптивности методологии под различные сроки реализации системы Недостаток ресурсов в области анализа рисков
Масштаб проекта Средние и крупные проекты Любые проекты Любые проекты
Сроки выполнения От нескольких недель до многих лет в зависимости от масштаба проекта От 2 до 6 месяцев
Заключение отдельных договоров на отдельные версии Заключается один договор. Версия и есть итоговый результат проекта На отдельную версию или несколько последовательных версий обычно заключается отдельный договор
Определение основных требований в начале проекта Да Не обязательно Нет
Изменение требований по мере развития проекта Нет Возможно (доработки и пожелания от клиента) Да
Разработка итерациями (версиями) Нет Да
Распространение промежуточного ПО Нет Да
Стоимость внесения изменений в проект Дешево на стадии формирования требований, затем все дороже Приблизительно равномерно по стоимости
Особенность методологии Строгое следование по «Маршрутной карте» Строгое наличие 3-х участников разработки и следование плану разработки Небольшая длительность таймбоксов, небольшая команда, наличие case-средств, фаза анализа рисков для решения о продолжении разработки. Отсутствие нужды в большом бюджете на старте
Реализация Последовательная, согласно «Маршрутной карте» Итерационная, со спринтами изменяемой длительности Итерационная, с возможностью для параллельного ведения работ внутри таймбокса
Простота реализации Легко Средне Средне
Число функциональных ошибок ~10, все в результате единственного этапа разработки ~10, но на каждом этапе меньшее число ошибок ~10, в среднем за виток примерно так же как за спринт в Scrum, но позволило снизить число ошибок на последних этапах за счет анализа рисков
Итоговое время разработки 25 дней 21 день 20 дней
Среднее время отклика Незначительное на числе пользователей до 500, затем значительный рост

Заключение

В рамках данной работы изучены каскадный, итерационный и спиралевидный методы внедрения ИС, их достоинства и недостатки и доказана целесообразность применения в разработке системы для автоматизации ключевых бизнес-процессов городской больницы, проведен сбор требований с помощью опроса персонала, изучения существующей документации и анализа полученных данных, на основе которых были сформулированы пользовательские и функциональные требования к разрабатываемой системе и определен их приоритет в разработке.
На основе рассмотренных материалов в среде 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.

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

Об авторе

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

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

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