diff --git a/labs/lab3/report.pdf b/labs/lab3/report.pdf index 2c2d1b8..9685a08 100644 Binary files a/labs/lab3/report.pdf and b/labs/lab3/report.pdf differ diff --git a/labs/lab3/report.typ b/labs/lab3/report.typ index 4072619..7a4e62b 100644 --- a/labs/lab3/report.typ +++ b/labs/lab3/report.typ @@ -49,150 +49,147 @@ === Цель работы. -Изучение требований к информационной системе и использование методов их выявления для разработки проекта системы регистрации пациента в больнице. +Изучение и формализация функциональных и нефункциональных требований к ИС, использование методов выявления требований и оформление их в виде глоссария, концепции и дополнительных спецификаций в соответствии с положениями ГОСТ 19.201-78 и ГОСТ 34.602-89. -=== Результаты. +=== Краткая концепция системы -==== 1. Общие сведения о требованиях +Назначение системы: автоматизация процессов регистрации пациентов и учета их статуса в больнице, учёта платных услуг и ведения архива выписанных пациентов; формирование управленческих отчётов. -Требование к системе — это условие или свойство, которому должна удовлетворять информационная система, чтобы удовлетворить потребности пользователей и соответствовать стандартам и техническим спецификациям. +Цели создания: cнизить время регистрации пациента и нагрузку на регистратуру; исключить бумажный учёт, обеспечить быстрый поиск и хранение истории пациентов; обеспечить возможность формирования отчётов и печати необходимых документов; повысить точность учёта платных услуг и операций. -Стандарты для работы с требованиями: +Пользователи: регистратура, лечащий врач, заведующий отделением, бухгалтер, администратор системы, медицинский архивариус. -- ГОСТ 19.201-78: Единая система программной документации. Техническое задание. Требования к содержанию и оформлению. +=== Глоссарий -- ГОСТ 34.602-89: Информационная технология. Техническое задание на создание автоматизированной системы. +- Пациент — физическое лицо, зарегистрированное в системе для получения медицинских услуг. +- Регистратура — сотрудник, выполняющий первичную регистрацию и распределение пациентов. +- Отделение — структурное подразделение больницы (кардиология, хирургия и т. п.). +- Палата — место размещения пациента в отделении; имеет пол, количество коек. +- Выписной эпикриз — документ, формируемый при выписке пациента, содержащий краткое описание лечения и результатов. +- Диагноз — код/наименование диагноза, назначаемое врачом. +- Статус больного — текущее состояние. +- Платная услуга — услуга за отдельную плату. +- Операция — хирургическое вмешательство; имеет дату/время, статус и осложнения. +- Отчёт — данные по заданным метрикам. +- Архив — данные о выписанных пациентах, сохраняемые для поиска и анализа. -Типы требований: +=== Методы выявления требований -- Функциональные — описывают действия и поведение системы при обработке информации (что система должна уметь делать). +Для построения требований рекомендуется использовать сочетание методов: -- Нефункциональные — определяют атрибуты системы или её окружения: +- Интервью с сотрудниками регистратуры, врачами, заведующими. +- Анкетирование персонала для сбора пожеланий по отчётности и интерфейсу. +- Моделирование и анализ текущих бизнес-процессов (регистрация, перевод, выписка). +- Сессии по выявлению требований (мозговой штурм с ключевыми стейкхолдерами). +- Прототипирование (демонстрация работающих прототипов экранных форм и отчётов пользователям) — быстрая валидация интерфейса. - - требования к применению (качество ПО, документации), +=== Функциональные требования - - требования к производительности (время отклика, пропускная способность), +==== Общие функции системы - - требования к реализации (стандарты, языки программирования, операционная среда), +- Учет и хранение данных пациентов. +- Поиск пациента по различным критериям. +- Журнал действий пользователей. +- Печать стандартных форм. +- Экспорт/импорт данных в стандартизованных форматах для обмена с другими системами. - - требования к надежности (частота сбоев, возможности восстановления), +==== Функции для регистратуры - - требования к интерфейсу (взаимодействие с внешними сущностями и регламент этого взаимодействия). +- Зарегистрировать нового пациента. +- Определить пациента в отделение. +- Перевести пациента в другое отделение. +- Закрепить пациента в палате / койке. +- Выставить счет за платные услуги. +- Просмотр наличия свободных мест в палатах с возможностью фильтрации по отделению и дате. +- Распечатать документы регистрации и направления. -Методы выявления требований: +==== Функции для лечащего врача -- Собеседование (интервьюирование) +- Назначить диагноз пациенту. +- Изменить/установить статус больного. +- Назначить лечение. +- Назначить процедуры. +- Назначить дату и время процедур. +- Назначить операцию. +- Назначить дату и время операции. +- Проставить статус операции. +- Назначить платные услуги. +- Выписать лекарственные средства. +- Выписать пациента. +- Создать выписной эпикриз. -- Анкетирование +==== Функции для заведующего отделением / администратора -- Моделирование и анализ бизнес-процессов +- Сформировать отчёт о пропускной способности больницы. +- Сформировать отчёт по среднему времени пребывания больных в стационаре. +- Сформировать отчёт по операциям с осложнениями. +- Просмотр загрузки палат/коек и прогноз заполнения. +- Управление списком отделений, палат, типов процедур и платных услуг. +- Права доступа: назначение ролей и прав пользователей. -- Сессии по выявлению требований (мозговой штурм) +==== Функции для бухгалтера / платёжной подсистемы -- Создание и демонстрация работающих прототипов приложений +- Вести учёт платных услуг, генерация счетов и историй оплат. +- Экспорт данных по начислениям для бухгалтерии. +- Маркировать оплату как оплачено/частично оплачено/отменено. -Документы для оформления требований: +==== Архив и отчётность -- Словарь предметной области (глоссарий) +- Перенос выписанных пациентов в архив с возможностью поиска и восстановления. +- Формирование стандартных и настраиваемых отчётов. +- Сохранение истории изменений медицинской карты и назначений. -- Концепция системы +=== Нефункциональные требования -- Дополнительные спецификации (технические требования) +==== Требования к применению -==== 2. Глоссарий +- Интерфейс должен быть доступен с минимальным обучением: обучение одного сотрудника — не более 4 часов базового курса. +- Все основные операции — не более 5 кликов/шагов. +- Формы ввода должны иметь валидацию и подсказки. -- Пациент — человек, обращающийся в больницу за медицинской помощью. +==== Требования к производительности -- Регистратор — сотрудник, оформляющий приём и регистрацию пациента. +- Время отклика на основные операции — не более 1.5 секунды при нагрузке до 50 одновременных пользователей. +- Поддержка одновременной работы до 200 пользователей в масштабируемой конфигурации при условии горизонтального масштабирования сервера. +- Формирование отчёта по пропускной способности за период до года — не более 10 секунд. -- Врач — медицинский работник, назначающий лечение и процедуры. +==== Требования к надёжности и доступности -- Заведующий отделением — руководитель подразделения, контролирующий пропускную способность и отчёты. +- Доступность системы 99.5%. +- Время восстановления после отказа — не более 2 часов при наличии резервного оборудования/контейнеров. +- Потеря данных — не более 15 минут. +- Логирование всех критических событий и операций. -- Бухгалтерия — отдел финансового учёта больницы. +==== Требования к безопасности и конфиденциальности -- Отделение — структурная единица больницы с палатами и койками. +- Аутентификация пользователей по логину/паролю; поддержка двухфакторной аутентификации для администраторов. +- Ролевой доступ: разграничение прав. +- Шифрование данных в покое и при передаче. +- Соответствие требованиям защиты персональных данных: журналы доступа, удаление персональных данных по запросу, хранение истории изменений. +- Регулярное применение обновлений безопасности и патчей. -- Палата — помещение для размещения одного или нескольких пациентов. +==== Требования к интерфейсу и совместимости -- Эпикриз — выписной документ о состоянии пациента и проведённом лечении. +- Веб-интерфейс, совместимый с современными браузерами — последние 2 версии. +- API для интеграции с лабораторией, учетной системой и электронным архивом. +- Экспорт/импорт данных в CSV/XML/JSON. -==== 3. Концепция системы +==== Требования к эксплуатации и поддержке -Цель проекта: Создать информационную систему регистрации и сопровождения пациентов в больнице, обеспечивающую автоматизацию процесса приёма, размещения, лечения и выписки пациентов, а также ведение отчётности. +- Документация: пользовательская инструкция, инструкция администратора, инструкция по резервному копированию/восстановлению. +- Система должна поддерживаться командой с 1 системным администратором и 1-2 разработчиками для сопровождения. -Основные возможности системы: -- Регистрация нового пациента +=== Cтадии разработки -- Определение отделения и палаты для пациента +1. Подготовительный этап / ТЗ — сбор требований, разработка ТЗ, согласование. +2. Проектирование — архитектура системы, модель данных, UX/UI прототипы. +3. Разработка — разработка модулей регистрации, врачебных функций, отчётов, платёжной подсистемы. +4. Тестирование — модульное, интеграционное, приёмочное тестирование с участием пользователей. +5. Внедрение и обучение — развертывание в продуктиве, обучение персонала. +6. Сопровождение — поддержка, исправление ошибок, доработка по результатам эксплуатации. -- Перевод пациента в другое отделение +=== Выводы: -- Выставление счета за услуги +Проведён анализ предметной области и описание назначение ИC. Сформирован глоссарий терминов, определены роли пользователей. Составлены детальные функциональные требования по ролям. Описаны нефункциональные требования с конкретными метриками. Подготовлены дополнительные технические спецификации. Разработан план стадий разработки и критерии приёмки в соответствии с ГОСТ 19.201-78 и ГОСТ 34.602-89. -- Просмотр наличия свободных мест - -- Назначение диагноза, статуса, лечения, процедур и операций - -- Назначение платных услуг и выписка лекарств - -- Создание выписного эпикриза - -- Формирование отчётов по пропускной способности, среднему времени пребывания, осложнениям при операциях - -==== 4. Функциональные требования - -- Регистратура: - - Зарегистрировать нового пациента - - Определить пациента в отделение - - Перевести пациента в другое отделение - - Закрепить пациента в палате - - Выставить счет за услуги - - Просматривать наличие свободных мест (мужские/женские) - -- Врач: - - Назначить диагноз - - Проставить статус больного - - Назначить лечение - - Назначить процедуры - - Назначить дату и время процедур - - Назначить операцию - - Проставить статус операции - - Назначить платные услуги - - Выписать лекарственные средства - - Выписать пациента - - Создать выписной эпикриз - -- Заведующий отделением: - - Формировать отчёты о пропускной способности - - Формировать отчёты по среднему времени пребывания - - Формировать отчёты по операциям с осложнениями - -==== 5. Нефункциональные требования - -Производительность: Время отклика системы при регистрации не более 2 секунд; пропускная способность — до 100 регистраций в день. - -Надёжность: Система должна иметь резервное копирование данных; допускается не более 1 сбоя в месяц. - -Юзабилити: Интерфейс должен быть удобен для быстрого ввода данных регистратором и врачом. - -Документация: Система сопровождается руководством пользователя и технической документацией. - -Интерфейс: Возможность взаимодействия с внешними системами (например, финансовый учёт, склад лекарств). - -==== 6. Дополнительные спецификации - -Система реализуется в виде веб-приложения. - -Используемая СУБД — PostgreSQL. - -Язык программирования: Python (backend) и JavaScript (frontend). - -Поддержка многопользовательского режима с разграничением прав доступа. - -=== Выводы - -В ходе выполнения работы были изучены методы выявления требований к информационной системе, разработан глоссарий предметной области, концепция и функциональные/нефункциональные требования для проекта «Система регистрации пациента в больнице». - -В результате проделанной работы получен полный набор требований, позволяющий строить дальнейшие модели системы, проектировать интерфейсы и готовить техническое задание для реализации. diff --git a/labs/lab4/assets/5.svg b/labs/lab4/assets/5.svg new file mode 100644 index 0000000..3bc3afd --- /dev/null +++ b/labs/lab4/assets/5.svg @@ -0,0 +1,3 @@ +ВрачСистемарегистрациипациента вбольницеПациентРегистратураЗаведующийотделениемДанные одиагнозах илеченииподтверждениерегистрацииМедицинскиеназначения,выпискиданные пациентаСчетанаоплатуданныеосчетахотчетызапросынаотчеты diff --git a/labs/lab4/assets/6.svg b/labs/lab4/assets/6.svg new file mode 100644 index 0000000..e0d2e9e --- /dev/null +++ b/labs/lab4/assets/6.svg @@ -0,0 +1,3 @@ +МедицинскоесопровождениеБухгалтерияФинансовый учетЗаведующийФормированиеотчетовВрачПациентРегистратураРегистрация исопровождениепациентаРегистрацияпациентаДанные опациентахИсториялеченияЭпикризФинансовые отчеты diff --git a/labs/lab4/assets/7.svg b/labs/lab4/assets/7.svg new file mode 100644 index 0000000..e281c48 --- /dev/null +++ b/labs/lab4/assets/7.svg @@ -0,0 +1,3 @@ +ПациентВвод данных пациентаРазмещение в отделенииЗакрепление в палатеРегистрация пациентаНазначение диагнозаНазначениепроцедур/операцийВыписка пациентаМедицинское diff --git a/labs/lab4/assets/8.svg b/labs/lab4/assets/8.svg new file mode 100644 index 0000000..5cebcde --- /dev/null +++ b/labs/lab4/assets/8.svg @@ -0,0 +1,3 @@ +Прием пациентаПроверка документовРегистрация пациентаНазначение диагнозаПланирование леченияВыписка пациентаОплата услугНазначениепроцедур/операцийСоздание эпикриза diff --git a/labs/lab4/report.pdf b/labs/lab4/report.pdf index 4160917..472511a 100644 Binary files a/labs/lab4/report.pdf and b/labs/lab4/report.pdf differ diff --git a/labs/lab4/report.typ b/labs/lab4/report.typ index c286426..6a2838c 100644 --- a/labs/lab4/report.typ +++ b/labs/lab4/report.typ @@ -63,7 +63,7 @@ Механизмы: персонал регистратуры, лечащие врачи, заведующий отделением, бухгалтерия, система. Управляющие воздействия: внутренние регламенты больницы, стандарты оформления, нормативные документы. -#align(center)[#image("assets/1.png")] +#align(center)[#image("assets/5.svg")] 2. Основные процессы проекта IDEF0. @@ -101,7 +101,7 @@ - A4: Формирование отчетов -#align(center)[#image("assets/2.png")] +#align(center)[#image("assets/6.svg")] 6. Декомпозиция уровня А-2 @@ -117,7 +117,7 @@ - A2.3: Выписка пациента -#align(center)[#image("assets/3.png")] +#align(center)[#image("assets/7.svg")] ==== Часть 2. Моделирование в нотации IDEF3. @@ -131,7 +131,7 @@ - Взаимодействие с заведующим отделением для формирования отчетов -#align(center)[#image("assets/4.png")] +#align(center)[#image("assets/8.svg")] 8. Основные информационные потоки и отношения