lab4 done

This commit is contained in:
nik
2025-10-14 17:20:41 +03:00
parent c5841a141d
commit 334a0f2425
8 changed files with 770 additions and 0 deletions

BIN
labs/lab3/report.pdf Normal file

Binary file not shown.

198
labs/lab3/report.typ Normal file
View File

@@ -0,0 +1,198 @@
#set text(size: 1.3em)
#show raw.where(block: false): box.with(
fill: luma(240),
inset: (x: 3pt, y: 0pt),
outset: (y: 3pt),
radius: 2pt,
)
#show raw.where(block: true): block.with(
fill: luma(240),
inset: 10pt,
radius: 4pt,
)
// title
#align(center)[Санкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики]
\
\
\
#align(center)[Факультет инфокоммуникационных технологий]
#align(center)[Направление подготовки 11.03.02]
\
\
#align(center)[Лабораторная работа №3]
#align(center)[Создание требований к разрабатываемой информационной системе]
\
\
\ //#align(center)[Вариант 19]
\
\
\
\
\
\
\
#align(right)[Выполнил:]
#align(right)[Дощенников Никита Андреевич]
#align(right)[Группа: К3221]
#align(right)[Проверил:]
#align(right)[Иванов Сергей Евгеньевич]
\
\
#align(center)[Санкт-Петербург]
#align(center)[2025]
#pagebreak()
=== Цель работы.
Изучение требований к информационной системе и использование методов их выявления для разработки проекта системы регистрации пациента в больнице.
=== Результаты.
==== 1. Общие сведения о требованиях
Требование к системе это условие или свойство, которому должна удовлетворять информационная система, чтобы удовлетворить потребности пользователей и соответствовать стандартам и техническим спецификациям.
Стандарты для работы с требованиями:
- ГОСТ 19.201-78: Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.
- ГОСТ 34.602-89: Информационная технология. Техническое задание на создание автоматизированной системы.
Типы требований:
- Функциональные описывают действия и поведение системы при обработке информации (что система должна уметь делать).
- Нефункциональные определяют атрибуты системы или её окружения:
- требования к применению (качество ПО, документации),
- требования к производительности (время отклика, пропускная способность),
- требования к реализации (стандарты, языки программирования, операционная среда),
- требования к надежности (частота сбоев, возможности восстановления),
- требования к интерфейсу (взаимодействие с внешними сущностями и регламент этого взаимодействия).
Методы выявления требований:
- Собеседование (интервьюирование)
- Анкетирование
- Моделирование и анализ бизнес-процессов
- Сессии по выявлению требований (мозговой штурм)
- Создание и демонстрация работающих прототипов приложений
Документы для оформления требований:
- Словарь предметной области (глоссарий)
- Концепция системы
- Дополнительные спецификации (технические требования)
==== 2. Глоссарий
- Пациент человек, обращающийся в больницу за медицинской помощью.
- Регистратор сотрудник, оформляющий приём и регистрацию пациента.
- Врач медицинский работник, назначающий лечение и процедуры.
- Заведующий отделением руководитель подразделения, контролирующий пропускную способность и отчёты.
- Бухгалтерия отдел финансового учёта больницы.
- Отделение структурная единица больницы с палатами и койками.
- Палата помещение для размещения одного или нескольких пациентов.
- Эпикриз выписной документ о состоянии пациента и проведённом лечении.
==== 3. Концепция системы
Цель проекта: Создать информационную систему регистрации и сопровождения пациентов в больнице, обеспечивающую автоматизацию процесса приёма, размещения, лечения и выписки пациентов, а также ведение отчётности.
Основные возможности системы:
- Регистрация нового пациента
- Определение отделения и палаты для пациента
- Перевод пациента в другое отделение
- Выставление счета за услуги
- Просмотр наличия свободных мест
- Назначение диагноза, статуса, лечения, процедур и операций
- Назначение платных услуг и выписка лекарств
- Создание выписного эпикриза
- Формирование отчётов по пропускной способности, среднему времени пребывания, осложнениям при операциях
==== 4. Функциональные требования
- Регистратура:
- Зарегистрировать нового пациента
- Определить пациента в отделение
- Перевести пациента в другое отделение
- Закрепить пациента в палате
- Выставить счет за услуги
- Просматривать наличие свободных мест (мужские/женские)
- Врач:
- Назначить диагноз
- Проставить статус больного
- Назначить лечение
- Назначить процедуры
- Назначить дату и время процедур
- Назначить операцию
- Проставить статус операции
- Назначить платные услуги
- Выписать лекарственные средства
- Выписать пациента
- Создать выписной эпикриз
- Заведующий отделением:
- Формировать отчёты о пропускной способности
- Формировать отчёты по среднему времени пребывания
- Формировать отчёты по операциям с осложнениями
==== 5. Нефункциональные требования
Производительность: Время отклика системы при регистрации не более 2 секунд; пропускная способность до 100 регистраций в день.
Надёжность: Система должна иметь резервное копирование данных; допускается не более 1 сбоя в месяц.
Юзабилити: Интерфейс должен быть удобен для быстрого ввода данных регистратором и врачом.
Документация: Система сопровождается руководством пользователя и технической документацией.
Интерфейс: Возможность взаимодействия с внешними системами (например, финансовый учёт, склад лекарств).
==== 6. Дополнительные спецификации
Система реализуется в виде веб-приложения.
Используемая СУБД PostgreSQL.
Язык программирования: Python (backend) и JavaScript (frontend).
Поддержка многопользовательского режима с разграничением прав доступа.
=== Выводы
В ходе выполнения работы были изучены методы выявления требований к информационной системе, разработан глоссарий предметной области, концепция и функциональные/нефункциональные требования для проекта «Система регистрации пациента в больнице».
В результате проделанной работы получен полный набор требований, позволяющий строить дальнейшие модели системы, проектировать интерфейсы и готовить техническое задание для реализации.

102
labs/lab4/assets/1.svg Normal file

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 106 KiB

102
labs/lab4/assets/2.svg Normal file

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 115 KiB

102
labs/lab4/assets/3.svg Normal file

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 105 KiB

102
labs/lab4/assets/4.svg Normal file

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 107 KiB

BIN
labs/lab4/report.pdf Normal file

Binary file not shown.

164
labs/lab4/report.typ Normal file
View File

@@ -0,0 +1,164 @@
#set text(size: 1.3em)
#show raw.where(block: false): box.with(
fill: luma(240),
inset: (x: 3pt, y: 0pt),
outset: (y: 3pt),
radius: 2pt,
)
#show raw.where(block: true): block.with(
fill: luma(240),
inset: 10pt,
radius: 4pt,
)
// title
#align(center)[Санкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики]
\
\
\
#align(center)[Факультет инфокоммуникационных технологий]
#align(center)[Направление подготовки 11.03.02]
\
\
#align(center)[Лабораторная работа №4]
#align(center)[Создание модели бизнес-процесса в нотации IDEF]
\
\
\ //#align(center)[Вариант 19]
\
\
\
\
\
\
\
#align(right)[Выполнил:]
#align(right)[Дощенников Никита Андреевич]
#align(right)[Группа: К3221]
#align(right)[Проверил:]
#align(right)[Иванов Сергей Евгеньевич]
\
\
#align(center)[Санкт-Петербург]
#align(center)[2025]
#pagebreak()
=== Цель работы.
Изучение методики создания модели бизнес-процесса в нотации IDEF0 и IDEF3 для системы регистрации пациента в больнице.
=== Результаты.
===== Часть 1. Моделирование в нотации IDEF0.
1. Контекстная диаграмма.
Главный процесс: «Регистрация и сопровождение пациента в больнице».
Входы: данные о пациенте, запросы на отчёты, данные о счетах.
Выходы: подтверждение регистрации, медицинские назначения, выписки, отчёты, счета на оплату.
Механизмы: персонал регистратуры, лечащие врачи, заведующий отделением, бухгалтерия, система.
Управляющие воздействия: внутренние регламенты больницы, стандарты оформления, нормативные документы.
#align(center)[#image("assets/1.svg")]
2. Основные процессы проекта IDEF0.
- Регистрация пациента: приём и оформление данных, распределение по отделениям, закрепление в палате.
- Медицинское сопровождение: назначение диагноза, процедур, операций, выписка.
- Финансовый учёт: выставление счетов, учет платных услуг.
- Формирование отчетов: пропускная способность, среднее время пребывания, количество операций с осложнениями.
3. Тип бизнес-процесса.
Процесс комплексный, управленческий и обслуживающий, ориентирован на автоматизацию административной и медицинской деятельности.
4. Входы, выходы, механизмы и управляющие воздействия.
- Входы: данные пациента, заявки на оплату, запросы на отчёты
- Выходы: подтверждения, отчёты, счета, выписки
- Механизмы: система, регистратура, врачи, бухгалтерия, заведующий отделением
- Управляющие воздействия: внутренние регламенты, стандарты, нормативные документы
5. Декомпозиция уровня А-1
Подпроцессы:
- A1: Регистрация пациента
- A2: Медицинское сопровождение
- A3: Финансовый учёт
- A4: Формирование отчетов
#align(center)[#image("assets/2.svg")]
6. Декомпозиция уровня А-2
- A1.1: Ввод данных пациента
- A1.2: Размещение в отделении
- A1.3: Закрепление в палате
- A2.1: Назначение диагноза
- A2.2: Назначение процедур и операций
- A2.3: Выписка пациента
#align(center)[#image("assets/3.svg")]
==== Часть 2. Моделирование в нотации IDEF3.
7. Диаграмма IDEF3
Показана последовательность действий и информационных потоков для процесса «Регистрация и сопровождение пациента»:
- Приём пациента Проверка документов Регистрация Назначение диагноза Планирование лечения Выписка
- Взаимодействие с отделом бухгалтерии для оплаты услуг
- Взаимодействие с заведующим отделением для формирования отчетов
#align(center)[#image("assets/4.svg")]
8. Основные информационные потоки и отношения
- Пациент передаёт персональные данные и заявления регистратура
- Регистратура вводит данные в систему врач, бухгалтерия
- Врач назначает процедуры регистратура, система
- Система формирует отчёты заведующий отделением
9. Перекрестки логики
- Решение о направлении пациента в отделение (A1.2) зависит от наличия свободных мест и категории палаты
- Назначение процедур/операций (A2.2) зависит от диагноза и статуса пациента
- Оплата услуг (A3) зависит от выставленного счёта и выбора пациента
=== Выводы
В ходе выполнения работы были построены модели бизнес-процессов в нотациях IDEF0 и IDEF3 для информационной системы регистрации пациента в больнице.
- Сформированы контекстная диаграмма, декомпозиции уровней А-1 и А-2
- Определены входы, выходы, механизмы и управляющие воздействия процессов
- Построена диаграмма информационных потоков и логики процессов в нотации IDEF3
В результате получены полные модели, позволяющие визуализировать последовательность действий, информационные потоки и взаимодействие участников системы, что обеспечивает основу для дальнейшей автоматизации и проектирования интерфейсов.