Применение спиралевидной модели внедрения информационных систем в городской поликлинике

Подробности

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

Автор: Гудков Евгений Алексеевич

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

Аннотация: в работе реализуется программа в среде MS FoxPro для автоматизации работы городской больницы на основе спиралевидной модели внедрения информационных систем. Выполняется идентификация требований, их приоритизация и разбиение на циклы разработки. Выявленные ключевые бизнес-процессы городской больницы моделируются в нотациях IDEF0 и DFD с разным уровнем детализации, кроме того, ведется проектирование архитектуры данных. Смоделированные процессы и данные городской больницы разрабатываются в среде MS FoxPro в разрезе ранее определенных циклов (витков спирали). Проводится функциональное и интеграционное тестирование реализованного приложения.
Скачать: PDF, PPT.
Ключевые слова: спиральная модель жизненного цикла, спиральная модель жизненного цикла программного обеспечения, спиральная модель жизненного цикла программного продукта, модели жизненного цикла аис, модели жизненного цикла информационных систем, модели жизненного цикла программного обеспечения, v образная модель жизненного цикла, эволюционная модель жизненного цикла, прототипная модель жизненного цикла, сравнительный анализ моделей жизненного цикла, IDEF0 декомпозиция пример, DFD диаграмма, методы обследования пациента, спиральная модель жизненного цикла пример, spiral model, база данных пациенты, база данных пациентов поликлиники, база данных анамнеза, сбор жалоб и анамнеза прием больных, база данных протокол осмотра пациента.

Введение

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

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

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

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

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

• учтены не все аспекты деятельности поликлиник;
• сложность в освоении;
• неудобство в эксплуатации.

Например, в работах [1-2] описана разработка программного средства, реализующего управление информацией о пациенте (добавление записи, редактирование, удаление, поиск) и процессы записи пациента на прием. Однако, там не рассмотрены аспекты автоматизации деятельности врача, такие как, например, запись в медицинскую карту и возможность просмотра данных пациента. Автоматизация этих процессов позволила бы в значительной степени повысить производительность врача, и, как следствие – уменьшить время, проводимое пациентами в очередях.

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

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

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

1.1. Понятие жизненного цикла и его модели

Информационные системы (ИС) должны удовлетворять интересам бизнеса, а также быть легко модифицируемыми и недорогими. Плохо спроектированная система, в конечном счете, требует больших затрат и времени для ее содержания и обновления. Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). Жизненный цикл (Life Cycle) определяется как развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения. Модель жизненного цикла (Life Cycle Model) – структура процессов и действий, связанных с жизненным циклом, организуемых в стадии, которые также служат в качестве общей ссылки для установления связей и взаимопонимания сторон [3].

1.2. Спиралевидная модель и ее особенности

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

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

Рис. 1.1. Спиралевидная модель: 1 – начальный сбор требований проекта; 2 – та же работа, но на основе рекомендаций заказчика; 3 – планирование проекта и анализ риска с использованием начальных требований; 4 – планирование и анализ риска реакции заказчика; 5 – переход к комплексной системе; 6 – начальный макет системы; 7 – версия системы следующего уровня; 8 – разработанная система; 9 – оценивание заказчиком

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

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

Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Барри Боэм – автор модели – в своей работе [7] формулирует десять наиболее распространённых (по приоритетам) рисков:

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

Достоинства спиральной модели:

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

Недостатки модели:

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

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

2.1. Этапы сбора и анализа требований

Весь процесс работы с требованиями к разрабатываемому продукту можно разделить на четыре этапа: 

• определение концепции продукта;
• сбор требований;
• анализ требований;
• проектирование системы.

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

На этапе сбора требований основная работа ведется с заказчиком системы и ее будущими пользователями. Цель этапа — точно определить функции продукта и способы его интеграции в существующие процессы. Качественное выполнение работ на этом этапе гарантирует то, что будущий продукт будет соответствовать ожиданиям заказчика. Четкая расстановка приоритетов обеспечивает реализацию наиболее востребованной функциональности и исключение второстепенной/невостребованной функциональности, что сэкономит бюджет и сроки [9]. 

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

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

Целью всех предыдущих этапов был сбор информации о том, кому и зачем необходим будущий продукт. Этап проектирования — это первый этап, на котором группа разработки принимает проектные решения о том, какую функциональность будет нести продукт, чтобы удовлетворить пользователей. Результатом этого этапа является законченное техническое задание к продукту. Оно должно содержать полное описание поведения будущего продукта и не содержать неоднозначностей и вопросов. На основе технического задания начинается моделирование работы продукта с конечными пользователями (используя макеты пользовательского интерфейса, к примеру) и производится тестирование технического задания. Это позволяет увеличить качество продукта и снизить его стоимость, так как стоимость внесения изменений в техническое задание всегда меньше, чем в конечный продукт [9].

2.2. Результаты сбора и анализа требований

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

• Хранение данных различных категорий:
  • пациенты;
  • врачи (персонал);
  • запись на прием;
  • анамнез пациентов.
• Возможности работы с вышеуказанными данными, включающие:
  • создание (добавление, регистрация, запись) – для всех категорий;
  • редактирование (изменение) – пациенты, персонал и протокол осмотра;
  • удаление (отмена записи) – для всех категорий;
  • отбор по ключевым параметрам (поиск) – для всех категорий;
  • сортировка по возрастанию/убыванию (в прямом/обратном алфавитном порядке) параметров – для всех категорий.
• Возможность авторизации пользователей в системе с помощью логина и пароля, хранящихся в БД.
• Разграничение доступа к данным в зависимости от исполняемой должности:
  • только работники регистратуры могут редактировать и удалять данные о пациентах, а также выписывать талон на прием;
  • только врачи могут работать с записями в электронной карте (анамнез). При этом полный доступ к записи (редактирование и удаление) получает только автор записи; остальные могут только просматривать записи без возможности изменения;
  • только главный врач (администратор) может работать с записями о сотрудниках в базе данных.
• Возможность отображения записей на прием в текущий рабочий день для каждого конкретного врача.
• Возможность просмотра врачом полной информации о пациенте, записанном на прием.

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

• Must have (обязательные) – требования с наибольшим приоритетом, без выполнения которых релиз продукта невозможен;
• Should have (желательные) – высокоприоритетные требования, которые критичны для функционала;
• Could have (возможные) – требования, которые можно включить в текущий релиз, но которые не влияют существенно на его успех;
• Won’t have (отсутствующие) – требования, которые не являются необходимыми в текущем релизе, но которые можно включить в следующие [9].

Используя метод MuSCoW, определим приоритеты полученных пользовательских требований:

• Требование 1 – Must have. Это требование является основой всей разрабатываемой программы, и без его выполнения нельзя говорить о релизе продукта.
• Требование 2 – Should have. В среде MS FoxPro возможна работа с записями (создание, редактирование, удаление, поиск, сортировка) посредством панели управления самой программы, т.е. нет прямой необходимости реализации данного требования. Вместе с тем, его реализация значительно упрощает интерфейс, вследствие чего работать с программой может любой пользователь без специальной подготовки.
• Требования 3-6 – Could have. Требования не являются ключевыми для полноценного функционирования самой программы, но их было бы неплохо включить в текущий релиз.

Функциональные требования – это требования, объясняющие, что должно быть в разрабатываемом ПО, а также какие действия должны выполняться системой. Значит, пользовательские требования будут иметь следующий вид:

• Таблицы, содержащие данные различных категорий:
  • данные о пациентах – таблица «Пациенты»;
  • данные о врачах и работниках регистратуры – таблица «Персонал»;
  • данные о записи на прием – таблица «Запись на прием»;
  • анамнез пациентов – таблица «Анамнез»;
• Формы и программные компоненты, обеспечивающие:
  • создание записей;
  • редактирование записей;
  • просмотр записей без изменения (для таблиц «Пациенты» «Анамнез»);
  • удаление записей;
  • отбор записей по ключевым параметрам;
  • сортировка записей по возрастанию/убыванию (в прямом/обратном алфавитном порядке) параметров.
• Форма и программные компоненты, обеспечивающие вход пользователя в систему.
• Программа для вызова соответствующих форм, в зависимости от исполняемой должности пользователя, вошедшего в систему.
• Форма и программные компоненты, отображающие запись на текущий день к данному врачу.
• Форма и программные компоненты для вывода полной информации о пациенте на экран.

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

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

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

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

Фундаментальным принципом реинжиниринга (реорганизации) является рассмотрение деятельности компании не с точки зрения функционирования ее структурных подразделений, а с точки зрения организации и протекания в ней бизнес-процессов. Бизнес-процесс – это связанное множество внутренних видов деятельности компании, заканчивающихся созданием продукции или услуги, необходимой потребителю. Термин “потребитель” следует понимать в широком смысле – это может быть просто клиент, а может быть и другой процесс, протекающий во внешнем окружении, например, у партнеров или субподрядчиков [11]. 

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

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

На начальных этапах создания СУБД необходимо понять, как работает организация, которую собираются автоматизировать. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но может не знать, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель, которая будет адекватна предметной области и содержать в себе знания всех участников бизнес - процессов организации [13].

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

• бесполезные, неуправляемые и дублирующие работы;
• работы без результата;
• неэффективный документооборот (нужный документ не оказывается в нужное время в нужном месте) и т.д.

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

Следует указать на распространенную ошибку при создании модели TO-BE – это создание идеализированной модели. Примером может служить построение модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знает, как должна выполняться работа по руководствам и должностным инструкциям и часто не имеет представления, как на самом деле его подчиненные выполняют работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD-BE (как должно было быть) [8].

3.1. Способы проектирования

Существует несколько способов моделирования бизнес-процессов, один из которых – функциональное моделирование IDEF0. Эта нотация используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции [14]. Элементы, используемые в процессе моделирования с помощью нотации IDEF0, приведены в табл. 3.1 [15].

Таблица 3.1. Графические элементы нотации IDEF0

Наименование	Графическое изображение
Исходный процесс
Входящие данные процесса
Исходящие данные процесса
Ограничение процесса
Ресурс процесса

Основным достоинством этой модели является то, что с её помощью можно учесть все аспекты функционирования проекта: как административные, так и организационные. Однако нотации IDEF0 недостаточно для полноценного проектирования бизнес-процесса; ведь нужно описать также и его нижние уровни, отобразив при этом документооборот и процессы преобразования информации в системе. Для этих целей используют нотацию DFD (Data Flow Diagram – диаграмма потока данных) [16]. Элементы, используемые в процессе моделирования с помощью нотации DFD, приведены в табл. 3.2 [15].

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

Описание	Графический элемент
Исходный процесс
Место хранения информации
Внешний по отношению к системе объект
Входящие/исходящие данные процесса

Недостатком данной нотации является отсутствие в схеме управляющих элементов. Впрочем, этот недостаток легко устранить, используя для моделирования верхнего уровня нотацию IDEF0.

3.2. Проектирование процессов в AS-IS с помощью IDEF0 и DFD

Проектирование в модели AS-IS позволяет показать функциональную схему медицинского учреждения в том виде, как она выглядит на данный момент. Функционирование поликлиники в представлении IDEF0 на нулевом уровне заключается в выполнении трех бизнес-процессов: А1 – «Нанять сотрудника», А2 – «Завести мед. карту», А3 – «Принять пациента». Эти процессы, а также связи между ними показаны на рис. 3.1

Рис. 3.1. Ключевые бизнес-процессы на начальном уровне описания 

Рис. 3.2. Бизнес-процесс А1 «Нанять сотрудника» на 1 уровне описания 

Подвергнем процессы А1 и А3 декомпозиции, получив описание IDEF0 на 1 уровне для каждого из них соответственно (рис. 3.2 – 3.3). 

Рис. 3.3. Бизнес-процесс А3 «Принять пациента» на 1 уровне описания

Следует указать, что процессы А1 – «Нанять сотрудника» и А2 – «Зарегистрировать мед. карту» в данном проекте являются второстепенными: не имеет особого смысла автоматизировать их по отдельности. Но в то же время без их автоматизации невозможно реорганизовать главный процесс А3 – «Принять пациента», так как для этого нужны списки (таблицы) врачей, которые могут принять пациентов, а также самих пациентов; это соответственно реализуется во вышеуказанных второстепенных процессах.

Подпроцесс А3.2 – «Обследовать пациента» нуждается в более подробном рассмотрении. Это можно сделать, подвергнув его декомпозиции. Однако выполнить моделирование 2 уровня детализации с помощью нотации IDEF0 невозможно, так как в процесс вовлекаются хранилища данных, связывающие между собой подпроцессы 2 уровня в единую цепь (поток данных). В таком случае для моделирования хорошо подходит нотация DFD, о которой было сказано выше. Результат декомпозиции – описание 2 уровня с помощью нотации DFD представлено на рис. 3.4. Дальнейшая декомпозиция не имеет смысла в рамках данного проекта.

Рис. 3.4. Результат декомпозиции процесса А3-2 – «Обследовать пациента» в нотации DFD (2 уровень описания)

3.3. Проектирование процессов в TO-BE с помощью IDEF0 и DFD 

Проектирование в модели TO-BE позволяет увидеть, как будут выглядеть ключевые бизнес-процессы функционирования медицинского учреждения после внедрения разрабатываемого приложения. Важной составляющей разрабатываемого приложения является база данных, призванная заменить все бумажные носители информации. Аналогично модели AS-IS, опишем ключевые бизнес-процессы на разных уровнях с помощью нотаций IDEF0 и DFD. Описание 0 уровня бизнес-процессов в модели TO-BE показано на рис. 3.5. По сравнению с моделью AS-IS, здесь процесс А2 – «Завести мед. карту» подвергся существенным изменениям, и его можно считать полностью автоматизированным.

Рис. 3.5. Ключевые бизнес-процессы на начальном уровне описания

Рис. 3.6. Бизнес-процесс «Нанять сотрудника» на 1 уровне описания

Рис. 3.7. Бизнес-процесс «Принять пациента» на 1 уровне описания

Как и в модели AS-IS, для более подробного рассмотрения подвергнем процессы А1 и А3 декомпозиции, получив описание IDEF0 на 1 уровне для каждого из них соответственно (рис. 3.6 – 3.7). Представление подпроцесса А3-2 – «Принять пациента» на 2 уровне описания с помощью нотации DFD показано на рис. 3.8. Из рис. 3.5 – 3.8 можно заметить, что база данных в разрабатываемом приложении используется во многих аспектах деятельности поликлиники, связывая их воедино. Это позволяет существенно ускорить доступ к данным, работу с записями, а также повысить надежность хранения информации и упростить процесс реорганизации хранилищ данных. Также замена медицинских карт компьютерными таблицами повысит удобство пользования поликлиникой для пациентов и позволит освободить физическое пространство, занимаемое хранящимися картами. 

Рис. 3.8. Результат декомпозиции процесса А2.2 – «Обследовать пациента» в нотации DFD (2 уровень описания) 

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

Раздел 4. Разработка и тестирование

4.1. Задание циклов разработки по спиралевидной модели

Разработка программного продукта согласно спиралевидной модели будет производиться в следующем порядке:

• начало:
  • анализ требований (15 требований – см. табл. 2.1);
  • моделирование ключевых бизнес-процессов с помощью нотаций IDEF0 и DFD;
  • составление плана разработки по спиральной модели.
• I виток спирали:
  • планирование текущего цикла разработки (реализовать требования 1-4 в среде FoxPro);
  • анализ рисков на основе полученных требований;
  • реализация требований 1-4 в среде FoxPro;
  • тестирование реализованных возможностей программы;
  • демонстрация прототипа программы заказчику.
• II виток спирали:
  • планирование текущего цикла разработки (реализовать требования 5-6, 9-10 в среде FoxPro);
  • анализ рисков на основе полученных требований;
  • реализация требований 5-6, 9-10 в среде FoxPro;
  • тестирование реализованных возможностей программы;
  • демонстрация прототипа программы заказчику.
• III виток спирали:
  • планирование текущего цикла разработки (реализовать требования 7-8, 11-12 в среде FoxPro);
  • анализ рисков на основе полученных требований;
  • реализация требований 7-8, 11-12 в среде FoxPro;
  • тестирование реализованных возможностей программы;
  • демонстрация прототипа программы заказчику.
• IV виток спирали:
  • планирование текущего цикла разработки (реализовать требования 13-15 в среде FoxPro);
  • анализ рисков на основе полученных требований;
  • реализация требований 13-15 в среде FoxPro;
  • тестирование реализованных возможностей программы;
  • подготовка к релизу (исправление мелких недостатков, ошибок и т.д.);
  • тестирование конечного продукта;
  • релиз конечного продукта.

4.2. 1-й прототип программы (I виток спирали) 

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

Рис. 4.1. Фрагмент таблицы «Персонал»

Рис. 4.2. Структура данных в программе FoxPro

4.3. 2-й прототип программы (II виток спирали) 

Во второй итерации в разрабатываемую программу добавлен пользовательский интерфейс для работы с таблицами «Пациенты» и «Персонал», включающий основные возможности работы с записями (создание, редактирование, удаление, сортировка, поиск). Результаты разработки показаны на рис. 4.3 – 4.4.

Рис. 4.3. Главное меню для работы с таблицей «Персонал»

Рис. 4.4. Фрагмент главного меню для работы с таблицей «Пациенты»

При нажатии кнопки «Создать» открывается окно, представленное на рис. 4.5. В открывшемся окне пользователь может ввести данные. При нажатии кнопки «Завершить регистрацию» запись добавляется в таблицу; кнопка «Назад» возвращает главное меню на экран. 

Рис. 4.5. Окно создания новой записи в таблице «Пациенты»

В процессе работы с приложением может потребоваться изменить данные. Для этого можно использовать кнопку «Изменить», предварительно выбрав запись, которую нужно изменить, в списке. В результате открывается такое же окно, как и в процессе создания записи (рис. 4.5), где пользователь может редактировать данные. Может также возникнуть необходимость удаления записи. При выборе нужной записи и нажатии кнопки «Удалить» открывается диалоговое окно, изображенное на рис. 4.6. Это сделано для того, чтобы предотвратить случайное удаление записи пользователем. При нажатии кнопки «Удалить» запись удаляется. Кнопка «Назад» возвращает пользователя к главному меню. 

Рис. 4.6. Окно, запрашивающее подтверждение пользователя на удаление записи

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

Рис. 4.7. Окно поиска

После ввода в поля необходимых значений и нажатия кнопки «Поиск» в основном списке главного меню будут показаны только записи, удовлетворяющие указанным критериям. Если одно из полей в окне поиска не было заполнено, то поиск по данному критерию не производится. Кнопка «Показать все» отменяет поиск и выводит на экран все записи. Сортировка данных в порядке возрастания происходит при нажатии на заголовок списка (например, «ФИО» или «Дата рождения» на рис. 4.3). При повторном нажатии происходит сортировка по тому же критерию, но в порядке убывания. При нажатии кнопки «Выход» программа закрывается.

4.4. 3-й прототип программы (III виток спирали) 

В третьей итерации в разрабатываемую программу добавлен пользовательский интерфейс для работы с таблицами «Запись на прием» и «Анамнез», включающий основные возможности работы с записями (создание, редактирование, удаление, сортировка, поиск). Результаты разработки показаны на рис. 4.8 – 4.9. 

Рис. 4.8. Фрагмент главного меню для работы с таблицей «Запись на прием»

Рис. 4.9. Фрагмент главного меню для работы с таблицей «Анамнез»

Рис. 4.10. Окно для записи на прием

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

Рис. 4.11. Окно для добавления протокола осмотра

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

Рис. 4.12. Режим просмотра записи в таблице «Анамнез»

4.5. Конечный продукт (IV виток спирали) 

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

Рис. 4.13. Форма для авторизации

Теперь врач может отслеживать план приема пациентов на текущий день, выбирая соответствующую вкладку внизу главного меню (рис. 4.14). При выделении записи в списке и нажатии на кнопку «Просмотр» открывается окно, отображающее все данные о пациенте в режиме чтения (рис. 4.15). 

Рис. 4.14. Отображение плана приема пациентов

Рис. 4.15. Вывод полной информации о пациенте

4.6. Тестирование программы

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

Интеграционное тестирование (integration testing) направлено на проверку взаимодействия между несколькими частями приложения (каждая из которых, в свою очередь, проверена отдельно на стадии модульного тестирования). Нагрузочное тестирование (load testing, capacity testing) – исследование способности приложения сохранять заданные показатели качества при нагрузке в допустимых пределах и некотором превышении этих пределов (определение «запаса прочности») [18]. Описание разработанных модулей программы, соответствующих требованиям (табл. 3.1) приведено в п. 4.2 – 4.5. Функциональное тестирование данных модулей показало их полную работоспособность и отсутствие ошибок, т.е. все функциональные требования были успешно реализованы. 

Интеграционное тестирование проводилось в случаях, когда происходит взаимодействие модулей программы (требования 7-8, 11-15, соответствующие III и IV виткам спирали), и также оказалось успешным. В частности, в процессе записи пациента на прием (рис. 4.10) происходит добавление в таблицу «Запись на прием» данных из таблиц «Пациенты» и «Персонал», выполняемое без сбоев в работе программы. Аналогично можно рассмотреть процессы отслеживания врачом записи на прием и просмотра данных о записанных пациентах (рис. 4.14, 4.15), где при основной выполняемой работе с таблицей «Анамнез», врач также может отображать данные из таблиц «Запись на прием» и «Пациенты».

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

Таблица 4.1. Время отклика системы при различном числе записей

Как видно из табл. 4.1, существенная задержка возникает лишь при количестве записей ~10000 и более. В остальных случаях время отклика не превышает 0,5 с и почти не замечается пользователем. Десять тысяч записей в базе образуются приблизительно за две недели работы средней городской поликлиники (в случае общего приема ~1000 чел./день за 10 рабочих дней), согласно данным, полученным в ходе опроса. В таком случае при очень большом числе записей возможно увеличение времени отклика. Однако следует учесть, что нагрузочное тестирование проводилось на обычном ПК, в то время как в поликлинике все действия обрабатываются сервером, вычислительная мощность которого во много раз выше. Таким образом, можно заключить, что нагрузочное тестирование проведено успешно. 

Заключение

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

После того, как требования были проанализированы, проводилось составление моделей AS-IS и TO-BE ключевых бизнес-процессов организации в нотациях IDEF0 (0-1 уровни) и DFD (2 уровень), и проведено их сопоставление на каждом уровне. Это позволило определить структуру разрабатываемого приложения. Затем был составлен план создания ПО согласно спиралевидной модели. Разработка приложения производилась в среде MS FoxPro, где поэтапно были реализованы все указанные требования, исправлены недочеты и ошибки в работе программы.

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

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

1. Чистякова Ю. А., Мартюгов А. С., Селяничев О. Л. Информационная система автоматизации работы медицинского учреждения // Новые информационные технологии в науке нового времени: сборник статей международной научно-практической конференции. – 2016. – С. 63-65.
2. Калиниченко В. И. Комплексная автоматизация услуги «Запись на прием к врачу» // II симпозиума «Информационные технологии для здравоохранения юга России. Сочи 2011». – С. 28.
3. ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств.
4. Орлов С. А. Технологии разработки программного обеспечения. Учебник для вузов. 4-е издание. Стандарт третьего поколения / С. А. Орлов, Б. Я. Цилькер. – М.: Издательский дом «Питер», 27 февр. 2012 г. – 608 с.
5. Невлюдов И. Ш., Евсеев В. В., Бортникова В. О. Модели жизненного цикла программного обеспечения при разработке корпоративных информационных систем технологической подготовки производства. – 2011.
6. Родигин Л. А. Оценка совокупной стоимости владения туристским интернет-проектом. / Л. А. Родигин, К. В. Наймарк. // Litres. – 5 сент. 2017 г.
7. Boehm B.W. A spiral model of software development and enhancement / Boehm B., Egyed A. // IEEE Computer, May 1988, pр. 61-72
8. Анисимов В. В. Проектирование информационных систем. Конспект лекций. М.: Дальневосточный государственный университет путей сообщения. URL: https://sites.google.com/site/anisimovkhv/publication/umr/pris (дата обращения 05.04.2018)
9. Химонин Ю. И. Сбор и анализ требований к программному продукту (Версия 1.03). – 2009, – 51 с.
10. Бариленко В. И. Бизнес-анализ как инструмент обоснования условий устойчивого развития //Вопросы региональной экономики. – 2015. – Т. 24. – №. 3. – С. 137.
11. Яблочников Е. И., Молочник В. И., Фомина Ю. Н. Реинжиниринг бизнес-процессов проектирования и производства // Учебное пособие. – СПб: СпбГУ ИТМО. – 2008.
12. Стрекалова Н. Д. Концепция бизнес-модели: методология системного анализа // Известия Российского государственного педагогического университета им. АИ Герцена. – 2009. – №. 92.
13. Половодов Д. А., Половодова Е. А., Сергин С. Е. Применение технологии IDEF для моделирования медицинских СУБД // Роль науки в развитии общества. – 2015. – С. 7.
14. РД IDEF0 – 2000. Методология функционального моделирования IDEF0.
15. Степанов Д. Ю. Анализ, проектирование и разработка корпоративных информационных систем: уровень бизнес-процессов / МИРЭА. - М., 2017.
16. Петеляк В. Е. и др. Data Flow Diagramming: особенности построения моделей описания управления потоками данных в организационных системах //Фундаментальные исследования. – 2015. – Т. 2. – №. 8.
17. Штенников Д.Г. Разработка информационных систем в образовании. Учебное пособие. – СПб: СПбГУ ИТМО, 2012. – 242 с.
18. Куликов С. С. Тестирование программного обеспечения //Базовый курс: практ. пособие. Минск: Четыре четверти. – 2015. – С. 63-110.

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

Гудков Е.А. Применение спиралевидной модели внедрения информационных систем в городской поликлинике / МИРЭА. - М., 2018. - 45 с. – URL: http://stepanovd.com/training/20-vkr/63-vkrb-2018-1-gudkov.