Размещено на http://www.allbest.ru/

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

ВЯТСКИЙ СОЦИАЛЬНО-ЭКОНОМИЧЕСКИЙ ИНСТИТУТ

Факультет информационных технологий

Кафедра информатики и вычислительной техники

Курсовая работа по дисциплине

Проектирование информационных систем

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

Киров 2011

Содержание

• Введение
• 1. Обоснование выбора инструментальных средств
• 2. Анализ требований к системе
• 3. Функциональная декомпозиция системы
• 3.1 Построение модели AS-IS
• 4. Построение ролевой диаграммы
• 5. Функционально-стоимостной анализ процессов (ABC)
• Заключение
• Библиографический список
• Приложения

Введение

В настоящее время происходит активная информатизация многих сфер человеческой деятельности, которая характеризуется внедрением и использованием автоматизированных информационных систем (АИС).

Автоматизированная информационная система (АИС) - это информационная система, в которой для обработки, хранения и извлечения данных используются программно-аппаратный комплекс. Создание и использование АИС способствует повышению эффективности производства или иной деятельности и обеспечивает наиболее высокое качество управления.

Санаторий «Авитек» - это натуропатическая клиника, где долечивают (реабилитируют) пациентов после тяжелых заболеваний сердца и сосудов, занимаются профилактикой обострений хронических заболеваний, укрепляют здоровье и продляют молодость. Это многопрофильный лечебно-оздоровительный комплекс на 165 мест [7].

На текущий момент учет пациентов (создание амбулаторной карты и ее заполнение по мере лечения пациента) ведется вручную, финансовые расчеты стоимости лечения выполняются в системе 1С. Кроме того, на базе санатория имеется специализированное оборудование для снятия различных медицинских параметров пациента (артериальное давление, пульс, частота дыхания при физических нагрузках и т.п.). Очевидно, предприятию требуется автоматизированная информационная система, обеспечивающая с одной стороны, хранение и автоматическое обновление амбулаторной карты пациента в электронном виде и с другой стороны, взаимодействующая с другими системами, применяемыми в ОАО «Авитек».

Цель работы: разработать проект автоматизированной информационной системы, обеспечивающей учет пациентов в ОАО «Авитек».

Для достижения поставленной цели должны быть решены следующие задачи:

1. Ознакомиться с методологией построения моделей в нотациях IDEF0, IDEF3 и DFD.

2. Изучить доступные инструментальные средства визуального моделирования бизнес-процессов и выбрать наиболее подходящее для разработки требуемой АИС.

3. С помощью выбранного инструмента провести моделирование деятельности по учету пациентов на ОАО «Авитек».

1. Обоснование выбора инструментальных средств

автоматизированный информационный бизнес учет

Российский рынок программного обеспечения предлагает довольно широкий спектр инструментов визуального моделирования бизнес-процессов: Rational Rose, Oracle Designer, AllFusion Process Modeler (BPWin) и AllFusion ERwin Data Modeler (ERWin), ARIS, Power Designer. За рубежом, помимо упомянутых, активно используются такие средства как Ithink Analyst, ReThink и др.

Краткая характеристика перечисленных инструментальных средств представлены в таблице 1.

Таблица 1 Перечень инструментальных средств

№	Наименование	Поставщик, официальный сайт. Основной представитель в России	Краткая характеристика
1	2	3	4
1	BPWin и ERWin	Computer Associates (ранее компания Platinum) http://www.ca.com Interface Ltd http://www.interface.ru	BPWin - инструмент визуального моделирования бизнес-процессов. ERWin - средство, используемое при моделировании и создании баз данных произвольной сложности на основе диаграмм "сущность - связь". Один из лидеров российского рынка. Локализован. Продажи, поддержка, обучение в России.
2	Oracle Designer	Компания Oracle http://www.oracle.com Представительство Oracle в России	Функциональное средство для описания предметной области. Входит в комплекс инструментальных средств Oracle9i Developer Suite по проектированию программных систем и баз данных, реализующих технологию CASE и собственную методологию разработки ИС компании Oracle - "CDM", позволяющих команде разработчиков провести проект, начиная от анализа бизнес-процессов через моделирование к генерации кода и получению прототипа, а в дальнейшем и окончательного продукта. Это средство имеет смысл использовать при ориентации на всю линейку продуктов Oracle, применяемую для проектирования, разработки и реализации сложной программной системы. Участник российского рынка. Локализован. Продажи, поддержка, обучение в России.
3	Rational Rose	IBM (ранее компания Rational Software, в настоящий момент является подразделением IBM) http://www.ibm.com Представительство IBM в России http://www.ibm.com/ru	Средство моделирования объектно-ориентированных информационных систем. Позволяет решать практически любые задачи в проектировании информационных систем: от анализа бизнес-процессов до кодогенерации на определенном языке программирования. Позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое. Один из лидеров российского рынка. Локализован. Продажи, поддержка, обучение в России.
4	ARIS	IDS Scheer AG http://www.ids-scheer.com Логика бизнеса http://www.blogic.ru	Интегрированное средство моделирования бизнес-процессов, объединяющее разнообразные методы моделирования и анализа систем. В первую очередь, это средство описания, анализа, оптимизации и документирования бизнес-процессов, чем средство проектирования ПО. Лидер на мировом рынке. Локализован. Продажи, поддержка, обучение в России.
5	Power Designer	Sybase http://www.sybase.com Sybase http://www.sybase.ru	PowerDesigner - средство моделирования бизнес-процессов, проектирования баз данных и объектного моделирования. Участник российского рынка, преследователь лидеров на мировом рынке. Поддержка, продажа, обучение в России есть. Нет информации по количеству проданных лицензий, количеству пользователей, поэтому достаточно сложно оценить распространенность в России.
6	Re-Think	Gensym http://www.gensym.com Информация по российским компаниям, представляющим данный продукт, не найдена.	Графическая объектно-ориентированная среда создания и сопровождения интеллектуальных приложений мониторинга, диагностики и управления сложными динамическими системами в реальных и моделируемых ситуациях. Один из преследователей мировых лидеров.
7	Ithink Analyst	High Performance Systems http://www.hps-inc.com Тора-центр http://www.tora-centre.ru	Пакет для ситуационного моделирования. Позволяет строить наглядные и точные модели самых сложных политических и экономических ситуаций, используя библиотеку базовых моделей и методы системной динамики. Также используется при анализе инвестиционных проектов и реинжиниринге. Один из участников мирового рынка. Пакет не распространен на российском рынке. Русского интерфейса нет. Продажа, поддержка и обучение в России осуществляется только одной компанией. Учебные материалы на русском существуют.
8	Workflow Modeler (ранее Design/IDEF)	Meta Software http://www.metasoftware.com Информация по российским компаниям, представляющим данный продукт, не найдена.	Пакет для функционального и информационного моделирования, анализа и проектирования бизнес-процессов. Используется как составная часть в некоторых известных пакетах типа CIM (Computer Integrated Manufacturing) и САЕ (Computer Aided Engineering) и принят в качестве стандарта для проектов, финансируемых американскими и европейскими спонсорами. Один из участников мирового рынка

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

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

§ распространенность продукта (количество проданных лицензий, наличие, размер и уровень деятельности пользовательской группы);

§ доступность поддержки поставщика. Такие услуги могут включать телефонную "горячую линию", техническую и консультационную поддержку через представителя поставщика в России;

§ доступность обучения. Обучение может проводиться на территории представителя поставщика в России, пользователя или где-либо в другом месте;

§ доступность материалов по продукту. Они могут включать компьютерные учебные материалы, учебные пособия, книги, статьи, информацию в Интернете, демоверсии.

Из приведенного в списка инструментальных средств более подробно рассмотрим BPWin и ERWin компании Соmputer Associates.

Computer Associates International, Inc. (CA) входит в пятерку ведущих производителей программного обеспечения, предлагая средства моделирования, резервного копирования, управления инфраструктурой предприятия (сетями, серверами и т.д.), информационной безопасности, business intelligence и т.д. Пакет BPWin основан на методологии IDEF и предназначен для функционального моделирования и анализа деятельности предприятия. Методология IDEF, являющаяся официальным федеральным стандартом США, представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель IDEF отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Возможности BPwin:

§ поддерживает сразу три стандартные нотации - IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ). Эти три основных ракурса позволяют описывать предметную область наиболее комплексно;

§ позволяет оптимизировать процедуры в компании;

§ полностью поддерживает методы расчета себестоимости по объему хозяйственной деятельности (функционально-стоимостной анализ, ABC);

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

§ интегрирован с ERwin (для моделирования БД), Paradigm Plus (для моделирования компонентов ПО) и др.;

§ интегрирован со средством имитационного моделирования Arena;

§ содержит собственный генератор отчетов;

§ позволяет эффективно манипулировать моделями - сливать и расщеплять их;

§ имеет широкий набор средств документирования моделей, проектов [5].

Таким образом, для проектирования АИС, обеспечивающей учет пациентов на ОАО «Авитек» будем использовать BPWin поскольку функциональность данного инструментального средства позволяет полностью решить поставленные задачи проектирования. Кроме того, существует достаточное количество методических материалов, позволяющих изучить данное средство визуального моделирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так как с проектируемой АИС будет работать регистратор, то целесообразно проводить рассмотрение с его точки зрения.

Обычно строится модель существующей организации работы - AS-IS (как есть). Анализ функциональной модели позволяет определить:

- наиболее слабые места;

- преимущества новых бизнес-процессов;

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

Найденные в модели недостатки можно исправить при создании модели TO-BE (как будет) - модели новой организации бизнес-процессов.

Технология проектирования ИС подразумевает сначала создание модели AS-IS, затем ее анализ и улучшение бизнес-процессов. И только на основе модели TO-BE строится модель данных, прототип и затем окончательный вариант ИС.

3.1 Построение модели AS-IS

Построение контекстной диаграммы

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой.

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

Контекстная диаграмма выполняется в нотации IDEF0 и показывает систему с точки зрения внешнего наблюдателя.

Взаимодействие работ с внешним миром и между собой описывается в виде интерфейсных дуг (стрелок).

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

Основная деятельность регистратуры санатория ОАО «Авитек» заключается в учете пациентов, поэтому контекстная диаграмма содержит единственную работу (активность) «Учет пациентов» (Приложение 1).

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

- Входные данные: данные о потенциальных пациентах, данные о доступных процедурах, биометрические данные.

- Выходные данные: данные о пациентах, предоставленные процедуры.

- Управление: инструкции и нормативные документы.

- Механизм: персонал (регистраторы, медики).

Стрелки контекстной диаграммы представлены в таблице 2.

Таблица 2 Стрелки контекстной диаграммы

Имя стрелки (Arrow Name)	Определение стрелки (Arrow Definition)	Тип стрелки (Arrow Type)
Потенциальные пациенты	Запросы информации об услугах и т.п.	Input
Доступные процедуры	Процедуры, предоставляемые санаторием	Input
Результаты обследования	Данные, полученные при обследовании пациента	Input
Инструкции и нормативные документы	Правила предоставления медицинских услуг, правила оформления документации и т.п.	Control
Персонал	Заполнение карточек учета, оказание медицинских услуг и т.д.	Mechanism
Предоставленные процедуры	Данные о процедурах, полученных пациентом за период лечения	Output

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

Поскольку мы отразили основную деятельность регистратуры санатория ОАО «Авитек» в целом, можно сказать, что контекстная диаграмма построена (Приложение 1). Это самый высокий уровень абстракции, выражающий точку зрения любого внешнего субъекта на организацию.

Детализация контекстной диаграммы

При декомпозиции контекстной диаграммы выделим четыре основные работы (активности), представленные в таблице 3.

Таблица 3 Работы диаграммы декомпозиции А0

Имя работы (Activity Name)	Определение (Definition)
Анализ возможности лечения (А1)	Информирование пациента, консультации
Новый пациент (А2)	Создание амбулаторной карты
Лечение (А3)	Обследование, процедуры, стационар
Постановка на учет (А4)	Дополнительные услуги, повторное лечение

Первой работой является «Анализ возможности лечения» (А1). Этот процесс начинается, когда потенциальный пациент интересуется возможностью пройти процедуры на базе санатория ОАО «Авитек». Если у пациента не имеется противопоказаний и среди спектра медицинских услуг санатория имеются те, которые наиболее подходят для его реабилитации, пациент поступает на лечение.

Входными данными для функции А1 являются потенциальные пациенты и доступные процедуры. Выходными данными являются сведения о пациенте. Исполнителями функции являются регистраторы.

Если пациента устраивают условия оказания медицинских услуг и их стоимость, то в базе данных должна быть создана его амбулаторная карта. Этот процесс назван «Новый пациент» (А2). Входными данными для его являются сведения о пациенте, выходными - направление на лечение. Исполнителями функции являются также регистраторы.

Центральной и самой важной активностью является «Лечение» (А3). Поскольку все лечебные процедуры должны проводиться с учетом медицинских показаний и состояния пациента, необходимо знать результаты анализов. Они могут быть как у пациента на руках (из районной поликлиники), так и получены при обследовании на базе санатория (в том числе на специализированном медицинском оборудовании). При необходимости, пациент может быть помещен на стационарное лечение сроком до 10 дней.

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

После того, как пациент закончил лечение, сведения о нем сохраняются в базе данных, чтобы при повторном обращении учитывалась его история болезни. Кроме того, в санатории могут проводиться плановые обследования или процедуры определенного профиля (для сердечнососудистых заболеваний, для заболеваний опорно-двигательной системы и т.п.). Постоянные пациенты должны извещаться об этих мероприятиях. Процесс повторного лечения может инициироваться и самим пациентом. Перечисленные услуги объединены в активность «Постановка на учет» (А4).

Входные данные для функции А3: сведения о пациентах, выходные данные: повторное лечение.

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

Создание диаграммы декомпозиции в нотации DFD

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

Потенциальный пациент может сделать запрос о том, доступна ли некоторая процедура в определенное время (например, возможна ли запись к косметологу на определенную дату/время), запрос на консультацию с врачом-специалистом или от организации может поступить запрос на стационарное лечение.

Регистратор по соответствующей базе данных проверяет, возможно ли удовлетворить запрос пациента. Если требуемое время занято, регистратор предлагает другое свободное время. И если потенциального пациента устраивают предложенные условия, то регистратор записывает его данные для дальнейшего внесения в базу данных пациентов.

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

В диаграмму DFD «Анализ возможности лечения» внесем следующие имена работ:

§ Обработка запроса на посещение процедур.

§ Обработка запроса на прием специалиста.

§ Обработка запроса на лечение в стационаре.

Для выполнения этих работ будут использоваться соответствующие хранилища данных:

§ База данных «Процедуры».

§ База данных «Специалисты».

§ База данных «Стационар».

Согласно правилам DFD граничные стрелки должны быть преобразованы во внутренние. Поэтому диаграмма будет содержать две внешние ссылки: входящую «Звонок или явка потенциального пациента» и исходящую «Запись сведений о пациенте». Эта исходящая ссылка связывает активность «Анализ возможности лечения» с активностью «Новый пациент» (Приложение 3).

Диаграмму декомпозиции активности «Новый пациент» также построим в нотации DFD. Работами здесь будут создание амбулаторной карты пациента и направление на лечение. Для создания новой карты необходимо обращение к базе данных «Пациенты». Заметим, что в эту активность не включается случай, когда пациент уже внесен в базу данных, поэтому связь с хранилищем будет односторонняя: только внесение новой записи - сведений о пациенте.

Входящей внешней ссылкой будет «Запись сведений о пациенте». Диаграмма представлена в Приложении 4.

Создание диаграммы декомпозиции в нотации IDEF3

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

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

Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы.

Для представления в нотации IDEF3 выберем активность «Лечение», поскольку она является центральным процессом, который должен быть отражен в проектируемой АИС. В зависимости от потребностей пациента лечение может проходить по различным сценариям.

При декомпозиции диаграммы А3.1 «Лечение» выделим восемь основных работ, представленные в таблице 4.

Таблица 4 Работы диаграммы декомпозиции А3.1

Имя работы (Activity Name)	Определение (Definition)
Регистрация направления	Внесение направления в соответствующую Базу данных для статистического учета
Обследование	Анализы, обследование пациента на медицинском оборудовании
Процедуры	Предоставление лечебных процедур
Прием специалиста	Консультация с врачом-специалистом
Лечение в стационаре	Госпитализация пациента
Внесение в карту пациента	Обновление информации в амбулаторной карте пациента (внесение результатов анализов, заключений специалистов, отметки о пребывании в стационаре)
Формирование списка оказанных услуг	Формирование списка услуг, оказанных данному пациенту за текущий период лечения
Передача информации в бухгалтерию	Передача списка предоставленных процедур в бухгалтерию для расчета стоимости лечения

В нотации IDEF3 единицы работы (UOW) являются центральными компонентами модели и требуют более подробного описания. Должны быть определены Объекты (Objects) и Факты (Facts), связанные с работой и Ограничения (Constrains), накладываемые на нее. Для диаграммы А3.1 данные параметры работ представлены в таблице 5.

Цикл реабилитации пациента зависит от параметров, указанных в направлении на лечение. Эти параметры определяют следующие возможные сценарии:

1. пациент сразу идет на процедуры,

2. пациент вначале проходит обследование, затем по его результатам идет на нужные процедуры;

3. после обследования пациент консультируется со специалистом;

4. пациент направляется в стационар.

Пути выполнения процессов на диаграмме отражены в виде точек ветвления (Приложение 5).

Таблица 5 Свойства UOW для работ диаграммы декомпозиции А3.1

Имя работы (Activity Name)	Свойства UOW
Регистрация направления	Объекты: Амбулаторная карта пациента
	Факты: В направлении указана программа реабилитации
	Ограничения: нет
Обследование	Объекты: Лаборатория, диагностический центр
	Факты: Пациент может иметь результаты анализов на руках.
	Ограничения: нет
Процедуры	Объекты: процедуры
	Факты: некоторые процедуры могут предоставляться без обследования (ИК-сауна, косметические и т.п.).
	Ограничения: Для некоторых типов лечебных процедур нужно специальное направление.
Прием специалиста	Объекты: Прием врача
	Факты: Для приема косметолога не требуются результаты анализов.
	Ограничения: нет
Лечение в стационаре	Объекты: стационар
	Факты: Для учета важна длительность лечения в стационаре
	Ограничения: Лечение в стационаре требует наличия анализов и направления районной поликлиники или мед. пункта предприятия
Внесение в карту пациента	Объекты: Амбулаторная карта пациента
	Факты: Должны вноситься все результаты анализов, обследований, заключения специалистов
	Ограничения: Обновление данных в амбулаторной карте должно производиться оперативно (в течение одного рабочего дня)
Формирование списка оказанных услуг	Объекты: Список оказанных услуг
	Факты: Задается период оказания услуг и из амбулаторной карты пациента экспортируется список
	Ограничения: нет
Передача информации в бухгалтерию	Объекты: Список оказанных услуг
	Факты: Предполагается экспорт данных в систему 1С
	Ограничения: нет

Создание диаграммы декомпозиции функции А4

Для полной декомпозиции функций А0 необходима декомпозиция работы А4 «Постановка на учет». Будем проводить декомпозицию в соответствии с методикой IDEF0. Работы диаграммы декомпозиции А4 представлены в таблице 6.

Таблица 6 Работы диаграммы декомпозиции А4

Имя работы (Activity Name)	Определение (Definition)
Определение группы здоровья	В соответствии с результатами анализов или пройденными процедурами, пациента относят к некоторой группе здоровья, что отражается в базе данных "Пациенты"
Извещение пациентов	Уведомление пациентов о проводимых плановых мероприятиях
Статистическая обработка	Ежемесячные отчеты о предоставленных услугах, статистика о группах пациентов и т.п.
Обращение пациента	Повторное обращение пациента

Диаграмма декомпозиции А4 представлена в Приложении 6.

3.2 Определение типов связей между функциями в модели

Определение типов связей между функциями значимо для оценки качества модели. При моделировании социально-экономических систем сложно выразить связи между элементами системы функционально (с помощью формул). Альтернативой может служить последовательная связь, отражающая причинно-следственные связи между функциями.

На диаграмме декомпозиции функции А0 «Лечение» связь функций «Новый пациент» и «Постановка на учет» коммуникационная (используются одни входные данные - «Сведения о пациенте»). Во всех остальных диаграммах построенной модели типы связей последовательные.

4. Построение ролевой диаграммы

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

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

Ролевая группа - набор ролей, выполняющих ту или иную часть бизнес-процессов. Роль - конкретная обязанность или должность в рамках ролевой группы. Ресурсы - конкретная личность, выполняющая данную обязанность (в некоторых случаях это могут быть технические средства) [3].

Поскольку моделируется очень конкретная область деятельности санатория (учет пациентов), то ролевая группа будет всего одна: санаторий, непосредственно обеспечивающий учет пациентов и прохождение ими обследования, процедур и осуществляющий лечение (Таблица 7).

Таблица 7 Ролевые группы

Название (Name)	Определение (Definition)	Важность (Importance)
Санаторий	Моделируемое подразделение	High

Ролевые группы и роли вносятся в специальные словари (словарь ролевых групп (Dictionary/Role group) и ролей (Dictionary/Role) соответственно). Заполненный словарь ролей для санатория ОАО «Авитек» представлен на рисунке 1.



Рис. 1. Словарь ролей

Полученная автоматически ролевая диаграмма представлена в Приложении 7.

5. Функционально-стоимостной анализ процессов (ABC)

BPwin предоставляет аналитику два инструмента для оценки модели -стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). ABC является широко распространенной методикой. Стоимостный анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, поскольку количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Re-engineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь), и др. в каждой из моделей AS-IS и ТО-ВЕ. Следовательно, стоимостный анализ позволяет оценить, каковы будут последствия внедрения ИС, действительно ли это приведет к повышению производительности и экономическому эффекту и к какому именно.

ABC может проводиться только тогда, когда модель работы последовательная (следует синтаксическим правилам IDEF0), корректная (отражает бизнес), полная (охватывает всю рассматриваемую область) и стабильная (проходит цикл экспертизы без изменений), другими словами, создание модели работы закончено.

ABC включает следующие основные понятия:

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

- движитель затрат - характеристики входов и управлений работы, которые влияют на то, как выполняется и как долго длится работа;

- центры затрат, которые можно трактовать как статьи расхода.

На уровне функционального блока связь IDEF0 и АВС-моделей базируется на трех принципах:

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

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

3. Стоимость или время функции, которая имеет декомпозицию, определяется как сумма стоимостей (времен) всех подфункций на данном уровне декомпозиции.

Начнем с определения центров затрат. Основной затратой при внедрении АИС по учету пациентов будет обучение специалистов регистратуры. Кроме того, требуется обеспечение доступа к базам данных, т.е. закупка сервера (как аппаратной, так и программной части).

Стоимость и продолжительность работ для диаграммы А0 «Учет пациентов» представлены в таблице 8.

Таблица 8 Стоимость и продолжительность работ на диаграмме «Учет пациентов»

Имя работы (Activity Name)	Центр затрат (Cost Center)	Сумма центра затрат (Cost Center Cost), в руб.	Продолжительность, (Duration), в днях	Частота (Frequency)
Анализ возможности лечения	Обучение специалистов	10 000	1	4
Новый пациент	Закупка сервера	150 000	2	1
Лечение	-	-	-	-
Постановка на учет	Телефонная связь	500	1	5

Поясним приведенные в таблице данные. В регистратуре работает 4 человека (2 смены по 2 человека). Обучение одного человека будет стоить 10 000 руб. и займет 1 рабочий день. Поскольку сервер баз данных будет использоваться при выполнении нескольких работ, мы его стоимость посчитаем один раз для активности «Новый пациент». Закупка сервера осуществляется один раз и его установка и настройка займет в среднем 2 дня. При реализации активности «Лечение» будет использоваться сервер баз данных: для внесения обновлений в карту пациента, для формирования и передачи отчета об оказанных услугах в бухгалтерию. Стоимость сервера уже учтена, обучение специалистов тоже проводилось на этапе Анализа возможности лечения. Таким образом, здесь затрат не будет. Для активности «Постановка на учет» центром затрат будет телефонная связь, используемая для оповещения о плановых мероприятиях санатория. В месяц проходит в среднем 5 мероприятий по различным направлениям. Извещение пациентов проводится в течении 1 дня за неделю до начала мероприятий.

Таким образом, после внесения необходимых значений параметров денежные характеристики отразились на диаграмме А0 (Приложение 8), а общая стоимость всех работ по учету пациентов отражена на рисунке 2.

Рис. 2. Общая стоимость затрат

Заключение

В рамках выполнения курсовой работы мы ознакомились по литературным источникам с методологией построения моделей в нотациях IDEF0, DFD, IDEF3, изучили доступные на российском рынке инструментальные средства визуального моделирования бизнес-процессов и с помощью выбранного инструмента BPWin построили модель информационной системы, автоматизирующей деятельность регистратора на ОАО «Авитек», а также осуществили функционально-стоимостной анализ процессов.

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

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

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

Библиографический список

1. Вендеров А.М. Проектирование программного обеспечения экономических информационных систем: учебник. - 2-е изд., перераб. и доп. - М.: Финансы и статистика, 2006. - 544 с.

2. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0. - М,: Диалог-МИФИ, 2002. - 224 с.

3. Проектирование информационных систем: Методические указания по выполнению курсовой работы / Сост. О.В. Караваева. - Киров: ВСЭИ, 2009. - 36 с.

4. Смирнова Г.Н. Проектирование экономических информационных систем: Учебник / Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; под ред. Ю.Ф. Тельнова. - М.: Финансы и статистика, 2001. - 512 с.

Электронные ресурсы

5. Анализ современных средств моделирования бизнес-процессов / Режим доступа: http://www.reengine.ru/index.asp?Menu=2&Sub=2

6. Личный сайт специалиста области ИС и ИТ Г. Верникова / Режим доступа: http://www.vernikov.ru/

7. Официальный сайт санатория «Авитек» / Режим доступа: http://www.medavitek.ru/

8. Рубцов C. Опыт использования стандарта IDEF0 / Режим доступа: http://www.iteam.ru/publications/it/section_51/article_1977/

Приложения

Приложение 1

Контекстная диаграмма

Приложение 2

Диаграмма декомпозиции А0

Приложение 3

Диаграмма декомпозиции А1

Приложение 4

Диаграмма декомпозиции А2

Приложение 5

Декомпозиция функции А3 «Лечение»

Приложение 6

Декомпозиция функции А4 «Постановка на учет»

Приложение 7

Ролевая диаграмма

Приложение 8

Диаграмма А0 с внесенными затратами

Размещено на Allbest.ru