ИС сети поликлиник

МИНОБРНАУКИ РОССИИИ

Федеральное государственное бюджетное

образовательное учреждение высшего образования

«Челябинский государственный университет»

(ФГБОУ ВО «ЧелГУ»)

Колледж ЧелГУ

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 — Медицинская книжка

Таблица 2 — Пациенты

Таблица 3 — Талоны

Таблица 4 — Врачи

Таблица 5 — Должность

4. ПРОТОТИПИРОВАНИЕ

Описание элемента фрейм “Главная”

Описание элемента фрейм “Записи”

Описание элемента фрейм “Запись к врачу”

Рисунок 9 - Фрейм "Выбор врача"

Описание элемента фрейм “Выбор врача”

Рисунок 10 - Фрейм "Выбор времени"

Описание элемента фрейм “Выбор времени”

Рисунок 11 - Фрейм "Чат"

Описание элемента фрейм “Чат”

Рисунок 11 - Фрейм "Профиль"

Описание элемента фрейм “Чат”

ЗАКЛЮЧЕНИЕ

В результате выполнения курсовой работы была спроектирована информационная система сети платных поликлиник.

Анализ предметной области помог понять структуру поликлиники. Функциональные и нефункциональные требования дали понять, как должна работать система сети поликлиник. После изучения нотации BPMN для информационной системы были построены модели “КАК ЕСТЬ” и “КАК ДОЛЖНО БЫТЬ”, благодаря которым можно было увидеть, что именно нужно было доработать или улучшить в системе. Диаграмма прецедентов помогла понять, как пользователь и врач может взаимодействовать с системой. Модель данных “Система сети поликлиник”, в которой описаны сущности помогли понять, как данные взаимодействуют друг с другом. При помощи Figma была построена структура будущей информационной системы и описаны ее фреймы.

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

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

СПИСОК ЛИТЕРАТУРЫ