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

Подробности

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

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

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

Аннотация: в статье рассмотрены и исследованы каскадная, итерационная и спиральная модели внедрения информационных систем. Для каждой модели выбрана соответствующая методология (ASAP для каскадной, Scrum – итерационной, и RAD – спиралевидной) и расписаны основные шаги при проведении разработки. Опираясь на изученные данные, проведено описание ключевых бизнес-процессов городской больницы в модели AS-IS и составлена карта процессов. Также собран перечень пользовательских и законодательных требований к разрабатываемой системе.
Скачать: PDF (статья), PDF (выпуск №12).
Ключевые слова: автоматизация больницы, методология ASAP, быстрая разработка приложений, rapid application development, RAD, RAD-программирование, платформы быстрой разработки приложений, сравнение методологий Agile и Waterfall, Agile или Waterfall, SCRUM революционный метод управления проектами, цифровизация медицины в России, цифровизация здравоохранения.

Введение

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

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

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

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

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

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

Цель и задачи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                (3.1)

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

                                   (3.2)

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

                                    (3.3)

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

 .                                             (3.4)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Литература 

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

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

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

Об авторе

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

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

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