Детский туберкулезный диспансер

МИНИСТЕРСТВО  ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ                   ФЕДЕРАЦИИ



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

 

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ

ТОМСКИЙ ПОЛИТЕХНИЧЕСКИЙ  УНИВЕРСИТЕТ»

_____________________________________________________________

 

Институт  - кибернетики

Специальность - прикладная информатика (в экономике)

Кафедра  - ОСУ

 

 

 

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

по  дисциплине “Разработка и стандартизация ПСИИТ”

на  тему

Детский туберкулезный диспансер.

 

 

 

Студентка  гр.   8592           ________________ А.О. Михайлова

          (подпись  студента)  

 

Студент     гр.   8592           ________________ Ф.Ф. Нечепал

          (подпись  студента)

 

 

 

Преподаватель               ________________ Д. Ю. Кузнецов

                                             (подпись руководителя)

 

 

(Оценка)     (Подпись)

__________

 

Томск 2013г.

 

Оглавление

ВВЕДЕНИЕ 3

ГЛАВА 1. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К СИСТЕМЕ 4

1.1. Техническое задание 4

1.1.1. ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ 4

1.1.2. НАЗНАЧЕНИЕ РАЗРАБОТКИ 4

1.1.3.   ТРЕБОВАНИЯ К ПРОГРАММНОМУ ПРОДУКТУ 5

1. Требования к функциональным характеристикам 5

2. Требования к надежности 7

3. Условия эксплуатации 8

4. Требования к составу и параметрам технических средств 8

1.1.4. ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ 9

1.1.5. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ (календарный план) 10

ГЛАВА 2. РАЗРАБОТКА ПРОГРАММНОГО ПРОДУКТА. 12

2.1. Диаграмма вариантов использования. 12

2.2 Диаграммы последовательностей 15

2.3. Диаграмма классов 17

2.4. Диаграмма развертывания 20

ГЛАВА 3. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ 21

Заключение 27

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 28

 

 

ВВЕДЕНИЕ

Целью данной курсовой работы являлась разработка объектно-ориентированной  системы, позволяющей автоматизировать работу детского туберкулёзного центра. Данная система будет обеспечивать хранение и обработку данных о пациентах (т.е.  ведение карточки пациента),  о сотрудниках, о хранящихся на складе товаров, а также создание отчетов. Все данные о товарах могут просматриваться и редактироваться в соответствии с правами доступа пользователя в системе.

Написание программы  реализуется среде Microsoft Visual Studio 2010, БД была создана Microsoft Accesses 2010 , диаграммы в Rational Rose.

В распоряжение проектировщика системы Rational Rose предоставляет следующие типы диаграмм, последовательное создание которых позволяет получить полное представление о всей проектируемой системе и об отдельных ее компонентах :

  • Диаграмма вариантов использования;
  • Диаграмма последовательности;
  • Диаграмма классов;
  • Диаграмма развертывания;

 

ГЛАВА 1. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К СИСТЕМЕ

    1.   Техническое задание

Настоящее техническое задание (ТЗ) предназначено для разработки проектной  документации ПО, автоматизирующего  систему организации детского туберкулезного диспансера.

Разрабатываемое ПО должно иметь клиент-серверную  архитектуру. На сервере должна располагаться база данных (БД).

Готовый продукт должен предоставлять  возможность директору – получать обобщенные документированные отчеты, а сотрудники могут добавлять и изменять данные по деятельности.

      1. ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ

Разработка данного  программного продукта ведется на основании  договора № 2611 от 8 февраля 2013 г. заключенного с детским туберкулезным диспансером.

      1. НАЗНАЧЕНИЕ  РАЗРАБОТКИ

Программный продукт предназначен для автоматизации деятельности организации по предоставлению:

    • услуг врачей, оказывающих медицинскую помощь больным детям;
    • санаторного обслуживания.

 Заказчик получает программный  продукт, который обеспечивает  возможность автоматизации работы  организации: создание и ведение  баз данных, автоматический расчет заработной платы за определенный период времени, вывод отчетов, просмотр информации о сотрудниках и услугах, составления индивидуальных проектов. Программный продукт предоставляет возможности разделения пользователей по ролям: «Глав. врач», «Врач», «Бухгалтер», «Администратор», «Шеф повар», «Зав. склада», «Отдел кадров», «Регистратура» в зависимости от типа пользователя ограничиваются его права и возможности.

Заказчик получает программный  продукт, который обеспечивает следующие  возможности:

    1. Контроль наличия продуктов питания и медикаментов на складе;
    2. Создание, изменение данных о поставщиках;
    3. Ведение учета пациентов;
    4. Создание и хранение в БД назначений лекарств врачом;
    5. Учет расходов;
    6. Создание личных карт пациентов;
    7. Создание, изменение данных о сотрудниках;
    8. Формирование отчетов.

1.1.3.  ТРЕБОВАНИЯ К ПРОГРАММНОМУ ПРОДУКТУ

1. Требования к функциональным  характеристикам

Программный продукт состоит из  подсистем:

Подсистема работы с сотрудниками:

Данная подсистема предоставляет  возможность внесения новых и  редактирования существующих данных отделом кадров. Так же осуществляется распределение сотрудников по должностям. Далее информация с ФИО и должностью передаться администратору для выдачи логина и пароля.

Входные данные:

ФИО сотрудников, паспортные данные, контактный номер, дата найма, адрес проживания, должность, квалификация,  оклад.

Выходные данные:

Обобщенные данные о  сотрудниках, стаж, зарплата за последний  отчетный период.

Подсистема регистрации:

Подсистема реализует  возможность регистрации пользователей  информационной системы для их последующей  авторизации для разделения их полномочий. Регистрация осуществляется через администратора системы.

Входные данные:

Данные сотрудника: ФИО, должность.

Выходные данные:

Зарегистрированный сотрудник, который получает: логин – пароль, с помощью которых имеет особый доступ к системе для работы с ней.

Подсистема авторизации:

Подсистема реализует  проверку достоверности данных пользователя, то есть осуществляет проверку соответствия логина и пароля пользователя.

Входные данные:

Данные пользователя: логин, пароль.

Выходные данные:

Ответная реакция системы: соответствие пары: логин, пароль –  вход в систему по учётной записи, либо несоответствие логина и пароля, что приводит к выдаче пользователю соответствующего сообщения.

Подсистема работы склада:

Предназначена для осуществления  заведующим склада контроля за поступлением новых продуктов питания, медикаментов  и наличием их на складе, выдача товара и формирование заказа.

Входные данные:

О товарах: наименование товара, количество, вид товара, дата прихода  на склад, срок годности.

Выходные данные:

О товарах: Отчет о наполненности склада.

 

 

Подсистема бухгалтерии:

Подсистема позволяет  формировать отчёты: «Пациенты», «Отчет по выдаче медикаментов», «Отчет по выдаче продуктов питания», «Отчет по заработной плате».

Входные данные:

  • Информация о пациентах: номер пациента, диагноз, возраст, лечение, отчётный период.
  • Информация о расходах на медикаменты: отчётный период;
  • Информация о расходах продуктов питания: отчётный период;
  • Информация о сотрудниках: ФИО сотрудника, должность, стаж, отчетный период, оклад;

Выходные данные:

О сотрудниках: премия.

Готовые отчеты: «Пациенты», «Отчет по выдаче медикаментов», «Отчет по выдаче продуктов питания», «Отчет по заработной плате».

Первый показывает, информацию о пациентах, поставленный диагноз, назначенное лечение.

Во втором и третьем отображаются расходы за определённый период.

Четвертый показывает основную информацию по каждому сотруднику за определённый период.

Подсистема работы с пациентами:

Данная подсистема предоставляет  возможность внесения новых и  редактирования старых данных по пациентам.

Входные данные:

ФИО пациента, свидетельство  о рождении, страховой полис,  контактный номер, дата начала лечения, адрес проживания, симптомы, диагноз.

Выходные данные:

Создание карточки пациента, назначенное лечение.

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

2. Требования к надежности

Надежное функционирование программы должно соответствовать  всем требованиям заказчика.

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

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

3. Условия эксплуатации

Для эксплуатации данного программного продукта пользователь должен пройти предварительную подготовку.

В случае возникновения технических проблем, привлекаются сторонние специалисты  в области программирования БД в  PHP/SQL.

4. Требования к составу и параметрам  технических средств

Для успешного функционирования системы  необходим сервер  и 7 персональных компьютера, которые должны быть объединены в локальную сеть. Параметры компьютеров должны удовлетворять следующим требованиям:

  • Рабочая станция:
    • Компьютер на базе процессора Intel (не ниже 2 GHz);
    • Оперативная память не менее 2048 Mb DDR3; 
    • Свободная память на жестком диске  не менее 250 Gb;
    • Видеопамять не менее 512 Mb;
    • Наличие сетевого адаптера.
    • Пропускная способность сети не менее 10 Мбит/с.
  • Сервер (для работы с единой базой данных)
    • Компьютер  на базе процессора Intel (не ниже 2 GHz);
    • Оперативная память не менее 8 Gb DDR3; 
    • 2 жестких диска (Объемом по 2048 GB);
    • Наличие сетевого адаптера;
    • RAID5- контроллер;
    • Устройство бесперебойного питания компьютера (UPS).
    • Вентиляторный модуль;

Для работы необходимы ПК, имеющие ОС- семейства Windows.

1.1.4. ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

Разработчик предоставляет:

  • системную документацию;
  • описание логической структуры базы данных;
  • руководство пользователя «Глав. Врач»;

 

 

 

 

1.1.5. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ (календарный план)

Этап

Начало этапа

Окончание этапа

Ожидаемые результаты

Ответственное лицо

Исследование организации

01.03.2013

10.03.2013

Представление об  функционировании организации, Диаграмма вариантов использования

Нечепал Ф.Ф., Михайлова А.О

Разработка технического задания

10.03. 2013

25.03.2013

Техническое задание

Нечепал Ф.Ф., Михайлова А.О

Проектирование ПО. Разработка структуры БД

27.03.2013

09.04.2013

Диаграмма классов. Логическая структура  базы данных

Нечепал Ф.Ф., Михайлова А.О

Разработка подсистемы, отвечающей за вывод информации из БД

28.03.2013

1.04.2013

Диаграммы последовательностей, Подсистема, отвечающая за вывод информации из БД

Нечепал Ф.Ф., Михайлова А.О

Разработка подсистемы отвечающей за управление системой

2.04.2013

5.04.2013

Подсистема, отвечающая за управление системой

Нечепал Ф.Ф., Михайлова А.О

Соединение подсистем и создание первой версии программы

7.04.2013

10.04.2013

Первая версия программы.

Нечепал Ф.Ф., Михайлова А.О

Тестирование и отладка

12.04.2013

15.04.2013

Функционирование программного продукта

Нечепал Ф.Ф., Михайлова А.О

Оформление технической документации

15.04.2013

16.04.2013

Техническая документация

Нечепал Ф.Ф., Михайлова А.О

Пробная эксплуатация программного продукта на аппаратной базе заказчика

16.04.2013

18.04.2013

Функционирование программного продукта на аппаратной базе заказчика

Нечепал Ф.Ф., Михайлова А.О

Внедрение и обучение персонала

18.04.2013

21.04.2013

Программа внедрена, персонал обучен.

Нечепал Ф.Ф., Михайлова А.О

   

 

 

ГЛАВА 2. РАЗРАБОТКА ПРОГРАММНОГО ПРОДУКТА.

2.1. Диаграмма вариантов использования.

Диаграммы вариантов использования  описывают функциональное назначение системы или то, что система  должна делать. Разработка диаграммы  преследует следующие цели:

  • определить общие границы и контекст моделируемой предметной области;
  • сформулировать общие требования к функциональному поведению проектируемой системы;
  • разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей;
  • подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.

Суть диаграммы вариантов  использования состоит в следующем. Проектируемая система представляется в виде множества сущностей или  актеров, взаимодействующих с системой с помощью вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. Вариант использования служит для описания сервисов, которые система предоставляет актеру. Диаграмма вариантов использования может дополняться пояснительным текстом, который раскрывает смысл или семантику составляющих ее компонентов.

 

Действующие лица:

Врач - лицо, отвечающее за создание карточки пациента, постановки диагноза, назначения лечения и самого лечения пациента.

Регистратура - отвечает за регистрацию пациентов.

Администратор - лицо, которое администрирует работу серверной части и базы данных, а также работу с учетными записями пользователей.

Бухгалтер -  лицо, которое рассчитывает и заносит в БД информацию о заработной плате каждого сотрудника, в соответствии с отработанными часами и видом работы, а также формирует отчеты.

Глав. врач – лицо, которое выполняет функции директора диспансера, контролирует работоспособность организации, просматривает отчетность, занимается лечением пациента.

Отдел кадров - занимается обработкой данных связанных с сотрудниками и внесения и в БД

Зав. склада - лицо, которое осуществляет контроль за поступлением новых продуктов питания, медикаментов  и наличием их на складе, выдачу товара и формирование заказа.

 

 

Рис. 1. Диаграмма вариантов использования 

2.2 Диаграммы последовательностей

Взаимодействие объектов в системе  происходит посредством приема и  передачи сообщений объектами-клиентами  и обработки этих сообщений объектами-серверами. При этом в разных ситуациях одни и те же объекты могут выступать  и в качестве клиентов, и в качестве серверов.

Данный тип диаграмм позволяет  отразить последовательность передачи сообщений между объектами.

Этот тип диаграммы не акцентирует  внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений.

 

Рис 2.Диаграмма авторизация

Рис 3.Диаграмма заполнение карточки пациента

Рис 4. Диаграмма информации о сотруднике.

 

2.3. Диаграмма классов

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.

Диаграмма классов представляет собой  некоторый граф, вершинами которого являются элементы типа "классификатор", которые связаны различными типами структурных отношений. Следует  заметить, что диаграмма классов  может также содержать интерфейсы, пакеты, отношения и даже отдельные  экземпляры, такие как объекты  и связи. Когда говорят о данной диаграмме, имеют в виду статическую  структурную модель проектируемой  системы. Поэтому диаграмму классов принято считать графическим представленном таких структурных взаимосвязей логической модели системы, которые не зависят или инвариантны от времени.

Диаграмма классов состоит из множества  элементов, которые в совокупности отражают декларативные знания о  предметной области. Эти знания интерпретируются в базовых понятиях языка UML, таких  как классы, интерфейсы и отношения  между ними и их составляющими  компонентами. При этом отдельные  компоненты этой диаграммы могут  образовывать пакеты для представления  более общей модели системы. Если диаграмма классов является частью некоторого пакета, то ее компоненты должны соответствовать элементам этого  пакета, включая возможные ссылки на элементы из других пакетов.

 

Рис 5. Диаграмма классов

 

 

2.4. Диаграмма развертывания

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

Диаграммы развертывания  используются для моделирования  статического вида системы с точки  зрения развертывания. В основном под  этим понимается моделирование топологии  аппаратных средств, на которых выполняется  система. По существу, диаграммы развертывания - это просто диаграммы классов, сосредоточенные  на системных узлах.

Диаграммы развертывания  важны не только для визуализации, специфицирования и документирования встроенных, клиент-серверных и распределенных систем, но и для управления исполняемыми системами с использованием прямого  и обратного проектирования.

Рис 6. Диаграмма развертывания

ГЛАВА 3. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

Приложение выполнено  на языке программирования C#. Среда разработки – «Microsoft Visual Studio 2010».

При запуске приложение появляется форма авторизации. Диалог авторизации требует ввод логина и пароля:

Рис 7. Форма  авторизации

При неправильном вводе данных возникает  ошибка:

Рис 8. Сообщение  об ошибке

 

Войдя в систему под  правами Глав. Врача появляется форма, в которой располагаются вкладки: сотрудники и карточка пациента.

Также на форме расположено  две  кнопки: поиск и выход на главную страницу (авторизация).

Рис 9. Форма для Глав. Врача, вкладка «Сотрудники».

На данной вкладке «Сотрудники» можно производить поиск данных по каждому из полей, редактировать данные на этой вкладке нельзя, так как Глав. Врач не имеет прав доступа для редактирования, а может лишь просматривать информацию. Также есть кнопка «На главную», при нажатии на нее,  возможно вернуться на форму авторизации.

Рис 9. Форма для Глав. Врача, вкладка «Карточка пациента».

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

При нажатии на кнопку «Показать отчёты», появляется форма, содержащая четыре отчёта «Пациенты», «Отчет по выдаче медикаментов», «Отчет по выдаче продуктов питания», и «Отчет по заработной плате».

Рис 10. Форма выбора отчета.

 

При нажатии на кнопку «Перейти» появляется форма, содержащая основную информацию о выдаче товаров, о начислении заработной платы сотрудникам, а также информацию о пациентах.

Рис 10. Форма отчетов.

 

Заключение

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

Написание программы было реализовано в среде Microsoft Visual Studio 2010, БД была создана Microsoft Accesses 2010 , диаграммы в Rational Rose.

В распоряжение проектировщика системы Rational Rose предоставляет следующие типы диаграмм, последовательное создание которых позволяет получить полное представление о всей проектируемой системе и об отдельных ее компонентах :

  • Диаграмма вариантов использования;
  • Диаграмма последовательности;
  • Диаграмма классов;
  • Диаграмма развертывания;
  • Диаграмма компонентов.

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

 

 

 

СПИСОК  ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

    1. Кузнецов  Д. Ю. Курс лекций по дисциплине: «Разработка и стандартизация программных систем и информационных технологий» - 2012 г.
    2. http://www.caseclub.ru/ - UML диаграммы в Rational Rose

 


Детский туберкулезный диспансер