Курсовая Создание автоматизированной информационной системы Больница
Работа добавлена на сайт bukvasha.net: 2015-10-25Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
от 25%
Подписываем
договор
Министерство образования и науки Российской Федерации
Федеральное государственное образовательное учреждение
среднего профессионального образования
«Канский технологический колледж»
Специальность 230103.51 «Автоматизированные системы обработки информации и управления»
КУРСОВАЯ РАБОТА
Создание автоматизированной информационной системы
«Больница»
Пояснительная записка
Выполнил:
Студент группы АВ 41
Н.В.Демянюк
Проверила:
Ю.В. Руминене
Канск 2010
Введение
Больница – лечебное учреждение для стационарного лечения больных.
Деятельность больницы состоит из:
- приём больных;
- назначение курсов лечения;
- консультация врачей
Цель курсовой работы состоит в том, чтобы автоматизировать деятельность «Больницы»,т.е уменьшить затраты времени на обслуживание клиентов персоналом, за счет работы в шаблоне о клиентских данных.
Для реализации поставленной цели необходимо:
-провести предпроектное исследование;
-разработать техническое проектирование;
-разработать программно-информационное ядро БД;
-разработать клиентское программное обеспечение.
1. Теоретическая часть
1.1Предпроектное исследование
1.1.1 Анализ предметной области
Бизнес процессы оказания услуг клиентам:
- приём клиентов
- назначение приёма к врачу
- регистрация пациента
- назначение курса лечения
Рисунок 1: Участники системы
1 Общие положения
1.1
Полное наименование системы и ее условное обозначение
Полное наименование системы: автоматизированная система учета клиентов (пациентов) "АИС Больница".
Краткое наименование системы: АИС Больница.
1.2
Номер договора (контракта)
Шифр темы: КР.РИЭАИС.23010351
Номер контракта: №3 от 22.11.2007.
1.3 Наименования организации-заказчика и организаций-участников работ
Заказчиком системы является: Федеральное Агентство по образованию Государственное образовательное учреждение среднего профессионального образования Канский Технологический Колледж.
Адрес заказчика: г. Канск, Кайтымская, 56.
Разработчиком системы является Демянюк Никита Владимирович.
Адрес разработчика: г. Канск, Герцена-9, 24.
1.4 Перечень документов, на основании которых создается система
Основанием для разработки АС "Кадровое агентство" является задание на курсовое проектирование по дисциплине «Разработка и эксплуатация автоматизированных информационных систем» студентке 4 курса группы АВ-41 Специальности №230103.51 «Автоматизированные системы обработки информации и управления (по отраслям)»
1.5 Плановые сроки начала и окончания работы по созданию системы
Плановый срок начала работ по созданию автоматизированная информационная система учета пациентов "АИС Больница"– 11 ноября 2010года.
Плановый срок окончания работ по созданию автоматизированная информационная система учета пациентов "АИС Больница" – 22 декабря 2010 года.
1.6 Источники и порядок финансирования работ
Источников финансирования нет.
1.7 Порядок оформления и предъявления заказчику результатов работ по созданию системы
Материалы отчета предоставляются в распечатанном виде и в виде демонстрационных материалов на накопителе электронных данных – дискете, флеш-накопителе данных.
Работа информационной системы демонстрируется на компьютере на контрольных примерах.
1.8 Перечень нормативно-технических документов, методических материалов, использованных при разработке ТЗ
При разработке автоматизированной информационной системы и создании проектно-эксплуатационной документации исполнитель должен руководствоваться требованиями следующих нормативных документов:
– ГОСТ 19.201-78. ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ;
– ГОСТ 34.601-90. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания;
– ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплексность и обозначение документов при создании автоматизированных систем;
– РД 50-34.698-90. Методические указания. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.
-Описание информационного обеспечения системы
-Схема структурная комплекса технических средств
-Описание программного обеспечения
-Содержание и структура документов должна соответствовать ГОСТ РД 50-34.698-90.
-Стандарт предприятия. Общие требования к оформлению расчетно-пояснительной записки курсовых проектов (работ) и выпускных квалификационных работ. Текстовые материалы и иллюстрации СТП ГОУ СПО «КТК» 2010
-Стандарт требования Каннского Технологического колледжа.
1.9 Определения, обозначения и сокращения
| N | Сокращение | Расшифровка |
| 1 | БЦ | Больница |
| 2 | ФА | Федеральное агенство |
| 3 | ТЗ | Техническое задание |
| 4 | АИС | Автоматизированная информационная система |
2 Назначение и цели создания системы
2.1 Назначение системы
АИС «Больница» предназначена для комплексного информационно-аналитического обеспечения процессов «Канский Технологический Колледж», в части исполнения следующих процессов:
- фиксирование пациентов в БД;
- составление истории о курсах лечения и приёмах;
- регистрация всех процессов;
- занесение данных в историю пациента;
АИС «Больница» предполагается использовать в Федеральном агентстве «Канский Технологический Колледж», и в его территориальных органах, задействованных в исполнении вышеперечисленных процессов.
2.2 Цели создания системы
Основными целями создания АИС «Больница» являются:
1. Замещение существующей информационной системы на полностью автоматизированную, что значительно упростит затраты времени и сил на работу с пациентами.
2. Позволит повысить оперативность работы с клиентами. Обеспечит возможность оказания услуг большему числу пациентов.
3. Повысит качество работы с клиентами. Уменьшит риск ошибок при редактировании и добавлении информации о пациентах.
4. Наглядность и структурность данных обеспечит удобство в работе с информацией.
Для реализации поставленных целей система должна решать следующие задачи:
1. Ввод данных в общий реестр, содержащий все данные о пациентах.
2. Редактирование данных в информационной системе.
3. Построение отчётов по запросам персонала.
3. Характеристика объекта автоматизации
Описание предметной области
Администрация больницы заказала разработку информационной системы для отдела приема пациентов и медицинского секретариата. Новая система предназначена для обработки данных о врачах, пациентах, приеме пациентов и лечении. Система должна выдавать отчеты по запросу врачей или администрации. Во время предпроектного обследования составлено следующее описание деятельности рассматриваемых подразделений.
Перед приемом в больницу проводится встреча пациента и врача. Врач сообщает в отдел приема пациентов об ожидаемом приеме больного и передает данные о нем. Пациент может быть принят в больницу более чем один раз, но если пациент ранее не лечился в больнице, то ему присваивается регистрационный номер и записываются его данные (фамилия, имя и отчество, адрес и дата рождения). Пациент должен быть зарегистрирован в системе до приема в больницу.
Спустя некоторое время врач оформляет в отделе приема пациентов прием больного. При этом определяется порядковый номер приема и запоминаются данные приема пациента. После этого отдел приема посылает сообщение врачу для подтверждения приема больного. В это сообщение включается регистрационный номер пациента и его фамилия, порядковый номер приема, дата начала лечения и номер палаты.
В день приема пациент сообщает в отдел приема о своем прибытии и передает данные о себе (или изменения в данных). Отдел приема проверяет и при необходимости корректирует данные о пациенте. Если пациент не помнит свой регистрационный номер, то выполняется соответствующий запрос. После регистрации пациент получает регистрационную карту, содержащую ФИО пациента, адрес, дату рождения, номер телефона, группу крови, название страховой компании и номер страховки.
Во время пребывания в больнице пациент может лечиться у нескольких врачей; каждый врач назначает один или более курсов лечения, но каждый курс лечения назначается только одним врачом. Данные о курсах лечения передаются в медицинский секретариат, который занимается координацией лечения пациентов, регистрируются и хранятся там. Данные включают номер врача, номер пациента, порядковый номер приема, название курса лечения, дату назначения, время и примечания.
При необходимости врач запрашивает в медицинском секретариате историю болезни пациента, содержащую данные о курсах лечения, полученных пациентом.
3.1 Диаграмма DFD-модели предметной области АИС «Больница»
|
3.2 Диаграмма IDEF0-модели предметной области АИС «Больница»
Рисунок 2 – «Диаграмма IDEF0 модели»
4 Требования к системе
4.1 Требования к системе в целом
4.1.1 Требования к структуре и функционированию системы
4.1.1.1 Перечень подсистем, их назначение и основные характеристики
В состав АИС «Больница» должны входить следующие подсистемы:
- Подсистема приема пациентов;
- Подсистема хранения данных;
- Подсистема формирования отчетности;
Подсистема приёма пациентов обеспечивает регистрацию пациентов, назначение приёма к врачу и курса лечения.
Подсистема хранения данных обеспечивает хранение всех данных о пациентах и истории их курса лечения. Кроме того содержаться данные о всех приёмах и врачах.
Подсистема формирования отчетности предназначена для создания и формирования отчетов в виде удобном для вывода на печатающие устройства на основе данных АИС Больница, проектирования и разработки форм регламентированной отчетности, настройки планового формирования и доставки регламентированных отчетов, формирования и предоставления по запросам пользователей аналитических и статистических отчетов в различных форматах (включая графические), отображения регламентированных отчетов с помощью веб-интерфейса, вывода подготовленных отчетных форм на печать.
4.1.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы
Требования не предъявляются.
4.1.1.3 Требования к характеристикам взаимосвязей создаваемой системы со смежными системами
Требования не предъявляются.
4.1.1.4 Требования к режимам функционирования системы
Для АИС «Больница» определен следующий режим функционирования:
- Нормальный режим функционирования;
В нормальном режиме функционирования системы:
- клиентское программное обеспечение и технические средства пользователей и администратора системы обеспечивают возможность функционирования в течение рабочего дня (с 09:00 до 18:00) пять дней в неделю;
- серверное программное обеспечение и технические средства северов обеспечивают возможность круглосуточного функционирования, с перерывами на обслуживание;
- исправно работает оборудование, составляющее комплекс технических средств;
- исправно функционирует системное, базовое и прикладное программное обеспечение системы.
Для обеспечения нормального режима функционирования системы необходимо выполнять требования и выдерживать условия эксплуатации программного обеспечения и комплекса технических средств системы, указанные в соответствующих технических документах (техническая документация, инструкции по эксплуатации и т.д.).
4.1.1.5 Требования по диагностированию системы
АИС «Больница» должна предоставлять инструменты диагностирования основных процессов системы, трассировки и мониторинга процесса выполнения программы.
Компоненты должны предоставлять удобный интерфейс для возможности просмотра диагностических событий, мониторинга процесса выполнения программ.
При возникновении аварийных ситуаций, либо ошибок в программном обеспечении, диагностические инструменты должны позволять сохранять полный набор информации, необходимой разработчику для идентификации проблемы (снимки экранов, текущее состояние памяти, файловой системы).
4.1.1.6 Перспективы развития, модернизации системы
АИС «Больница» должна реализовывать возможность дальнейшей модернизации как программного обеспечения, так комплекса технических средств.
Также необходимо предусмотреть возможность увеличения производительности системы путем её масштабирования.
4.1.2 Требования к численности и квалификации персонала системы
Численность и квалификация персонала системы должны определяться с учетом следующих требований:
– структура и конфигурация системы должны быть спроектированы и реализованы с целью минимизации количественного состава обслуживающего персонала;
– структура системы должна предоставлять возможность управления всем доступным функционалом системы как одному администратору, так и предоставлять возможность разделения ответственности по администрированию между несколькими администраторами;
– для администрирования системы к администратору не должны предъявляться требования по знанию всех особенностей функционирования элементов, входящих в состав администрируемых компонентов системы;
– аппаратно-программный комплекс системы не должен требовать круглосуточного обслуживания и присутствия администраторов у консоли управления.
Штатный состав персонала, эксплуатирующего систему, должен формироваться на основании нормативных документов Российской Федерации.
Все специалисты должны работать с нормальным графиком работы не более 8 часов в сутки.
Система реализуется на персональных компьютерах, поэтому требования к организации труда и режима отдыха при работе с ней должны устанавливаться, исходя из требований к организации труда и режима отдыха при работе с этим типом средств вычислительной техники.
Для обеспечения максимальной работоспособности и сохранения здоровья профессиональных пользователей на протяжении рабочей смены должны устанавливаться регламентированные перерывы: через 2 часа после начала рабочей смены и через 1.5 – 2.0 часа после обеденного перерыва продолжительностью 15 минут каждый или продолжительностью 10 минут через каждый час работы.
Продолжительность непрерывной работы персонала с разрабатываемой системой и персональными компьютерами без регламентированного перерыва не должна превышать 2 часа.
Деятельность персонала по эксплуатации системы должна регулироваться должностными инструкциями.
Для эксплуатации АИС «Больница» определены следующие роли:
- Мед. секретарь(пользователи);
- Врачи;
- Системный администратор
Основными обязанностями мед. секретаря являются:
- ведение учетных записей ;
- составление и подготовка отчётов;
- фиксирование пациентов в БД;
Основными обязанностями врачей являются:
- приём пациентов;
- назначение курса лечения пациенту;
- наблюдение пациента в течении курса лечения;
Врач должен обладать высоким уровнем квалификации и практическим опытом выполнения работ по работе с пациентом.
Основными обязанностями системных администраторов являются:
- обеспечение бесперебойной работы системы в больнице;
- наладка и устранение оборудования и ошибок при их появлении;
Мед. секретари ( пользователи системы) должны иметь опыт работы с персональным компьютером на базе операционных систем Microsoft Windows на уровне квалифицированного пользователя и свободно осуществлять базовые операции в стандартных Windows.
Роли системного администратора, администратора баз данных и администратора информационной безопасности могут быть совмещены в роль мед. секретаря.
4.1.3 Показатели назначения
Для АСУ указывают:
- степень приспособляемости системы к изменению процессов и методов управления, к отклонениям параметров объекта управления;
- допустимые пределы модернизации и развития системы;
- вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.
АИС Больницы должны обеспечивать возможность исторического хранения данных с глубиной не менее 10 лет.
Система должна обеспечивать возможность одновременной работы 50 пользователей для подсистемы операционной деятельности, и не менее 10-ти пользователей для других подсистем при следующих характеристиках времени отклика системы:
– для операций навигации по экранным формам системы – не более 5 сек;
– для операций формирования справок и выписок – не более 10 сек.
Время формирования аналитических отчетов определяется их сложностью и может занимать продолжительное время.
Система должна предусматривать возможность масштабирования по производительности и объему обрабатываемой информации без модификации ее программного обеспечения путем модернизации используемого комплекса технических средств. Возможности масштабирования должны обеспечиваться средствами используемого базового программного обеспечения.
4.1.4 Требования к надежности
Система должна сохранять работоспособность и обеспечивать восстановление своих функций при возникновении следующих внештатных ситуаций:
– при сбоях в системе электроснабжения аппаратной части, приводящих к перезагрузке ОС, восстановление программы должно происходить после перезапуска ОС и запуска исполняемого файла системы;
– при ошибках в работе аппаратных средств (кроме носителей данных и программ) восстановление функции системы возлагается на ОС;
– при ошибках, связанных с программным обеспечением (ОС и драйверы устройств), восстановление работоспособности возлагается на ОС.
Для защиты аппаратуры от бросков напряжения и коммутационных помех должны применяться сетевые фильтры.
Все внешние элементы технических средств системы, находящиеся под напряжением, должны иметь защиту от случайного прикосновения, а сами технические средства иметь зануление или защитное заземление в соответствии с ГОСТ 12.1.030-81 и ПУЭ.
Система электропитания должна обеспечивать защитное отключение при перегрузках и коротких замыканиях в цепях нагрузки, а также аварийное ручное отключение.
Общие требования пожарной безопасности должны соответствовать нормам на бытовое электрооборудование. В случае возгорания не должно выделяться ядовитых газов и дымов. После снятия электропитания должно быть допустимо применение любых средств пожаротушения.
Факторы, оказывающие вредные воздействия на здоровье со стороны всех элементов системы (в том числе инфракрасное, ультрафиолетовое, рентгеновское и электромагнитное излучения, вибрация, шум, электростатические поля, ультразвук строчной частоты и т.д.), не должны превышать действующих норм (СанПиН 2.2.2./2.4.1340-03 от 03.06.2003 г.).
4.1.6 Требования к эргономике и технической эстетике
Взаимодействие пользователей с прикладным программным обеспечением, входящим в состав системы должно осуществляться посредством визуального графического интерфейса (GUI). Интерфейс системы должен быть понятным и удобным, не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм. Навигационные элементы должны быть выполнены в удобной для пользователя форме. Средства редактирования информации должны удовлетворять принятым соглашениям в части использования функциональных клавиш, режимов работы, поиска, использования оконной системы. Ввод-вывод данных системы, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать удобный доступ к основным функциям и операциям системы.
Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление системой должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен используется главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм.
Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений) должны быть на русском языке.
Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях система должна выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных.
Экранные формы должны проектироваться с учетом требований унификации:
– все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации;
– для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы;
– внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должны реализовываться одинаково для однотипных элементов.
Система должна соответствовать требованиям эргономики и профессиональной медицины при условии комплектования высококачественным оборудованием (ПЭВМ, монитор и прочее оборудование), имеющим необходимые сертификаты соответствия и безопасности Росстандарта.
4.1.7 Требования к транспортабельности для подвижных АС
Требования не предъявляются.
4.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
Система должна быть рассчитана на эксплуатацию в составе программно–технического комплекса Заказчика и учитывать разделение ИТ инфраструктуры Заказчика на внутреннюю и внешнюю. Техническая и физическая защита аппаратных компонентов системы, носителей данных, бесперебойное энергоснабжение, резервирование ресурсов, текущее обслуживание реализуется техническими и организационными средствами, предусмотренными в ИТ инфраструктуре Заказчика.
Для нормальной эксплуатации разрабатываемой системы должно быть обеспечено бесперебойное питание ПЭВМ. При эксплуатации система должна быть обеспечена соответствующая стандартам хранения носителей и эксплуатации ПЭВМ температура и влажность воздуха.
Периодическое техническое обслуживание используемых технических средств должно проводиться в соответствии с требованиями технической документации изготовителей, но не реже одного раза в год.
Периодическое техническое обслуживание и тестирование технических средств должны включать в себя обслуживание и тестирование всех используемых средств, включая рабочие станции, серверы, кабельные системы и сетевое оборудование, устройства бесперебойного питания.
В процессе проведения периодического технического обслуживания должны проводиться внешний и внутренний осмотр и чистка технических средств, проверка контактных соединений, проверка параметров настроек работоспособности технических средств и тестирование их взаимодействия.
На основании результатов тестирования технических средств должны проводиться анализ причин возникновения обнаруженных дефектов и приниматься меры по их ликвидации.
Восстановление работоспособности технических средств должно проводиться в соответствии с инструкциями разработчика и поставщика технических средств и документами по восстановлению работоспособности технических средств и завершаться проведением их тестирования. При вводе системы в опытную эксплуатацию должен быть разработан план выполнения резервного копирования программного обеспечения и обрабатываемой информации. Во время эксплуатации системы, персонал, ответственный за эксплуатацию системы должен выполнять разработанный план.
Размещение помещений и их оборудование должны исключать возможность бесконтрольного проникновения в них посторонних лиц и обеспечивать сохранность находящихся в этих помещениях конфиденциальных документов и технических средств.
Размещение оборудования, технических средств должно соответствовать требованиям техники безопасности, санитарным нормам и требованиям пожарной безопасности.
Все пользователи системы должны соблюдать правила эксплуатации электронной вычислительной техники.
Квалификация персонала и его подготовка должны соответствовать технической документации.
4.1.9 Требования к защите информации от несанкционированного доступа
Требования не предъявляются.
4.1.10 Требования по сохранности информации при авариях
Программное обеспечение АС Кадры должно восстанавливать свое функционирование при корректном перезапуске аппаратных средств. Должна быть предусмотрена возможность организации автоматического и (или) ручного резервного копирования данных системы средствами системного и базового программного обеспечения (ОС, СУБД), входящего в состав программно технического комплекса Заказчика.
Приведенные выше требования не распространяются на компоненты системы, разработанные третьими сторонами и действительны только при соблюдении правил эксплуатации этих компонентов, включая своевременную установку обновлений, рекомендованных производителями покупного программного обеспечения.
4.1.11 Требования к защите от влияния внешних воздействий
Требования не предъявляются.
4.1.12 Требования к патентной частоте
Требования не предъявляются.
4.1.13 Требования по стандартизации и унификации
Взаимодействие пользователей с прикладным программным обеспечением, входящим в состав системы должно осуществляться посредством визуального графического интерфейса (GUI). Интерфейс системы должен быть понятным и удобным, не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм. Навигационные элементы должны быть выполнены в удобной для пользователя форме. Средства редактирования информации должны удовлетворять принятым соглашениям в части использования функциональных клавиш, режимов работы, поиска, использования оконной системы. Ввод-вывод данных системы, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать удобный доступ к основным функциям и операциям системы.
Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление системой должно осуществляется с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен используется главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм.
Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений) должны быть на русском языке.
Экранные формы должны проектироваться с учетом требований унификации:
– все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации;
– для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы;
– внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должны реализовываться одинаково для однотипных элементов.
Система должна соответствовать требованиям эргономики и профессиональной медицины при условии комплектования высококачественным оборудованием (ПЭВМ, монитор и прочее оборудование), имеющим необходимые сертификаты соответствия и безопасности Росстандарта.
4.1.14 Дополнительные требования
Дополнительные требования не предъявляются.
4.2 Требования к функциям (задачам), выполняемым системой
Перечень функций справочников должен быть уточнен на стадиях технического проектирования и опытной эксплуатации.
Подсистема управления нормативно-справочной информацией должна обеспечивать ведение следующих справочников и реестров:
- Реестр «Врачи»;
- Реестр «Приёмы»;
- Реестр «Курсы лечения»;
- Реестр «Рег. карты»;
- Реестр «Пациенты»;
Реестр «Врачи»:
Реестр «Врачи» должен обеспечивать возможность обработки необходимого набора атрибутов, включая:
- Фамилия Имя Отчество;
- № паспорта врача;
- Специализация;
- Дата рождения;
- Заслуги;
Реестр «Приёмы»:
Реестр «Приёмы» должен обеспечивать возможность обработки необходимого набора атрибутов, включая:
- № паспорта врача;
- Регистрационный номер;
- Дата приёма;
- № приёма;
Реестр «Курсы лечения»:
Реестр «Курсы лечения» должен обеспечивать возможность обработки необходимого набора атрибутов, включая:
- № курса;
- Регистрационный номер;
- № приёма;
- Описание курса;
Реестр «Рег. карта»:
Реестр «Рег. карта» должен обеспечивать возможность обработки необходимого набора атрибутов, включая:
- ФИО;
- Регистрационный номер;
- Адрес;
- Дата рождения;
- № телефона;
- страховая компания;
- номер страховки;
Реестр «Пациенты»:
Реестр «Пациенты» должен обеспечивать возможность обработки необходимого набора атрибутов, включая:
- ФИО;
- Регистрационный номер;
- Адрес;
- Дата рождения;
- № телефона;
4.3 Требования к видам обеспечения
Требования не предъявляются.
4.3.1 Требования к математическому обеспечению системы
Требования не предъявляются.
4.3.2 Требования к информационному обеспечению системы
Требования не предъявляются.
4.3.3 Требования к лингвистическому обеспечению системы
Требования не предъявляются.
4.3.4 Требования к программному обеспечению системы
Требования не предъявляются.
4.3.5 Требования к техническому обеспечению
В состав комплекса должны следующие технические средства:
– Серверы БД;
– ПК пользователей;
– ПК администраторов.
Серверы БД должны быть объединены в отказоустойчивый кластер. Серверы приложений должны образовывать кластер с балансировкой нагрузки.
Серверы БД, серверы приложений и сервер системы формирования отчетности должны быть объединены одной локальной сетью, с пропускной способностью не менее 100 Мбит.
Требования к техническим характеристикам серверов БД:
– Процессор – 2 х Intel Xeon 3 ГГц;
– Объем оперативной памяти – 16 Гб;
– Дисковая подсистема – 4 х 146 Гб;
– Устройство чтения компакт-дисков (DVD-ROM);
– Сетевой адаптер – 100 Мбит.
Требования к техническим характеристикам ПК пользователя и ПК администратора:
– Процессор – Intel Pentium 1.5 ГГц;
– Объем оперативной памяти – 256 Мб;
– Дисковая подсистема – 40 Гб;
– Устройство чтения компакт-дисков (DVD-ROM);
– Сетевой адаптер – 100 Мбит.
Требования к техническим характеристикам ПК пользователя и ПК администратора:
– Процессор – Intel Pentium 1.5 ГГц;
– Объем оперативной памяти – 256 Мб;
– Дисковая подсистема – 40 Гб;
– Устройство чтения компакт-дисков (DVD-ROM);
– Сетевой адаптер – 100 Мбит.
4.3.6 Требования к метрологическому обеспечению
Требования не предъявляются.
4.3.7 Требования к организационному обеспечению
Требования не предъявляются.
4.3.8 Требования к методическому обеспечению
В состав нормативно-правого и методического обеспечения системы должны входить следующие законодательные акты, стандарты и нормативы:
- Медицинские нормы
- Медицинские предписания
5 Состав и содержание работ по созданию (развитию) системы
| Этапы выполнения курсового проекта |
| Выдача заданий |
| Анализ предметной области |
| Концептуальное проектирование информационной системы |
| Даталогическое проектирование информационной системы |
| Физическое проектирование информационной системы |
| Создание запросов на языке SQL |
| Разработка интерфейса пользователя |
| Тестирование и отладка |
| Разработка руководства пользователя |
| Оформление теоретической части |
| Защита проекта |
6 Порядок приёмки и контроля системы
6.1 Виды, состав, объем и методы испытаний системы
Для защиты курсовой работы материалы отчета предоставляются в распечатанном виде и в виде демонстрационных материалов на накопителе электронных данных – дискете, флеш-накопителе данных.
Работа информационной системы при защите курсовой работы демонстрируется на компьютере на контрольных примерах.
7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
Требования не предъявляются
8 Требования к документированию
Для системы на различных стадиях создания должны быть выпущены следующие документы из числа предусмотренных в ГОСТ 34.201–89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании первой очереди АИС «Больница» приведены в таблице:
| Наименование документа | Код документа | Часть проекта |
| Техническое задание | ТЗ | Предпроектное исследование |
| Инструкция пользователя | ИП | Рабочее проектирование |
9 ИСТОЧНИКИ
1. Гагарина Л.Г., Киселев Д.В., Федотова Е.Л. Разработка и эксплуатация автоматизированных информационных систем: учебное пособие.-М.: ИД «Форум»: ИНФРА-М, 2007. – 384 с.
2. Голицына О.Л., Максимов Н.В., Попов И.И. Базы данных: учеб. Пособие. – М.: «Форум»: ИНФРА-М, 2007.-400 с.
3. Фуфаев Э.В., Фуфаев Д.Э. Базы данных: учебное пособие для студ. сред. проф. образования. – М.: Издательский центр «Академия», 2008.-320 с.
4. Ю. Избачков, В. Петров, А. Васильев, И. Телина Информационные системы 3-е издание. - СПб.: Питер, 2010. – 544 с.
5. Грекул В. И.; Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем : курс лекций: учебное пособие. М.: Интернет-Ун-т Информ. технологий, 2005
6. http://www.citforum.ru/ - форум информационных технологий.
7. http://www.intuit.ru/ -Интернет-Университет Информационных Технологий.
8. http://teachpro.ru/course2d.aspx?idc=250 – обучающий видеокурс по системе MS Access 2007.
9. http://www.mstu.edu.ru/education/materials/zelenkov/toc.html - электронный учебник по базам данных.
10. http://www.rugost.com/ - Сайт содержит ГОСТы, примеры разработанных документов по ГОСТ (ТЗ, ТП,РД), шаблоны документов по ГОСТ.
1.2 Техническое проектирование
1.2.1 Концептуальное проектирование
Концептуальное проектирование - сбор, анализ и редактирование требований к данным.
Для этого осуществляются следующие мероприятия:
обследование предметной области, изучение ее информационной структуры
выявление всех фрагментов, каждый из которых харакетризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами
моделирование и интеграция всех представлений
По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели "сущность-связь".
Рисунок 2: ER-диаграмма
Сущности:
1.
Врачи:
· ФИО
· № паспорта врача
· Специализация
· Дата рождения
· Заслуги
2.
Приёмы:
· № паспорта врача
· Регистрационный номер
· Дата приёма
· № приёма
3.
Курсы лечения
· № курса
· Регистрационный номер
· Описание курса
· № приёма
4.
Рег. Карта
· ФИО
· Регистрационный номер
· Адрес
· Дата рождения
· № телефона
· Группа крови
· Страховая компания
· № страховки
5.
Пациенты
· ФИО
· Регистрационный номер
· Адрес
· Дата рождения
· № телефона
1.2.2 Даталогическое проектирование.
Реляционная модель данных организует и представляет данные в виде таблиц или реляций.
Реляционная схема базы данных – это схема или список, содержащий имена реляционных таблиц, имена атрибутов, ключевые атрибуты и внешние ключи.
Таблица Врачи:
| Атрибут | Тип данных | Домен | Ограничения |
| ФИО | Текстовый | Список фамилий | NOT NULL |
| № паспорта врача | Числовой | Номера паспортов | Первичный ключ |
| Специализация | Текстовый | Дерматолог; Хирург; Окулист; Лор; Невропатолог; | NOT NULL |
| Дата рождения | Дата, время | даты | NOT NULL |
| Заслуги | Текстовый | Список заслуг | NOT NULL |
Таблица Приёмы:
| Атрибут | Тип данных | Домен | Ограничения |
| Регистрационный номер | Числовой | Список регистрационных номеров | NOT NULL |
| Дата приёма | Дата | Даты | NOT NULL |
| № приёма | Числовой | Номера приёмов | Первичный ключ |
| № паспорта врача | Числовой | Список номеров паспортов | NOT NULL |
Таблица Курсы лечения
| Атрибут | Тип данных | Домен | Ограничения |
| Регистрационный номер | Числовой | Список регистрационных номеров | NOT NULL |
| № курса | Числовой | Номера курсов | Первичный ключ |
| № приёма | Числовой | Номера приёмов | Внешний ключ |
| Описание курса | Текстовый | Описания курса лечения | NOT NULL |
Таблица Рег. карта:
| Атрибут | Тип данных | Домен | Ограничения |
| ФИО | Текстовый | Список фамилий | NOT NULL |
| Регистрационный номер | Числовой | Список регистрационных номеров | Первичный ключ |
| Адрес | Текстовый | Список адресов | NOT NULL |
| Дата рождения | Дата, время | Даты | NOT NULL |
| № телефона | Числовой | Номера телефонов | NOT NULL |
| Группа крови | Текстовый | Группы крови | NOT NULL |
| Страховая компания | Текстовый | Список страховых компаний | NOT NULL |
| № страховки | Числовой | Номера страховок | NOT NULL |
Таблица Пациенты:
| Атрибут | Тип данных | Домен | Ограничения |
| ФИО | Текстовый | Список фамилий | NOT NULL |
| Регистрационный номер | Числовой | Список регистрационных номеров | Первичный ключ |
| Адрес | Текстовый | Список адресов | NOT NULL |
| Дата рождения | Числовой | Даты | NOT NULL |
| № телефона | Числовой | Номера телефонов | NOT NULL |
1.2.3 Физическое проектирование.
Sql запросы на создание таблицCREATE TABLE:
CREATE
TABLE Врачи (ФИО char (50) NOT NULL, № паспорта integer NOT NULL primary key, Специализация char (50) NOT NULL , Дата рождения Data/time, Заслуги char (50) NOT NULL);
CREATE
TABLE Приёмы (Регистрационный номер integer NOT NULL, Дата приёма Date/time NOT NULL, № приёма integer NOT NULL primary key , № паспорта врача integer NOT NULL);
CREATE
TABLE Курсы лечения (Регистрационный номер integer NOT NULL, № курса integer NOT NULL primary key, № приёма integer NOT NULL Foreign key, Описание курса char (50) NOT NULL);
CREATE
TABLE Рег. карта (ФИО char (50) NOT NULL, Регистрационный номер integer NOT NULL primary key , Адрес char (50) NOT NULL, Дата рождения Date/time NOT NULL, № телефона integer NOT NULL, Группа крови char (50) NOT NULL, Страховая компания char (50) NOT NULL, № страховки integer NOT NULL);
CREATE
TABLE Пациенты (ФИО char (50) NOT NULL, Регистрационный номер integer NOT NULL primary key, Адрес char (50) NOT NULL , Дата рождения Data/time, № телефона integer NOT NULL);
2. Практическая часть
2.1
Программно-информационное ядро базы
Таблица «Врачи»
Таблица «Приёмы»
Таблица «Рег. карта»
Таблица «Пациенты»
Схема данных:
2.2 Описание метода доступа к базе данных
Метод доступа
ADO
.
Объекты данных ActiveX (ActiveX Data Objects, или ADO) — это новейший метод доступа к данным .
ADO обеспечивает средства, с помощью которых программа получает доступ к базе данных. Объекты ADO подключаются к базе данных посредством провайдера OLE DB.
OLE DB представляет собой новый, разработанный Microsoft, низкоуровневый интерфейс, обеспечивающий доступ к множеству различных типов данных.
Провайдер OLE DB предоставляет доступ объектам ADO к этим базам данным. В свою очередь, объекты ADO позволяют подключаться к данным из прикладных программ.
Специализированные элементы управления данными (DataGrid и ADO Data). С помощью элемента управления Data можно элементарно подключиться к базам данным: достаточно настроить несколько его свойств и "связать" с ним некоторые другие элементы управления, которые будут реально отображать информацию.
Все используемые в программе данные поступают от некоторого источника данных, который может представлять собой любую базу данных— в нашем случае Microsoft Access.
Существует множество различных систем баз данных, и подключиться можно практически ко всем. Технология ODBC представляет собой одно из наиболее распространенных средств подключения к самым различным источникам данных.
ADO Data содержит следующие вкладки:
General. Определяет способ подключения элемента управления ADO Data к базе данных.
RecordSource. Определяет набор записей, который элемент управления ADO Data должен получить из источника данных. Здесь можно указать имя таблицы (или хранимой процедуры) либо SQL-запрос.
Color и Font. Определяет внешний вид элемента управления ADO Data.
2.3 Клиентское программное обеспечение
2.3.1 Программные модули
Запросы к БД:
1.поиск по специализации врача:
procedure TForm1.Button4Click(Sender: TObject);
begin
Form7.ShowModal;
end;
2.поиск по группе крови пациента:
procedure TForm1.Button5Click(Sender: TObject);
begin
Form8.ShowModal;
end;
3.поиск по страховой компании:
procedure TForm1.Button6Click(Sender: TObject);
begin
Form9.ShowModal;
end;
2.3.2
Интерфейс
программы
Рисунок 3 – Главная форма
Рисунок 4 - Таблица: Врачи
Рисунок 5 - Таблица: Пациенты
Рисунок 6 - Таблица: Приёмы
Рисунок 7 - Таблица: Курсы лечения
Рисунок 8 - Таблица: Регистрационная карта
Рисунок 9 – Запрос: Поиск врачей по специализации
Рисунок 10 - Запрос: Поиск пациентов по группе крови
Рисунок 11Запрос: Поиск пациентов по страховой компании
Рисунок 12 - Отчёт: Отчёт о текущих врачах
Рисунок 13 - Отчёт: Отчёт о ожидающих пациентах
2.4 Справочная система
При помощи кнопки Справка можно узнать информацию о Delphi:
Delphi— язык программирования, который используется в одноимённой среде разработки. Сначала язык назывался Object Pascal.[2] Начиная со среды разработки Delphi 7.0[3], в официальных документах Borland стала использовать название Delphi для обозначения языка Object Pascal.
Delphi — результат развития языка Турбо Паскаль, который, в свою очередь, развился из языка Паскаль. Паскаль был полностью процедурным языком, Турбо Паскаль, начиная с версии 5.5, добавил в Object Pascal — динамическую идентификацию типа данных с возможностью доступа к метаданным классов (то есть к описанию классов и их членов) в компилируемом коде.
2.5 Инструкция для пользователя.
1. Перечень эксплуатационной документации:
Перечень эксплуатационных документов, с которым необходимо ознакомиться:
- БД "Больница";
2. Подготовка к работе
2.1 Состав дистрибутива
В состав дистрибутива БД "Больница" входит:
- Клиентская часть Windows приложения БД "Больница";
2.2 Запуск системы
1. Для того, чтобы запустить БД "Больница", откройте папку, в которую была сохранена программа, и запустите файл Рекламная фирма.
2. В открывшемся окне вы увидите главную кнопочную форму.
2.3 Проверка работоспособности системы
Программное обеспечение работоспособно, если в результате действий пользователя, изложенных в п.п.2.2, на экране монитора отобразилось главное окно клиентского приложения без выдачи пользователю сообщений о сбое в работе.
3. Описание операций
3.1 Наименование операции
Просмотр справочной информации, составление договора.
3.2 Условия выполнения операции
Приложение запущено, успешно функционирует, не выполняет никакх операций, блокирущих доступ к пунктам меню.
3.3 Подготовительные действия
Отсутствуют.
3.4 Основные действия
Работа с кнопочной формой
3.6 Ресурсы, расходуемые на операцию
Отсутствуют.
4. Аварийные ситуации. Восстановление базы данных
При сбое в работе аппаратуры восстановление нормальной работы системы должно производиться после:
- перезагрузки операционной системы;
- запуска исполняемого файла системы;
При ошибках в работе аппаратных средств (кроме носителей данных и программ) восстановление функции системы возлагается на ОС.
При ошибках, связанных с программным обеспечением (ОС и драйверы устройств), восстановление работоспособности возлагается на ОС.
При неверных действиях пользователей, неверных форматах или недопустимых значениях входных данных, система выдает пользователю соответствующие сообщения, после чего возвращается в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных.
5. Рекомендации по освоению
Для успешного освоения приложения БД "Больница" необходимо иметь навыки работы с ПК.
Заключение:
Актуальность данной курсовой работы заключается в том, что сейчас в XXI веке все автоматизируется. И в настоящее время никто не может представить свою работу без компьютера.
Современные информационные технологии с их стремительно растущим потенциалом и быстро снижающимися издержками открывают большие возможности для новых форм организации труда и занятости в рамках как отдельных корпораций, так и общества в целом. Спектр таких возможностей значительно расширяется - нововведения воздействуют на все сферы жизни людей, семью, образование, работу, географические границы человеческих общностей и т. д. Сегодня информационные технологии могут внести решающий вклад в укрепление взаимосвязи между ростом производительности труда, объемов производства, инвестиций и занятости. Новые виды услуг, распространяющиеся по сетям, в состоянии создать немало рабочих мест, что подтверждает практика последних лет.
В данной курсовой работы было произведено предпроектное исследование, произведено техническое проектирование, в котором была разработана ER-диаграмма, реляционная модель БД.
Результатом явилась БД «Больница», предназначенная для комплексного информационного обеспечения процессов «Больницы».
Список используемой литературы
1. Гагарина Л.Г., Киселев Д.В., Федотова Е.Л. Разработка и эксплуатация автоматизированных информационных систем: учебное пособие.-М.: ИД «Форум»: ИНФРА-М, 2007. – 384 с.
2. Голицына О.Л., Максимов Н.В., Попов И.И. Базы данных: учеб. Пособие. – М.: «Форум»: ИНФРА-М, 2007.-400 с.
3. Фуфаев Э.В., Фуфаев Д.Э. Базы данных: учебное пособие для студ. сред. проф. образования. – М.: Издательский центр «Академия», 2008.-320 с.4.Ю. Избачков, В. Петров, А. Васильев, И. Телина Информационные системы 3-е издание. - СПб.: Питер, 2010. – 544 с.
4. Грекул В. И.; Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем : курс лекций: учебное пособие. М.: Интернет-Ун-т Информ. технологий, 2005
5. http://www.citforum.ru/ - форум информационных технологий.
6. http://www.intuit.ru/ -Интернет-Университет Информационных Технологий.
7. http://teachpro.ru/course2d.aspx?idc=250 – обучающий видеокурс по системе MS Access 2007.
8. http://www.mstu.edu.ru/education/materials/zelenkov/toc.html - электронный учебник по базам данных.
9. http://www.rugost.com/ - Сайт содержит ГОСТы, примеры разработанных документов по ГОСТ (ТЗ, ТП,РД), шаблоны документов по ГОСТ.
Федеральное государственное образовательное учреждение
среднего профессионального образования
«Канский технологический колледж»
КУРСОВОЙ ПРОЕКТ
Дисциплина: Разработка и эксплуатация автоматизированных информационных систем
Тема:
Создание автоматизированной информационной системы «Больница»
Специальность 230103.51
Группа АВ-41
Демянюк Н.В.
Содержание
Введение
1. Теоретическая часть…………………………………………………...
1.1 Предпроектное исследование……………………………………….
1.1.1 Анализ предметной области…………………………………….....
1.1.2 Техническое задание……………………………………………….
1.2 Техническое проектирование……………………………………….
1.2.1 Концептуальное проектирование………………………………....
1.2.2 Даталогическое проектирование………………………………….
1.2.3 Физическое проектирование……………………………………....
1.2.4 Технический проект………………………………………………..
2. Практическая часть……………………………………………………
2.1 Программно-информационное ядро……………………………......
2.2 Описание метода доступа к базе данных…………………………..
2.3 Клиентское программное обеспечение…………………………….
2.3.1 Программные модули……………………………………………...
2.3.2 Интерфейс программы……………………………………………..
2.4 Справочная система………………………………………………......
2.5 Инструкции для пользователя……………………………………….
Заключение
Список используемой литературы
