ИС сети поликлиник
Предмет
Тип работы
Факультет
Преподаватель
МИНОБРНАУКИ РОССИИИ
Федеральное государственное бюджетное
образовательное учреждение высшего образования
«Челябинский государственный университет»
(ФГБОУ ВО «ЧелГУ»)
Колледж ЧелГУ
09.02.04 Информационные системы (по отраслям)
КУРСОВОЙ ПРОЕКТ
По дисциплине Методы и средства проектирования информационных систем
На тему: ИС сети поликлиник
Выполнила: студентка
Группы СПИС-301
Миленина Елена Ивановна
Руководитель:
Бикбулатова Альбина Рашитовна
Оценка__________________
Подпись_________________
Челябинск,
2022
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
В наш век информационных технологий, стало реально все документы преобразовывать в электронный вид и регистратура городской поликлиники в считанные минуты может найти сведения о принятых пациентах, вызовах, кабинетах.
Современные информационные системы являются не просто средством автоматизации и повышения эффективности, но неотъемлемым элементом архитектуры компании. Организации все чаще вкладывают значительные средства в системы, способные помочь компании выжить в стремительно изменяющейся внешней среде и условиях конкуренции.
Информационная система (ИС) представляет собой систему, которая предназначена для поиска, хранения и обработки информации, и соответствующие ей организационные ресурсы (человеческие, технические, финансовые и пр.), обеспечивающие и распространяющие информацию.
Современная поликлиника является крупным многопрофильным, специализированным лечебно-профилактическим учреждением, предназначенным оказывать медицинскую помощь и осуществлять комплекс профилактических мероприятий по оздоровлению населения и предупреждению заболеваний.
Функции поликлиники:
Поликлиника проводит большую профилактическую работу, противоэпидемические мероприятия, санитарно-просветительную работу среди обратившихся пациентов, изучает здоровье населения, выявляет раннюю заболеваемость, организует статистический учет и анализ показателей состояния здоровья населения.
В поликлинике, как в системе, имеются такие недостатки как:
Однако есть еще один взгляд на проблему бесплатности медицинского обслуживания: «Бесплатный уровень - это всегда какие-то рамки. Больному всегда хочется получить больше. Материальных ресурсов лечебного учреждения не всегда хватает на то, чтобы полностью удовлетворить пациентов».
Цель работы: Организация работ поликлиники, систематизация данных и оптимизация рабочих процессов.
Задачи:
Предметная область — часть реального мира, подлежащая изучению с целью организации управления и в конечном итоге автоматизации. Она содержит в себе информацию, которую необходимо формализовать для внесения в базу данных. [1, С. 6]
Деятельность, направленная на выявление реальных потребностей заказчика, а также на выяснения смысла высказанных требований, называется анализом предметной области. Анализ предметной области – это первый шаг этапа системного анализа, с которого начинается разработка программной системы. Разработчики должны научиться
Анализом предметной области занимаются системные аналитики или бизнес-аналитики. Они передают полученные ими знания другим членам проектной команды, сформулировав их на более понятном разработчикам языке. Для передачи этих знаний обычно служит некоторый набор моделей, в виде графических схем и текстовых документов. [2]
Анализ предметной области разбивается на три фазы:
Системные требования — это более детализированное описание пользовательских требований.
Они обычно служат основой для заключения контракта на разработку программной системы и поэтому должны представлять максимально полную спецификацию системы в целом. Системные требования также используются в качестве отправной точки на этапе проектирования системы. Спецификация требований может строиться на основе различных системных моделей, таких, как объектная модель или модель потоков данных.
Функциональные требования — это перечень сервисов, которые должна выполнять система, причём должно быть указано, как система реагирует на те или иные входные данные, как она ведёт себя в определённых ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.
Стандартные формы для специфицирования функциональных требований:
Если это спецификация функции, необходимо описание предварительных условий, которые должны выполняться перед вызовом функции, и описание заключительного условия, которое должно быть выполнено после завершения выполнения функции.
Нефункциональные требования — описывают характеристики системы и её окружения, а не поведение системы. Здесь также может быть приведён перечень ограничений, накладываемых на действия и функции, выполняемые системой.
Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д.
Нефункциональные требования не связаны непосредственно с функциями, выполняемыми системой. Они связаны с такими интеграционными свойствами системы, как надёжность, время ответа или размер системы. Кроме того, нефункциональные требования могут определять ограничения на систему, например, на пропускную способность устройств ввода-вывода, или форматы данных, используемых в системном интерфейсе.
Нефункциональные требования основываются на бюджетных ограничениях, учитывают организационные возможности компании-разработчика, возможность взаимодействия разрабатываемой системы с другими программными и вычислительными системами, а также такие внешние факторы, как правила техники безопасности, законодательство о защите интеллектуальной собственности и т.п.
Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
Концептуальная модель — это определенная схема. Она в целях формирования смысловой структуры некоего объекта использует различные понятия и связи между ними. Однако стоит учитывать тот момент, что концептуальная модель системы абстрактна. Но это не единственное значение термина. Кроме того, существует понятие "концептуальная модель предметной области". Смысл данного термина состоит в том, что для описания какой-либо сферы используется перечень связанных между собой понятий. В этих целях используются классификация определений, их характеристики и свойства, а также законы происходящих в них процессов. [11]
Entity-relationship модель — это семантическая модель данных, которая предназначена для упрощения процесса проектирования базы данных. Из ER-модели могут быть порождены все виды баз данных: реляционные, иерархические, сетевые, объектные. В основе ER-модели лежат понятия «сущность», «связь» и «атрибут».
Для больших баз данных построение ER-модели позволяет избежать ошибок проектирования, которые чрезвычайно сложно исправлять, в особенности, если база данных уже эксплуатируется или на стадии тестирования. Ошибки в разработке структуры базы данных могут привести к переделке кода программного обеспечения управляющего этой базой данных. В результате время, средства и человеческие ресурсы будут использованы неэффективно.
ER-модель – это представление базы данных в виде наглядных графических диаграмм. ER-модель визуализирует процесс, который определяет некоторую предметную область. Диаграмма «сущность»-«связь» – это диаграмма, которая представляет в графическом виде сущности, атрибуты и связи.
ER-модель – это только концептуальный уровень моделирования. ER-модель не содержит деталей реализации. Для той же самой ER-модели детали ее реализации могут отличаться. [4]
В ER-моделях и моделях данных обычно выделяют до трех уровней детализации:
Модель «сущность – связь» основана на диаграммной технике. Для представления различных аспектов структуры данных (объектов, свойств объектов, связей между объектами, свойств связей и других) используются графические средства. [5]
Прототипирование — это один из этапов разработки, который заключается в продумывании содержания и расположения важных элементов интерфейса.
Основной задачей проектирования информационной системы является сокращение разницы между ожиданиями клиента и конечным результатом. На это нацелены все этапы проектирования, в том числе составление технического задания и его формат, анализ требований, бизнес-анализ и прототипирование.
Проектирование проекта происходит постепенно. Определенными этапами, каждый из которых выполняет свою задачу. Проектирование включает в себя три этапа, однако иногда, в зависимости от проекта, третий этап может быть исключен из процесса. Мы называем этот этап дизайном. Трудозатраты на каждый последующий этап становятся больше по сравнению с предыдущим, то есть каждый последующий этап требует больше сил и времени. [6]
Процесс прототипирования включает в себя следующие этапы:
Прототипирование программного обеспечения имеет много вариантов. Однако все эти методы в той или иной степени основаны на двух основных формах прототипирования: одноразовом прототипировании и эволюционном прототипировании.
Одноразовое или быстрое прототипирование относится к созданию модели, которая в конечном итоге будет отброшена, а не станет частью конечного поставляемого программного обеспечения. После завершения предварительного сбора требований создается простая рабочая модель системы, которая визуально показывает пользователям, как могут выглядеть их требования при внедрении в готовую систему. Это также форма быстрого прототипирования.
Эволюционное прототипирование сильно отличается от одноразового прототипирования. Основная цель при использовании эволюционного прототипирования-построить очень надежный прототип структурированным образом и постоянно совершенствовать его. Причина такого подхода заключается в том, что эволюционный прототип, будучи построен, образует сердце новой системы, а затем будут созданы улучшения и дальнейшие требования.
Конечный продукт строится в виде отдельных прототипов. В конце отдельные прототипы объединяются в общий дизайн. С помощью инкрементного прототипирования сокращается временной разрыв между пользователем и разработчиком программного обеспечения.
Экстремальное прототипирование как процесс разработки используется особенно для разработки веб-приложений. По сути, он разбивает веб-разработку на три этапа, каждый из которых основан на предыдущем. Первая фаза-это статический прототип, состоящий в основном из HTML-страниц. На втором этапе экраны программируются и полностью функционируют с использованием имитируемого уровня служб. На третьем этапе услуги внедряются. [8]
2.1.1 Основные термины и определения
Система — это группа взаимодействующих или взаимосвязанных элементов, которые действуют в соответствии с набором правил, образуя единое целое.
Операционная система (ОС) — это комплекс взаимосвязанных программ, предназначенных для управления ресурсами компьютера и организации взаимодействия с пользователем.
2.1.2 Основные функции и модули системы
Система разделена на:
Под серверной частью понимают набор аппаратно-программных средств, с помощью которых реализована логика работы приложения. Это то, что происходит вне браузера и компьютера пользователя. К бэкенду относится панель администрирования, управление данными, логика их передачи по запросам фронтенда.
Задача серверной разработки — сделать так, чтобы ответ от сервера доходил до клиента и спроектированные блоки функционировали нужным образом. А также создать для заказчика удобную и безопасную среду для наполнения и обновления контента на сайте.
Серверная часть должна корректно работать на популярных дистрибутивах Linux:
Фронтэнд, т.е. клиент представляет собой интерактивную часть программы, которая исполняется в веб-браузере на компьютере, смартфоне или планшете. Клиентская часть реализует пользовательский интерфейс веб-приложения и загружается в виде динамических веб-страниц.
Все страницы сайта должны корректно (согласно ТЗ) отображаться и работать в популярных современных браузерах:
Производительность сервера, необходимая для выполнения требований к быстродействию системы, определяется и фиксируется документально в передаточной документации в ходе разработки.
Все страницы сайта должны работать достаточно быстро, так чтобы пользователю не пришлось долго ждать загрузки:
Гарантирована работа на следующих наиболее популярных экранах компьютеров:
Гарантированная работа на следующих наиболее популярных экранах мобильных устройств:
Поддержка портретной и ландшафтной ориентации экрана.
Достоверность – это соответствие первичных данных фактическому положению. Исходя из практической потребности, достоверность обычно описывают в терминах ошибок. Для предупреждения ошибок наблюдения выявляют их виды и причины возникновения. Ошибки наблюдения подразделяют на два вида: ошибки регистрации и ошибки репрезентативности.
Ошибки регистрации – это погрешности, которые возможны независимо от вида наблюдения. Они бывают случайными и систематическими (тенденциозными). Существуют преднамеренные ошибки, причиной которых становится сознательное искажение данных. Непреднамеренные ошибки, как правило, носят случайный характер, они могут возникнуть в результате низкой квалификации работников.
Ошибки репрезентативности присущи только выборочному наблюдению. Причина их возникновения заключается в том, что выборочная совокупность недостаточно точно отображает состав всей изучаемой совокупности.
3. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
3.1. Описание модели “КАК ЕСТЬ”
“КАК ЕСТЬ” показана в схеме BPMN (рис.1)
Рисунок 2 — "КАК ЕСТЬ"
Процесс описания системы:
3.2. Описание модели “КАК ДОЛЖНО БЫТЬ”
“КАК ДОЛЖНО БЫТЬ” показано в схеме BPMN (рис.3).
Рисунок 3 — "КАК ДОЛЖНО БЫТЬ"
Процесс описания системы:
4.3. Требования к функционированию системы
Диаграмма прецедентов показана на рисунке 3.
Рисунок 4 — Диаграмма прецедентов
Описание диаграммы:
В системе пользователю можно:
Врачу в данной системе можно:
3.4. Концептуальная модель
3.4.1. Модель данных
Модель данных “Cистема сети поликлиник” изображена на рисунке 4.
Описание сущностей приведены в таблицах 1-5.
Рисунок 5 – Модель данных “Система поликлиник”
Таблица 1 — Медицинская книжка
Наименование параметра | Свойство | Тип данных | Пояснение | Пример |
ID_Мед.Карта | Индикационный номер медицинской книжки | integer(10) | Первичный ключ, поле уникальное, обязательное | 1234 |
ID_Пациента | Индикационный номер пациента | integer(10) | Внешний ключ, поле уникальное, обязательное | 3862 |
Диагноз | Результаты анализа, рекомендации | varchar(550) | Поле неуникальное, обязательное | Простуда |
Дата обращения | Время, когда обратился пациент | Date (7) | Поле неуникальное, обязательное | 12.02.2022 |
Таблица 2 — Пациенты
Наименование параметра | Свойство | Тип данных | Пояснение | Пример |
ID_Пациента | Индикационный номер пациента | integer(10) | Первичный ключ, поле уникальное, обязательное | 1254 |
ID_Мед.Карты | Индикационный номер медицинской книги | integer(10) | Внешний ключ, поле уникальное, обязательное | 1234 |
Фамилия | Фамилия пациента | varchar(255) | Поле неуникальное, обязательное | Невский |
Имя | Имя пациента | varchar(255) | Поле неуникальное, обязательное | Александр |
Отчество | Отчество пациента | varchar(255) | Поле неуникальное, необязательное | Палыч |
Место жительства | Место жительства пациента | varchar(200) | Поле неуникальное, обязательное | г.Челябинск, ул. Кирова, д.22 , кв. 121 |
Номер телефона | Номер телефона пациента | numeric(17,0) | Поле уникальное, необязательное | +79322407670 |
Таблица 3 — Талоны
Наименование параметра | Свойство | Тип данных | Пояснение | Пример |
ID_Талона | Индикационный номер врача | integer(10) | Первичный ключ, поле уникальное, обязательное | 1243 |
ID_Пациента | Индикационный номер пациента | integer(10) | Первичный ключ, поле уникальное, обязательное | 1254 |
Кабинет | Номер кабинета, где проводится прием | numeric(17,0) | Поле уникальное, обязательное | 102 |
Время | Время приема | time(7) | Поле неуникальное, обязательное | 11.04.2022, 13:00 |
Таблица 4 — Врачи
Наименование параметра | Свойство | Тип данных | Пояснение | Пример |
ID_Врача | Индикационный номер врача | integer(10) | Первичный ключ, уникальное поле, обязательное | 1355 |
ID_Должность | Индикационный номер должности | integer(10) | Внешний ключ, уникальное поле, обязательное | 3453 |
Фамилия | Фамилия врача | varchar(255) | Поле неуникальное, обязательное | Толстой |
Имя | Имя врача | varchar(255) | Поле неуникальное, обязательное | Лев |
Отчество | Отчество врача | varchar(255) | Поле неуникальное, необязательное | Николаевич |
Кабинет | Номер кабинета, где проводится прием | numeric(17,0) | Поле уникальное, обязательное | 205 |
Контактный номер | Контактный номер врача | numeric(17,0) | Поле уникальное, необязательное | +79322407670 |
Таблица 5 — Должность
Наименование параметра | Свойство | Тип данных | Пояснение | Пример |
ID_Должность | Индикационный номер должность | integer(10) | Первичный ключ, уникальное поле, обязательное | 1232 |
Должность | Должность врача | varchar(150) | Неуникальное поле, обязательное | Окулист |
4. ПРОТОТИПИРОВАНИЕ
Описание элемента фрейм “Главная”
Элемент | Тип | Описание |
Шапка | ||
Тело | ||
Название страницы | TEXT | Название страницы, которое кратко дает понять пользователю содержание той или иной таблицы. |
Название больницы | TEXT | Название больницы и ее номер |
Адрес больницы | TEXT | Адрес больницы |
Изображение больницы | IMAGE | Фото больницы |
Кнопка записи | BUTTON | Кнопка, при нажатии которой происходит переход на страницу записи к врачу |
Подвал | ||
Кнопка «Главная» | BUTTON | Кнопка, при нажатии которой происходит переход на страницу «Главная» |
Кнопка «Записи» | BUTTON | Кнопка, при нажатии которой происходит переход на страницу «Записи» |
Кнопка «Записаться» | BUTTON | Кнопка, при нажатии которой происходит переход на страницу записи к врачу |
Кнопка «Чат» | BUTTON | Кнопка, при нажатии которой происходит переход на страницу «Чат» |
Кнопка «Профиль» | BUTTON | Кнопка, при нажатии которой происходит переход на страницу «Профиль» |
Описание элемента фрейм “Записи”
Элемент | Тип | Описание |
Шапка | ||
Тело | ||
Название страницы | TEXT | Название страницы, которое кратко дает понять пользователю содержание той или иной таблицы. |
Подвал | ||
Описание элемента фрейм “Запись к врачу”
Элемент | Тип | Описание |
Шапка | ||
Тело | ||
Название страницы | TEXT | Название страницы, которое кратко дает понять пользователю содержание той или иной таблицы. |
Выберите врача | BUTTON | Кнопка, при нажатии которой открывается COMBO BOX «Выбор врача» |
Выберите дату и время приема | BUTTON | Кнопка, при нажатии которой открывается COMBO BOX «Выбор даты и времени» |
Подвал |
Рисунок 9 - Фрейм "Выбор врача"
Описание элемента фрейм “Выбор врача”
Элемент | Тип | Описание |
Шапка | ||
Тело | ||
Врач 1 | BUTTON | Кнопка, при нажатии которой происходит выбор Врача 1 |
Врач 2 | BUTTON | Кнопка, при нажатии которой происходит выбор Врача 2 |
Подвал |
Рисунок 10 - Фрейм "Выбор времени"
Описание элемента фрейм “Выбор времени”
Элемент | Тип | Описание |
Шапка | ||
Тело | ||
Календарь | IMAGE | Календарь с выбором даты и времени |
Подвал |
Рисунок 11 - Фрейм "Чат"
Описание элемента фрейм “Чат”
Элемент | Тип | Описание |
Шапка | ||
Тело | ||
Название страницы | TEXT | Название страницы, которое кратко дает понять пользователю содержание той или иной таблицы. |
Подвал |
Рисунок 11 - Фрейм "Профиль"
Описание элемента фрейм “Чат”
Элемент | Тип | Описание |
Шапка | ||
Тело | ||
Название страницы | TEXT | Название страницы, которое кратко дает понять пользователю содержание той или иной таблицы. |
Фото профиля | IMAGE | Фото профиля пользователя |
Поле ФИО | TEXT | Поле, в котором написаны ФИО пользователя |
Поле Почта | TEXT | Поле, в котором написана почта пользователя |
Поле Полис | TEXT | Поле, в котором написан полис пользователя |
Подвал |
ЗАКЛЮЧЕНИЕ
В результате выполнения курсовой работы была спроектирована информационная система сети платных поликлиник.
Анализ предметной области помог понять структуру поликлиники. Функциональные и нефункциональные требования дали понять, как должна работать система сети поликлиник. После изучения нотации BPMN для информационной системы были построены модели “КАК ЕСТЬ” и “КАК ДОЛЖНО БЫТЬ”, благодаря которым можно было увидеть, что именно нужно было доработать или улучшить в системе. Диаграмма прецедентов помогла понять, как пользователь и врач может взаимодействовать с системой. Модель данных “Система сети поликлиник”, в которой описаны сущности помогли понять, как данные взаимодействуют друг с другом. При помощи Figma была построена структура будущей информационной системы и описаны ее фреймы.
Использование данной информационной системы упрощает доступ к персональным данным пациента, централизует хранение всех данных о пациенте. Благодаря этому повышается уровень качества обслуживания и лечения. Все это приводит к повышению управляемости поликлиники и увеличению прибыли.
Спроектированная информационная система сети больниц в дальнейшем может быть доработана, к примеру добавление для пользователей функции изменение записей на прием, создание календаря рабочих дней врачей и использована в любой сети больниц
СПИСОК ЛИТЕРАТУРЫ