Автоматизированная информационная система учета пациентов на примере ОАО "Авитек"

Дипломная работа - Компьютеры, программирование

Другие дипломы по предмету Компьютеры, программирование

 

2. Анализ требований к системе

 

Постановка задачи

1. Разработка должна осуществляться в соответствии с основными стадиями жизненного цикла продукта с применением структурного подхода.

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

-создание новой амбулаторной карты пациента;

-учет процедур, полученных пациентом в период лечения;

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

-взаимодействие с системой расчета стоимости лечения (1С);

-печать различных отчетов.

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

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

Различным организационным уровням соответствуют четыре типа ИС:

оперативному уровню управления - системы с эксплуатационного уровня, системы уровня знаний;

тактическому уровню управления - ИС тактического управления;

стратегическому уровню управления - ИС стратегического управления.

ИС эксплуатационного уровня предназначены для автоматизации элементарных функций ОИ оперативного уровня управления компанией. Такими функциями являются: ввод информации, первичная обработка текущей информации, проведение платежей, осуществление почтовых операций. ИС эксплуатационного уровня применяются для ведения складского учета, кадрового учета, организации документооборота, ввода первичной бухгалтерской информации, оперативное планирование и т.д. Основная цель систем на этом уровне состоит в том, чтобы автоматизировать рутинные операции по воду информации и проводить потоки транзакций через организацию [4].

На эксплуатационном уровне задачи, данные и действия предопределены и высоко формализованы.

Таким образом, приведенные ранее требования к АИС для ОАО Авитек позволяют отнести ее к системам эксплуатационного уровня.

 

3. Функциональная декомпозиция системы

 

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

Декомпозиция позволяет представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой [6].

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

Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ, другими словами, первоначально необходимо определить область (Scope) моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования и когда должна быть закончена модель. При формулировании области необходимо учитывать два компонента - широту и глубину. Широта подразумевает определение границ модели - мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком Уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени - трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема "плавающей области") [2].

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

Анализ системы будем осуществлять в терминах бизнес-процессов организации с использованием методологий IDEF0, DFD, IDEF3.

Первый шаг в построении модели - это определение цели модели, т.е. ряда вопросов, на которые призвана ответить модель.

Из требований к модели, приведенных в п.2, следуют такие общие вопросы:

из каких процессов состоит деятельность регистратуры санатория;

какие данные используются при учете пациентов;

каковы общие алгоритмы обработки этих данных.

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