29.10.2026 – Подготовлена новая подборка статей «Техническое обслуживание и ремонт»
23.08.2026 – Подготовлена новая подборка статей «ФСБУ, ПБУ и МСФО»
20.08.2026 – Доступна новая статья «ФСБУ 10/2026 «Расходы»: основные нововведения»

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

Аннотация: в статье детально проанализирована методология внедрения Agile Kanban, идентифицированы и приоритизированы требования, спроектированы процессы и оргструктура в моделях AS-IS и TO-BE на базе нотации UML Activity Diagram до 3-го уровня детализации, заданы пользовательские формы приложения, смоделирована и нормализована структура баз данных, реализованы ключевые бизнес-процессы по назначению диагностики, расшифровке результатов диагностики, а также составлению курса терапии в среде MS Access.
Ключевые слова: метод канбан, канбан метод, канбан в разработке программного обеспечения, канбан разработка, внедрение системы канбан на предприятии, Agile Kanban методология, система канбан, канбан внедрение информационных системах, внедрить канбан систему, этапы внедрения системы канбан.

5. Первая итерация: проектирование приложений

5.1. Схема приложения

Ссылка на 1-ю часть статьи. Главная задача этапа моделирования экранов пользовательского приложения состоит в формировании наиболее простого для понимания и использования интерфейса, используя который, пользователи не будут сталкиваться с большим количеством препятствий и проблем. В процессе проектирования необходимо принимать во внимание следующие условия: для кого и для чего предназначено разрабатываемое программное обеспечение; как распределяются функции системы по конкретным страницам, и какова их последовательность. На рисунках 5.1-5.2 продемонстрирована схема приложения, отображающая взаимодействие пользовательских форм между собой.

Схема приложения (часть 1)

Рис. 5.1. Схема приложения (часть 1)

Схема приложения (часть 2)

Рис. 5.2. Схема приложения (часть 2) 

5.2. Структура таблиц баз данных

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

Данные, описанные в части 2, необходимо нормализовать. Существует несколько правил нормализации, называющиеся нормальной формой [13]. Основными нормальными формами являются:

  • первая нормальная форма (1NF), подразумевает соблюдение следующих правил:
    • определение ключевых полей;
    • устранение повторяющихся групп: на пересечении каждого столбца и каждой строки содержится только одно (атомарное значение), а не множество значений;
    • все атрибуты должны зависеть от первичного ключа. Таким образом, необходимо задать ключевые поля для таблиц, описанных в функциональных требованиях в части 2 и привести поля в таблицах к соответствию условию атомарности: одно поле – одно значение;
  • вторая нормальная форма (2NF). Отношения находится во второй нормальной форме, если они находится в первой нормальной форме, а так же все не ключевые атрибуты зависят только от первичного ключа. Для приведения разрабатываемого программного обеспечения ко второй нормальной форме необходимо создание таблиц справочников для не ключевых атрибутов. В проектируемой БД были созданы следующие таблицы-справочники:
    • жалобы;
    • диагнозы;
    • виды диагностики;
    • лекарства;
  • третья нормальная форма (3НФ). Отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме, и каждый не ключевой атрибут зависит только от первичного ключа и не зависит от другого.

Представим классы данных, нормализованные до 3-й нормальной формы, в таблице 5.1.

Таблица 5.1. Классы и объекты данных

Класс данных Данные Тип данных Размерность
Пациенты 🔑ID_Пациента Счетчик Длинное целое
Фамилия Текстовый 20
Имя Текстовый 20
Отчество Текстовый 20
Дата рождения Дата/время Краткий формат даты
Дата регистрации Дата/время Краткий формат даты
Пол Текстовый 10
Специалисты 🔑ID_Специалиста Счетчик Длинное целое
Фамилия Текстовый 20
Имя Текстовый 20
Отчество Текстовый 20
Диагнозы 🔑ID_Диагноза Счетчик Длинное целое
Наименование диагноза Текстовый 50
Жалобы 🔑ID_Жалобы Счетчик Длинное целое
Жалоба Текстовый 50
Виды диагностики 🔑ID_Диагностики Счетчик Длинное целое
Наименование диагностики Текстовый 50
Показатели нормы 🔑ID_Показателя Счетчик Длинное целое
Наименование показателя Текстовый 50
МинЗначение Числовой Одинарное с плавающей точкой
МаксЗначение Числовой Одинарное с плавающей точкой
ID_Диагностики Подстановка и отношение Длинное целое
Проведенная диагностика 🔑ID_Код Счетчик Длинное целое
Дата Дата/Время Краткий формат даты
ID_Пациента Постановка и отношение Длинное целое
ID_Показателя Постановка и отношение Длинное целое
ЗначениеПоказателя Числовой Одинарное с плавающей точкой
ID_Специалиста Постановка и отношение Длинное целое
Лекарства 🔑ID_Код  Счетчик Длинное целое
Наименование Текстовый 50
Диагнозы и лекарства  🔑ID_Код Счетчик Длинное целое
ID_Диагноза Постановка и отношение Длинное целое
ID_Лекарства Постановка и отношение Длинное целое
Вид Текстовый  50 
Дозировка возраст 1 Числовой  Длинное целое 
Дозировка возраст 2 Числовой Длинное целое
ЧастотаПриема Текстовый 50
ПриемПищи Текстовый 50
ПродолжительностьПриема Числовой Длинное целое
Комментарий Поле МЕМО 255
Первичный прием 🔑ID_Приема Счетчик  Длинное целое
Дата Дата/Время Краткий формат даты
ID_Пациента Числовой  Длинное целое
ID_Специалиста Числовой  Длинное целое
ДанныеАнамнеза Поле МЕМО 255
ПациентыЖалобы  🔑ID_Код Счетчик  Длинное целое
ID_Пациента Постановка и отношение  Длинное целое
ID_Жалобы Постановка и отношение Длинное целое
Дата Дата/Время Краткий формат даты
Направление по жалобам 🔑ID_Жалобы Постановка и отношение Длинное целое
🔑ID_Диагностики Постановка и отношение Длинное целое
Назначения 🔑ID_Назначения Счетчик Длинное целое
Дата Дата/Время Краткий формат даты
ID_Специалиста Постановка и отношение Длинное целое
ID_ПрепДоз Постановка и отношение Длинное целое

Схема БД – совокупность таблиц, которые определяют все классы данных, характеристика всех колонок, их видов, уместных значений, связей между таблицами, игнорирующая определение данных [14]. Построим схему данных, для информации, содержащейся в таблице 5.1 (рис. 5.3).

Схема данных

Рис. 5.3. Схема данных

6. Итерации 2-4: разработка программного обеспечения

6.1 Итерация 2, реализация требований 1-3

Согласно методологии разработки программного обеспечения Agile Kanban, отобразим Kanban-доску на начальном этапе разработки программного обеспечения, что соответствует итерации 2 (рис. 6.1).

Kanban-доска на этапе реализации итерации 2

Рис. 6.1. Kanban-доска на этапе реализации второй итерации

В ходе реализации итерации 2 необходимо выполнить следующие пользовательские требования: хранение данных, ввод и редактирование данных, а также вывод информации на экран. Реализация требования «Хранение данных» заключается в создании в среде разработки программного обеспечения Microsoft Access таблиц, описанных в функциональных требованиях в части 2 (рисунок 6.2).

Созданные в среде MS Access таблицы

Рис. 6.2. Созданные в среде MS Access таблицы

Электронный бланк диагностики

Рис. 6.3. Электронный бланк диагностики

Выполнение требования «Ввод и редактирование данных» требует реализации пользовательских форм. Пользовательские формы – это объекты, предназначенные для ввода и отображения данных. На рисунке 6.3 дан пример реализации экрана «Составить бланк диагностики». Для реализации пользовательского требования «Вывод информации на экран» подготовит отчетные форы. На рисунке 6.4 представлена функция поиска информации о пациенте.

Функция поиска данных о пациенте

Рис. 6.4. Функция поиска данных о пациенте

6.2 Итерация 3, реализация требований 4-6

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

Kanban-доска для реализации итерации 3

Рис. 6.5. Kanban-доска для реализации третьей итерации

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

  • установить комбинации между жалобами из таблицы «Жалобы» и видами диагностики из таблицы «Виды диагностики»;
  • создать запрос на предоставление данных;
  • создать отчет для отображения данных. 

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

Разработка требования «Автоматическая расшифровка результатов диагностики» подразумевает выполнение следующих задач: запись диапазона нормальных значений для каждого диагностического показателя и создание параметрического параметра. Для выполнения функции сравнения диагностических показателей необходимо в создаваемый параметрический SQL-запрос добавить следующее условие:

If([Анализы]![значениеПоказателя]<[ПоказателиНормы] ! [минЗначение] Or [Анализы] ! [значениеПоказателя] >[ПоказателиНормы] ! [максЗначение]; "Отклонение"; "Норма").

В данном алгоритме проходит проверка условия: если значение показателя пациента меньше минимального значения или больше максимального значения (из таблицы «Показатели нормы»), то в поле «Результат» выводится сообщение «Отклонение». В противном случае в поле «Результат» выводится сообщение «Норма». Отобразим пример результата выполнения данной функции на рисунке 6.7. 

Форма ввода жалоб пациента

Рис. 6.6. Форма ввода жалоб пациента

Автоматическая расшифровка результатов диагностики

Рис. 6.7. Автоматическая расшифровка результатов диагностики

Реализация требования «Автоматическое назначение курса терапии» осуществляется за счет выполнения следующих задач:

  • установить соотношение между диагнозами из таблицы «Диагнозы» и лекарственными препаратами из таблицы «Лекарства»;
  • осуществляется дозировки лекарственных препаратов для возрастной группы до 12 лет («Дозировка 1») и после 12 лет («Дозировка 2»);
  • запрограммировать код на языке VBA для автоматического определения возраста пациента (рис. 6.8);
  • выполнить SQL-запрос на установку дозировки лекарственных препаратов на основе вычисленного возраста пациента и установленного диагноза.

Листинг VBA-программы

Рис. 6.8. Листинг VBA-программы

На рисунке 6.9 дан пример работы функции по автоматическому назначению курса терапии.

Автоматическое назначение курса терапии

Рис. 6.9. Автоматическое назначение курса терапии

6.3 Итерация 4, реализация требований 7-8

Реализация текущей итерации требует выполнения следующих пользовательских требований: обеспечение конфиденциальности и печать данных (рис. 6.10).

Kanban-доска для итерации 4

Рис. 6.10. Kanban-доска для четвертой итерации

Для покрытия пользовательского требования «Обеспечение конфиденциальности» был задан пароль для разработанной программы (рис. 6.11).

Запрос на ввод пароля при входе в программу

Рис. 6.11. Запрос на ввод пароля при входе в программу

Выполнение требования «Печать данных» потребовало использование стандартного функционала MS Access для передачи данных на устройство печати. Для этого в ранее созданные отчеты добавлена кнопки «Печать данных». Финальная структура данных, описывающая все итерации разработки решения, приведена на рис. 6.12.

Схема данных разработанной программы

Рис. 6.12. Схема данных разработанной программы

Заключение

Целью данной работы была автоматизация ключевых бизнес-процессов городской больницы. В результате чего была детально изучена деятельность городской больницы, определены и спроектированы процессы в модели As-Is с использованием нотации UML Activity Diagram. Далее, в результате анализа модели As-Is была предложена деятельность городской больницы в модели To-Be, в которой выполнена оптимизация текущих процессов. В процессе разработки приложения в среде MS Access были изучены и применены на практике основные этапы по внедрению и применению методологии Agile Kanban. Разработка велась на основе пользовательских требований, собранных на этапе анализа, вследствие чего был составлен бэклог продукта, отображающий потребности и их приоритеты.

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

Литература

  1. Agile-манифест разработки программного обеспечения [Электронный ресурс]. – URL: http://agilemanifesto.org (Дата обращения 01.09.2021).
  2. Андерсон Д., Кармайкл Э. Канбан: краткое руководство. LeanKanban University, 2015. – 79 c.
  3. Канбан разработка [Электронный ресурс]. – URL: https://ru.wikipedia.org (Дата обращения 01.09.2021).
  4. Грин Д. Постигая Agile. М.: Манн, Иванов и Фербер, 2016. – 288 с.
  5. Книберг Х., Скарин М. Kanban и Scrum: выжимаем максимум. InfoQ.com. ISBN: 9785040907687.
  6. Анализ требований [Электронный ресурс]. – URL: https://ru.wikipedia.org/wiki/Анализ_требований (Дата обращения 01.09.2021).
  7. Вигерс К. Разработка требований к программному обеспечению. – М.: Русская редакция, 2014. – 736 с.
  8. Воронков А.Н., Колосова Т.В. Словарь по менеджменту: учебное пособие. – Н. Новгород: ННГАСУ, 2013. – 125 с.
  9. Описание бизнес-процессов [Электронный ресурс]. – URL: http://regcons.ru  (Дата обращения 01.09.2021).
  10. Модель AS-IS и модель TO-BE [Электронный ресурс]. – URL: https://studbooks.net (Дата обращения 01.09.2021). 
  11. Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS. – СПб.: Питер, 2006. – 736 с.
  12. Описание основных приемов нормализации базы данных» [Электронный ресурс]. – URL: https://support.microsoft.com/ru-ru/help/283878/description-of-the-database-normalization-basics (Дата обращения 01.09.2021).
  13. Создание связей между таблицами в базе данных [Электронный ресурс]. – URL: https://support.microsoft.com/ru-ru/help/304466/how-to-define-relationships-between-tables-in-an-access-database (Дата обращения 01.09.2021). 

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

Мартынов М.В. Применение Agile Kanban для автоматизации работы городской больницы (Часть 2) // Корпоративные информационные системы. – 2021. – №4 (16) – с. 82-99. – URL: https://corpinfosys.ru/archive/issue-16/181-2021-16-agilekanban.

Применение Agile Kanban для автоматизации работы городской больницы (Часть 2)

Об авторе

Мартынов Михаил Васильевич Мартынов Михаил Васильевич – студент 4-го курса кафедры оптических и биотехнических систем и технологий физико-технологического института РТУ МИРЭА. Тема выпускной квалификационной работы бакалавра «Применение методологии Agile Kanban для автоматизации ключевых бизнес-процессов городской больницы».

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

  1. Банкротство юридического лица: ликвидационный баланс (часть 2);
  2. Soft skills в проектах внедрения корпоративных информационных систем;
  3. Цифровизация и корпоративные информационные системы;
  4. Годовой бухгалтерский отчет организации за 2021 год;
  5. Agile Kanban для автоматизации работы городской больницы (часть 2).

2025

2024

2023

2022