1.2.3.Схема информационных и материальных потоков

Все подразделения больницы находятся в постоянном взаимодействии; они связаны потоками информации, материальных средств, энергетических и экономических ресурсов, которыми они обмениваются в процессе функционирования. Рассмотрим и проанализируем информационные и материальные потоки. Информационные потоки соответствуют характеру объекта управления: для технологических процессов — это различные сигналы (электрические, оптические, механические и другие), а для организационных систем — документы. Значительная часть информации может представляться в виде документов на машинных носителях, бумажных носителях и в виде электронных файлов.

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

 информационные потоки между подразделениями больницы;

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

1- информация о поступлении пациента;

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

3- информация о размещении пациента;

4- информация о поступлении или выписке пациента;

5- информация о поставленном диагнозе и назначенной системе лечения;

6- информация о поступлении или выписке пациента;

7- информация о поставленном диагнозе и назначенной системе питания;

8- запрос информации о количестве блюд и их стоимости;

9- информация о количестве блюд и их стоимости;

10- запрос информации о количестве лекарственных препаратов и их стоимости;

11- информация о количестве лекарственных препаратов и их стоимости;

12- запрос на материальные средства для комплекса питания;

13- требуемые материальные средства;

14- запрос материально-технического отдела о материальных средствах на склад;

15- требуемые материальные средства;

16- запрос лекарственных средств на складе;

17 - требуемые лекарственные средства;

18- запрос продуктов питания на складе;

19- требуемые продуктов питания;

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

21- информация обо всех материальных средствах, продуктах питания на складе;

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

23- отчеты о результатах работы финансового отдела;

24- информация от секретаря;

25- отчеты о результатах работы юридического отдела;

26- отчет о количестве поступающих пациентах;

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

28- информация о размере расходов на продукты;

29-запрос материально-технического отдела на инвентарь со склада;

3 -необходимый инвентарь.

Рис. 1.5. Информационные и материальные потоки между подразделениями больницы.

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

1.3.Постановка задач на проектирование

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

1.3.1. Недостатки существующей ИС:

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

·        сложность обработки информации;

·        большие затраты времени на обработку информации вручную;

·        сложность при хранении информации;

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

·        большой объем бумажных документов;

В связи с этим, целесообразно внедрение автоматизированной подсистемы «Диетпитание» для учета меню для всех пациентов

Основными направлениями реализации поставленной задачи являются:

1.Организовать процесс автоматизированного учета меню для всех пациентов;

2.Внедрить подсистему «Диетпитание»;

 3.Разработать таблицы БД и структуру связей между ними.

·       для работы с базами данных и практической реализации поставленной задачи необходимо произвести выбор многопользовательской СУБД с целью реализации возможности одновременного доступа нескольких пользователей к информации, хранящейся централизовано на сервере БД. Здесь же необходимо организовать разграничение прав доступа к хранимой информации;

·       необходимо переработать поставленную задачу в соответствии с современными требованиями по программному, техническому, организационному, эргономическому и другими видам обеспечения;

1.3.2.Требования, предъявляемые к внедряемой подсистеме

·       Требования к структуре и функционированию подсистемы

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

·       Требования к работникам

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

·       Требования к надежности и безопасности работы подсистемы

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

·       Требования к эргономике и технической эстетике

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

Рабочее место оператора должно соответствовать нормам и правилам охраны труда.

·       Требования к эксплуатации, техническому ремонту и ремонту технических средств

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

·       Требования к защите информации от несанкционированного доступа

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

1.3.3.Требования к функциям, выполняемым подсистемой

Перечень функций, выполняемых подсистемой:

1.Назначение питания пациенту, соответствующее его диагнозу;

2.Контроль, замена продукта на эквивалентный продукт;

3.Заказ закончившихся продуктов

1.3.4.Обзор современных методов и программных средств решения задачи

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

Системы предоставляют каждому из специалистов участвующих в процессе лечебного питания (врачу-диетологу, диетсестре, начальнику продовольственной службы, старшей медицинской сестре отделения, постовым сестрам лечебных отделений, а так же администратору системы) перечень задач, позволяющих получать и вводить различную информацию в базу данных в режиме реального времени.В качестве платформы для проекта автоматизации учета меню всех пациентов на базе корпоративной информационной системы «Флагман» - разработчик компания «Инфософт» (г.Москва). может быть использована информационная система «Флагман-медицина». Эта ИС существует с 2006 года. Система охватывает различные аспекты медицинской деятельности. ИС «Флагман-медицина» разработана на базе SQL Server компании Microsoft, программирование велось на Turbo Delphi.

Система «Лечебное питание»:

Конфигурация системы «Лечебное питание» разработана «Научно-производственным центром «ДИП» совместно со специалистами Института Питания РАМН. Этот программный комплекс представляет собой конфигурацию «Бухгалтерия для бюджетных организаций» системы программ «1С:Предприятие 7.7», дополненную новыми возможностями, в которых учтена специфика работы врачей-диетологов в стационарах бюджетных медицинских учреждений. Новые возможности конфигурации позволяют производить расчет диетического питания стационара, вести учет приготовления блюд в пищеблоке и контролировать движение продуктов на продовольственном складе. Расчет диетического питания в программе производится в зависимости от количества больных по различным диетстолам и дням недели на основе текущего недельного меню, при этом ведется учет белков, жиров, углеводов, килокалорий. В программе предусмотрены печать картотеки блюд, меню на день, меню-раскладки, бракеражного журнала, раздаточных ведомостей и других стандартных документов, используемых диет-службами стационаров, а также формирование необходимых отчетов. Вместе с тем конфигурация системы «Лечебное питание» содержит все стандартные возможности по ведению учета в конфигурации «Бухгалтерия для бюджетных организаций». Это автоматизированное ведение бухгалтерского учета практически по всем разделам - учет основных средств, нематериальных активов, оборудования, малоценных предметов и запасов; учет сметных назначений, ассигнований и лимитов бюджетных обязательств; учет финансирования, фондов и средств целевого назначения; учет операций по лицевым счетам, открытым в органах казначейства или кредитных организациях, по источникам финансирования и другим участкам учета, формирование регламентированной отчетности и т.д.

Но так как этот программный комплекс представляет собой конфигурацию «Бухгалтерия для бюджетных организаций» системы программ «1С:Предприятие 7.7»,то этот комплекс нам не подходит, потому что в Г/Б№2 бухгалтерия работает с программным продуктом «Парус».

1.3.5.Обоснование необходимости разработки подсистемы

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

Таким образом, для решения возникшей проблемы, наиболее приемлемым вариантом является разработка подсистемы своими силами.

1.3.6.Обоснование необходимости и направлений разработки

В том состоянии (информационном и организационном), в котором сейчас находится система питания в Городской больнице №2 установка серийного продукта, даже самого лучшего, не даст ожидаемых результатов. Коллектив должен быть готов к работе в новых условиях и психологически, и технически. Кроме того, покупка серийной системы в условиях бюджетной организации нерациональна. Наилучшим решением для данной организации будет постепенное внедрение подсистем автоматизации конкретных процессов. Начать следует с организации процесса питания. Подсистема предоставляет каждому из специалистов участвующих в процессе лечебного питания (врачу-диетологу, диетсестре, начальнику продовольственной службы, старшей медицинской сестре отделения, а так же администратору системы) перечень задач, позволяющих получать и вводить различную информацию в базу данных в режиме реального времени. Поскольку медицинское учреждение являются бюджетной организацией, подсистема «Диетпитание» позволит автоматизировать работу не только диет-службы, но и бухгалтерии, что существенно облегчит работу бухгалтеров по обработке информации по приходу и расходу продуктов питания.

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

2.Проектная часть

2.1.Информационное обеспечение разрабатываемой подсистемы

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

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

Информационное обеспечение является средством для решения следующих задач:

1.представления информации о пациенте

2.организации процедур питания с учетом его диагноза

3.организации взаимодействия пользователя с подсистемой на основе экранных форм ввода вывода

4.обеспечения эффективного использования информации в лечении и питании пациента (на основе унифицированной системы документации).

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

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

К информационному обеспечению предъявляются следующие общие требования:

·    информационное обеспечение должно содержать полную и достоверную информацию;

·    иметь эффективные методы сбора, хранения, накопления, обновления и поиска данных;

·    однократный ввод информации и ее многократное и многоцелевое использование;

·    должна быть простой и удобной для доступа к данным информационной базы;

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

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

·    должна быть обеспечена совместимость с информационным обеспечением систем, взаимодействующих с разрабатываемой подсистемой;

·    формы документов должны отвечать требованиям стандартов (или унифицированной системы документации);

·    структура документов и экранных форм должна соответствовать характеристиками терминалов на рабочих местах конечных пользователей.

2.1.1.Внемашинное ИО


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

2.1.2Описание входной и выходной информации решаемой задачи

Структура подсистемы «Диетпитание» (см рис 2.1)



Рис. 2.1. Структура подсистемы «Диетпитание»

Итак, как можно увидеть, что подсистема «Диетпитание» состоит из трех подразделений:

1.Врач-диетолог;

2.Столовая;

3.Кухня.

На рис.2.2.можно видеть функциональную схему

                  

Рис. 2.2. функциональная схема

Обозначения на схеме рис.2.2.

информационные потоки;

материальные потоки (блюда).

На вход подсистемы «Диетпитание» поступают данные о заболевании пациента от самого пациента, а также из диагностического отделения лечебного комплекса. В зависимости от основного диагноза пациента и его дополнительных жалоб на самочувствие, а также его возраста, соответствия роста и веса врач-диетолог выбирает и назначает систему питания каждому пациенту, то есть определенную диету. В соответствии с диетой врач-диетолог устанавливает меню питания данного пациента, то есть список блюд на ближайшую неделю. Эти данные о меню передаются в столовую, а оттуда поступают на кухню, где заказанные блюда будут готовиться и поступать в столовую. На выходе подсистемы «Диетпитание» будут готовые блюда для пациентов.
Функциональные модели основных процессов п/с «Диетпитание» (выполняются врачом-диетологом) представлены на рис. 2.3.



Теперь рассмотрим, с какими отделениями взаимодействует подсистема «Диетпитание».

На рис.2.4.Схема взаимодействия п/с с другими подразделениями



Обозначения на схеме рис.2.4.

информационные потоки;

материальные потоки (продукты питания);

1.диагноз заболевания пациента, поставленный врачами;

2.дополнительная информация о состоянии пациента;

3.меню пациента на неделю;

4.информация о диете пациента, назначенной врачом-диетологом;

5.информация о количестве пациентов, пребывающих в стационар

6.список блюд на неделю;

7.готовые блюда;

8.заказ продуктов питания на складе;

9.продукты питания для приготовления блюд;

10.запрос склада на поиск эквивалентного продукта;

11.список эквивалентных продуктов;

12.запрос бухгалтерии на количество продуктов;

13.перечни продуктов, которые затрачены на приготовление.

2.1.3.Организация работы с п/с «Диетпитание»

Врач-диетолог занимается решением следующих задач:

1.Определение системы питания на планируемый срок;

2.Выбор альтернативного продукта в блюде;

3.Замена блюда Б_i на эквивалентное ему блюдо Б_j в рамках рациона, назначенного врачом-диетологом.

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

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

Схема информационного обмена подразделения «Врач-диетолог» с другими подразделениями больницы представлена на рис.2.5.

Рис.2.5.Информационный обмен врача-диетолога с другими подразделениями больницы

Обозначения на рис.2.5.

1.Информация о самочувствии пациента и результаты его диагностики врачом-диетологом;

2.Информация о заболеваниях и диагнозе пациента, поставленном диагностическим отделением лечебного комплекса;

3.Информация о диагнозе пациента, поставленном врачом-диетологом передается в архив;

4.Запрос столовой на составление меню врачом-диетологом, а также на замену продукта (или блюда), которого не хватает на складе;

5.Составленные врачом-диетологом меню и список эквивалентных продуктов (или блюд);

6.Запрос склада на замену продукта, которого не хватает;

7.Список эквивалентных продуктов.

2.1.4.Определение системы питания на планируемый срок

Врач-диетолог получает от терапевта (из лечебного комплекса) информацию о состоянии пациента и в соответствии с его самочувствием, врач-диетолог рекомендует определенную диету Д_i. Рассмотрим подробнее построение этой модели.

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

Можно составить таблицу исходных данных (Таблица 2.2.1), в которой столбцы определяются как атрибуты, а строки как значения атрибутов.

2.1.5.Подразделение«Столовая»

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

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

В столовой имеется ассортимент приготовленных блюд. Ассортимент блюд составляется c учетом имеющихся на складе продуктов. Для приготовления какого-либо блюда используется определенный набор продуктов. Этот набор продуктов {П} для приготовления блюда {Б_i} является набором атрибутов этого блюда.

Схема взаимодействия подразделения «Столовая» с другими подразделениями представлена на рис.2.6.



Рис.2.6.Схема взаимодействия подразделения «Столовая» с другими подразделениями больницы.
Обозначения потоков информации на рис.2.6.

1.Запрос столовой на составление меню врачом-диетологом;

2.Составленные врачом-диетологом меню;

3.Данные об общем количестве пациентов;

4.Данные о количестве пациентов, с диетическим и общим питанием;

5.Потоки готовых блюд.

2.1.6.Подразделение «Кухня»

Задача заказа блюд на кухне.

Для решения этой задачи необходимо знать:

1.Сколько человек питается по каждой диете;

2.Подсчитать количество блюд.

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

Схема взаимодействия подразделения «Кухня» с другими подразделениями больницы представлена на рис.2.7.



Рис.2.7.Схема взаимодействия подразделения «Кухня».

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

1.Заявка на приобретение продуктов питания;

2.Доставка продуктов со склада на кухню;

3.Запрос бухгалтерии на количество продуктов, ушедших на приготовление блюд;

4.Перечни продуктов, ушедших на приготовление блюд, и их количество;

5.Данные о количестве пациентов, с диетическим и общим питанием;

6.Потоки готовых блюд.

2.1.7.Разработка технологических схем

Поскольку в больнице применяется лечебное (диетическое), так и питание по общему столу, (№ 15 при заболеваниях, не требующих специальных лечебных диет) то в общем случае на кухне следует заказать следующее количество блюд:

К_б = К_БД+К_БС, где

К_Б -количество блюд, заказанное на кухне;

К_БД -количество блюд, заказанных по диете;

К_БС-количество блюд, заказанных по общему столу.

                                                                                                                                   Таблица.2.1Состав продуктов

В столовой имеется ассортимент приготовляемых блюд. Ассортимент блюд составляется с учетом имеющихся на складе продуктов.

Для приготовления какого-либо блюда используется определенный набор продуктов.

Набор продуктов {П} для приготовления блюда Б_j является набором атрибутов этого блюда.

Можно записать:

 Б₁ = {П₁¹ , П₃¹ , П₂₅¹ , П_е¹ ,…};

 Б₂ = {П₁² , П₂² ,…П₁₀² , П_к² ,…};

 :

 :

 Б_j = {П₇^j , П₁₃^j , П₁₅^j},

где П_i^j – i-й продукт, используемый для приготовляемого j–го блюда

(i–вид продукта).

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

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

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

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

Рис.2.8. Общий вид двудольного графа связи блюд и продуктов

Множество вершин {Б_j} на графе отражает множество блюд, а множество вершин {П_i} - множество продуктов. Дуги отражают связь каждого блюда с продуктами, используемыми для его приготовления. Каждая дуга содержит вес брутто В_ji – вес i–го продукта, необходимый для приготовления одной порции j-го блюда.

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

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

Рассмотрим двудольный граф для нескольких конкретных блюд

Граф приведен на рис.2.9.

Б₁ -холодец мясной;

Б₂ -винегрет;

Б₃-жаркое по домашнему.

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

П₁-говядина

П₂-желатин

П₃-морковь

П₄-петрушка

П₅-лук репчатый

П₆ -свекла

П₇-огурцы соленые

П₈-капуста квашенная

П₉-картофель

П₁₀-лавровый лист

П₁₁-перец черный Горошком

П₁₂-жир животный топленый

П₁₃-томатное пюре

П₁₄-масло растительное

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

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

Рис 2.9 Пример двудольного графа соответствия продуктов блюдам

                            Таблица 2.2 соответствий между блюдами и продуктами



Аналогично можно выразить соответствие блюд Б_j и диет Д_i с помощью двудольного графа на рис. 2.10.таблицы 2.3.



Рис2.10Двудольного граф соответствия блюд и диет

На рис. 2.10k_ij – калорийность j-го блюда в i-ой диете.

                            Таблица2.3 соответствия между блюдами и диетами

2.1.8.Поступление и хранение продуктов

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

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

Следовательно, на входе подсистемы «Врач-диетолог» помимо данных о заболеваниях пациента от врача-терапевта из лечебного комплекса должны быть данные о перечне продуктов, их количестве, времени поступления и допустимых сроках хранения.

2.1.9.Инфологическая модель данных

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

Инфологическая модель данных представлена в виде диаграммы «Сущность-связь»:

Рисунок 2.11.Модель «Сущность-связь»

                                                     Диетическое питание пациентов        

        

         В базе данных подсистемы имеются права доступа
                  

                                                           Рис 2.12

         В базе данных подсистемы «Диетпитание» будут храниться и обрабатываться данные о пациентах, диетах, блюдах, продуктах, заболеваниях и др.

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

В тоже время каждой диете ставится в соответствие свой набор приемов пищи (завтрак, обед, полдник и ужин), каждый из которых состоит из различных сочетаний категорий блюд (закуска, 1-е блюдо,  2-е блюдо, 3-е блюдо и десерт). Каждая категория включает в себя свой набор блюд, а каждому блюду ставятся в соответствие свои продукты. В базе данных также хранятся калорийность и энергетическая ценность каждого продукта, содержание в нем белков, жиров, углеводов, витаминов (А, В1, С), а также минеральных веществ (Са, Fe, Ka).

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

Центральными информационными сущностями БД являются сущности «Продукты», «Блюда», «Диеты». Эти информационные сущности несут информацию о калорийности, энергетической ценности, содержании белков, жиров, углеводов, витаминов, а также минеральных веществ в каждом продукте, блюде, диете. Каждый продукт, блюдо, диета характеризуется атрибутами «номер» (уникальное значение), «название», «энергетическая ценность», «белки», «жиры», «углеводы», «витамин А», «витамин В₁», «витамин С», «минерал Са», «минерал Fe», «минерал Ka».  Кроме того, информационная сущность «Блюда» имеет атрибут «рецепт», а сущность «Продукты» - атрибуты «номер поставщика», «единица измерения», «цена», «на складе», «ожидается», «минимальный заказ» (для организации учета запасов продуктов).

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

Сущность  «Заболевание» описывается атрибутами «номер заболевания», «заболевание».

         Сущность «Приемы пищи» описывается атрибутами «номер приема пищи», «прием пищи».

         Сущность «Категории блюд» описывается атрибутами «номер категории», «категория».

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

Далее описываются сущности, играющие вспомогательную роль в проектируемой ИС – разграничение прав доступа.

Сущность «Группы пользователей ИС» описывается атрибутами «номер группы», «название группы», «номер прав доступа», «пароль».

Сущность «Права доступа» описывается атрибутами «номер прав доступа», «описание прав доступа».

Между описанными информационными сущностями БД организуются следующие связи:

·        «Пациент»-«Заболевание» - связь «многие ко многим»;

·        «Диеты» - «Заболевание» - связь «один ко многим»;

·        «Приемы пищи»-«Диеты» - связь «многие ко многим»;

·        «Приемы пищи»-«Категории блюд» - связь «многие ко многим»;

·        «Категории блюд»-«Блюда» - связь «один ко многим»;

·        «Блюда»-«Продукты» - связь «многие ко многим»;

·        «Продукты»-«Поставщики» - связь «многие ко многим»;

·        «Права доступа»-«Группы пользователей ИС» - связь «один ко многим».

2.2.Выбор СУБД

Все СУБД можно разделить на два типа: однопользовательские и многопользовательские (серверные). Выбрана клиент-серверная архитектура для проектируемой информационной системы, поэтому рассмотрим серверные СУБД.

В первую очередь при выборе СУБД необходимо принимать во внимание следующие факторы:

-        независимость от программно-аппаратной платформы;

-     поддержка многопроцессорной и параллельной обработки данных;

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

-        оптимальное хранение распределенных данных, а также быстрый доступ к ним;

-        работа с неструктурированными данными;

-        локальная автономия.

Проведем сравнительный анализ СУБД, в какой-либо степени отвечающих данным требованиям.

MS

SQL

Server
2005
Personal. Удобный пользовательский интерфейс утилит администрирования в сочетании с достаточно высокой производительностью и относительно невысокой стоимостью эксплуатации сделал эту серверную СУБД второй по популярности после Oracle.

Данная версия поддерживает платформы Windows NT, Windows 2000/2003, Windows XP Professional.

СУБД позволяет удовлетворять такие требования, предъявляемые к системам распределенной обработки данных, как тиражирование данных, параллельная обработка, поддержка больших баз данных на относительно не дорогих аппаратных платформах при сохранении несмежного управления.

Важнейшие характеристики данной СУБД - это:

-        простота администрирования;

-        быстродействие и функциональные возможности механизма сервера СУБД;

-        наличие средств удаленного доступа.

         MS SQL Server 2005 Personal, как система управления реляционными базами данных:

-        представляет всю информацию в виде таблиц;

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

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

-        поддерживает основные реляционные операции (выбор, проектирование и объединение), а также теоретико-множественные операции, такие как объединение, пересечение и дополнение;

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

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

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

Низкая суммарная стоимость владения системой наряду с большими возможностями обеспечивает перспективное будущее этой СУБД.

PostrgeSQL – объектно-реляционная система управления базами данных. PostrgeSQL считается самой совершенной СУБД, распространяемой по принципу «freeware». В PostrgeSQL реализованы многие возможности, традиционно встречавшиеся только в масштабных коммерческих продуктах.

В PostgreSQL реализованы многие возможности, обычно присутствующие только в коммерческих СУБД, таких как DB2 и Oracle. Ниже перечислены основные возможности PostgreSQL версии 7.1.x.

• Объектно-реляционная модель. Работа с данными в PostgreSQL основана на объектно-реляционной модели, что позволяет задействовать сложные процедуры и системы правил. Примерами возможностей этой категории являются декларативные запросы SQL, контроль параллельного доступа, поддержка многопользовательского доступа, транзакции, оптимизация запросов, поддержка наследования и массивов.

• Простота расширения. В PostgreSQL поддерживаются пользовательские операторы, функции, методы доступа и типы данных.

• Полноценная поддержка SQL
. PostgreSQL соответствует базовой спецификации SQL99 и поддерживает такие средства, как объединения стандарта SQL92.

• Проверка целостности ссылок. PostgreSQL поддерживает проверку целостности ссылок, обеспечивающую правильность данных в базе.

• Гибкость API
. Гибкость API PostgreSQL позволяет легко создавать интерфейсы к РСУБД PostgreSQL. В настоящее время существуют программные интерфейсы для Object Pascal, Python, Perl, PHP, ODBC, Java/JDBC, Ruby, TCL, C/ C+ и Pike.

• Процедурные языки. В PostgreSQL предусмотрена поддержка внутренних процедурных языков, в том числе специализированного языка PL/pgSQL, являющегося аналогом PL/SQL, процедурного языка Oracle. Одним из преимуществ PostgreSQL является возможность использования Perl, Python и TCL в качестве внутренних процедурных языков.

• Клиент-сервер. В PostgreSQL используется архитектура «клиент-сервер» с распределением процессов между пользователями.

Учитывая то, что перечисленные СУБД имеют характеристики, удовлетворяющие поставленным требованиям, остановимся на выборе той СУБД, которая в настоящее время более предпочтительна - PostgreSQL в силу ее широких возможностей и оптимальной стоимости (она распространяется бесплатно).

2.2.1.Внутримашинная реализация данных

Ведущим направлением организации внутримашинного информационного обеспечения является технология баз и банков данных. К организации информационного обеспечения деятельности подсистемы «Диетпитание» предъявляется ряд требований. Наиболее важными из них являются: обеспечение для многих пользователей работы с данными в реальном времени; предоставление для обмена информацией возможности экспорта/импорта данных в разных форматах; безопасность хранения и передачи информации; сохранение целостности информации при отказе аппаратуры.

В базе данных имеются таблицы:

                                                                      Таблица 2.4.Содержание продуктов



                                                           Таблица  2.5 Содержаниеблюда                                                    

                                                                       Таблица 2.6.Содержание диеты



                                                                  Таблица 2.7.Поставщики

 

                                                           Таблица 2.8.Пациент

                                          

                                                                                  Таблица 2.9.Категория блюд



                                                                                              Таблица 2.10.Приемы пищи



                                                                                             

Таблица 2.11 Права пользователя



                                                                                              Таблица 2.12.Права доступа



                                                          

Таблица2.13 Заболевания



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

                                                                  Таблица 2.14.Диета и прием пищи



                                                                       Таблица 2.15.Пациент и заболевания



                                                                      Таблица2.16 Поставщики-продукты



                                                           Таблица 2.17.Прием пищи и категория блюд



                                                           Таблица 2.18.Блюдо - продукт

                                  

                                                                    

Связи между таблицами представлены на рис 2.13

Рисунок 2.13 «Даталогическая модель данных»

2.3. Математическая модель

2.3.1. Модель организации пищевого рациона

В стационаре ведется как лечебное (диетическое) так и питание пациента по общему столу. Лечебное питание назначается врачом в виде той или иной диеты. Диеты представляют совокупный рацион питания, имеющий определенное лечебное назначение. Каждая диета характеризуется калорийностью, химическим составом пищи (т. е. определенным содержанием в ней белков, жиров, углеводов, витаминов и минеральных солей), а также ассортиментом разрешенных при данной диете продуктов и их сочетаний в виде блюд.На каждый день недели имеется меню, в которое входят блюда для завтрака, обеда, полдника и ужина (см.рис.1.6) имеются указания на то ,какой диете каждое блюдо относится, причем одно и тоже блюдо может относиться к разным диетам. Каждый пациент может выбрать блюда на завтрак, обед, полдник и ужин в соответствии со своей диетой. Взяв различное сочетание блюд на завтрак, обед, полдник и ужин, а также на весь день можно получить все возможные варианты для данной диеты.

Рис. 2.14.Схема суточного рациона пациента

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

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

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

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

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

П_i = {a_1i, a_2i,…,a_ni}.

Можно записать, что продукт П_i имеет эквивалентный продукт Пэ_i тогда, когда атрибуты эквивалентного продукта Пэ_i = {a₁э_i, a₂э_i,…,a_nэ_i} находятся в определенном диапазоне, близком к значениям атрибутов заменяемого продукта. Например, если у заменяемого продукта калорийность равна 45 ккал, то у эквивалентного продукта калорийность должна находиться в пределах 40 – 50 ккал.

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

Блок-схема процесса замены продукта на эквивалентный изображена на рис. 2.16



Рис.2.16.Блок-схема процесса замены продукта на эквивалентный

2.3.3 Замена блюда в диете на эквивалентное

Как уже говорилось выше, если эквивалентный продукт в блюде не найден или не имеет аналогов, то врач-диетолог должен заменить все блюдо. Рассмотрим механизм замены блюда Б_i на Б_j. Поиск эквивалентного блюда необходимо осуществлять в списке блюд { Б_1кл,…, Б_nкл}, приемлемых для диеты Д_кл, в которой заменяется блюдо.

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

Блок-схема замены блюда на эквивалентное блюдо рис.2.15.

Рис.2.17 Блок схема замена блюд на эквивалентное блюдо

2.3.4. Модель управления запасами

Товарно-материальный запас-это запас какого-либо ресурса или предметов, используемых в больнице.

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

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

Установление рационального количества запаса для ГБ № 2 является средством, позволяющим, с одной стороны, ликвидировать ненужные запасы, а с другой стороны – обеспечить ритмичное поступление продуктов для пациентов без перебоев. Управление запасами заключается в установлении моментов и объемов заказов на их восполнение. Совокупность правил, по которым принимаются такие решения, называется стратегией (системой) управления запасами. Оптимальной стратегией считается та, которая обеспечивает минимум затрат по доведению продуктов до пациентов городской больницы № 2. Нахождение оптимальных стратегий составляет предмет теории оптимального управления запасами.

Применяемая в ГБ №2 система с фиксированным размером заказа предполагает, что размер поступающих партий продуктов - величина постоянная, а очередные поставки осуществляются через разные интервалы времени. Заказ на поставку партии продуктов делается при уменьшении размера запаса до заранее установленного критического уровня, называемого "точкой заказа". Таким образом, интервалы между поставками продуктов зависят от интенсивности потребления продуктов.

Ситуацию иллюстрирует рисунок 2.18. На рисунке обозначены:

Z(t) – величина запаса продуктов на складе;

S – "точка заказа";

q = const – объем доставляемой партии продуктов;

,  , , - продолжительность заготовительного периода.



Рис2.18.Движение запаса продуктов

Регулируемыми параметрами являются: "точка заказа" и объем заказа продуктов.

Интервал времени между подачей заявки и поступлением партии продуктов на склад ГБ №2 называется заготовительным периодом.

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



Рис2.19 Порядок функционирования стратегии управления запасами ГБ №2

Рассмотрим модель управления запасами ГБ №2, когда процесс пополнения запасов распределён во времени. В данном случае одна часть производственной системы выполняет функцию поставщика (хозяйственный отдел, отдел закупок) для другой части этой системы, выступающей в роли потребителя (отделения больницы).

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

Приведем обозначения необходимых для дальнейшего анализа величин:

 q - объем закупаемой партии продуктов, шт.;

 - интенсивность потребления, шт./ед. времени;

 - темп закупок, шт./ед. времени; соответственно, - темп прироста запасов (шт./ед. времени), на графике - тангенс соответствующего угла;

 -Zmax - максимальный уровень запасов;

 b - расходы на хранение единицы продукции в единицу времени, ед. стоимости;

 c0 - затраты на заготовительно-складские работы, ед. стоимости;

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



Рис.2.20-Движение запасов в модели с постепенным пополнением, применяемой в ГБ № 2

Из рисунка 2.20. видно, что изделия производятся в течение только части цикла, потому что темп заготовки продуктов выше темпа потребления; потребление же происходит на протяжении всего цикла. Уровень запасов равен разнице между уровнем заготовки и уровнем потребления. Пока продолжается поставка, уровень запасов будет повышаться. Когда поставка прекращается, уровень запасов начинает снижаться. Следовательно, уровень запасов будет максимальным в момент завершения поставки. Когда наличный запас продуктов будет исчерпан, поставки возобновляется, и весь цикл повторяется вновь.

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

На этот раз включим в общие расходы всего два вида издержек: затраты на проведение заготовительных работ и затраты на хранение продуктов. Расходы, пропорциональные объему партии (компонент, включающий величину c₁), в функцию включать не будем. Во-первых, это слагаемое никак не влияет на итоговые выражения для оптимальных параметров, во-вторых, в условиях, когда ГБ №2 одновременно является и поставщиком, и потребителем продуктов, такие затраты по сути не связаны с функционированием системы хранения запасов.

Итак, суммарные затраты V(t) за период времени [0,t]:

 V(t) = c ₀n(t) + b∙Zср∙t → min. (1)

Далее разделим предыдущее выражение на t, получим:

 V = c₀∙ + b∙ → min. (2)

Выразим Zmax через q (объем приобретаемой партии продуктов):

Zmax = q/p (p - ),

откуда: V = c₀∙/q + bq/2p∙( p- ) → min.

Приравняем нулю производную:

 dV/dp= -c₀∙/q²+ bq/2p∙( p- )=0 (3)

Выразим q:

 (4)

Выражение (4) используется для определения оптимального размера партии продуктов с модели с постепенным пополнением запаса.

Оптимальное значение "точки заказа" S* находится из так:

S*=*θ

"Точка заказа" в данном случае представляет собой уровень запаса продуктов ГБ № 2, при котором следует начать заготовительные работы.

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

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

Если же система хранения запасов имеет сложную структуру, используемые вероятностные распределения сложны, а их характеристики изменяются с течением времени, то единственным средством анализа становятся имитационные эксперименты.

2.4. Алгоритмы и технология решения задач

Разобьем все данные на группы в соответствии с подразделениями подсистемы «Диетпитание», то есть, в каком подразделении какие данные будут использоваться.

1. Врачу-диетологу необходимы следующие данные:

·        фамилия, инициалы имени и отчества пациента;

·        дата рождения пациента;

·        диагноз заболевания пациента;

·        поставленная в соответствии с заболеванием диета питания;

·        наименования всех блюд в столовой;

·        калорийность блюд;

·        содержание белков, жиров, углеводов в блюде;

·        содержание витаминов А, В1, С в блюде;

·        содержание минеральных веществ Са, Fe, Ka;

·        наименования всех продуктов на складе;

·        калорийность продуктов;

·        содержание белков, жиров, углеводов в продукте;

·        содержание витаминов А, В1, С в продукте;

·        содержание минеральных веществ Са, Fe, Ka в продукте;

·        количество пациентов каждой диеты;

·        рационы питания пациентов.

2. Подразделению «Столовая» необходимы данные:

·        количество пациентов каждой диеты;

3. Подразделению «Кухня» необходимы данные:

·        наименования всех блюд в столовой;

·        количество каждого блюда;

·        рецепты блюд;

·        перечень продуктов;

·        количество продуктов для каждого блюда.

4. Подразделению «Склад» необходимы данные:

·        наименования всех продуктов на складе;

·        единица измерения

·        цена за единицу;

·        количество продукта в наличии на складе;

·        ожидаемое количество продукта;

·        минимальный заказ данного продукта;

·        данные о поставщике.

2.4.1. Разработка технологической схемы (технологии) ввода и накопления информации

В соответствии с функциями объекта автоматизации составим структуру экранных форм и меню, представленную на рис.2.21



Рис 2.21.Структура экранных форм

2.4.2 Построение форм ввода-вывода информации

В соответствии со структурой экранных форм для каждого подразделения подсистемы «Диетпитание» создадим экранные формы. Форма главного меню представлена на рис. 2.22.


Рис. 2.22. Форма «Главное меню»

         Для врача-диетолога созданы экранные формы, представленные на рис.2.23.– 2.31.



Рис. 2.23. Форма «Врач-диетолог»


Рис.2.24. Форма «Содержание продуктов»


Рис.2.25. Форма «Содержание блюд»



Рис.2.26. Форма «Содержание диет»

Рис.2.27. Форма «Диета и заболевания»



Рис.2.28. Форма «Карта пациента»



Рис.2.29. Форма «Рацион питания»

Рис. 2.30. Форма «Эквивалентный продукт»


Рис.2.31. Форма «Эквивалентное блюдо»
Для столовой создана экранная форма, представленная на рис.2.32.

Рис.2.32. Форма «Число пациентов диеты»

Для кухни созданы экранные формы, представленные на рис. 2.32



Рис.2.33. Форма «Кухня»


Рис.2.34. Форма «Рецепты блюд»
Форма «Продукты» была представлена выше на рис.2.24
Для склада созданы экранные формы, представленные на рис.2.35 и           2.36


Рис.2.35. Форма «Склад»

Рис.2.36. Форма «Управление запасами»
Описание работ с формами

Для работы с базой данных подсистемы «Диетпитание» необходимо

запустить данное приложение.

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

Далее в зависимости от выбранной группы и введенного пароля открывается соответствующая форма: «Врач-диетолог», «Столовая», «Кухня», «Склад».

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

На форме «Врач-диетолог» пользователь увидит следующие кнопки:

         - «Содержание продуктов»-откроется форма со списком наименований продуктов и следующими значениями каждого продукта: энергетическая ценность, белки, жиры, углеводы, витамины А, В₁, С и минералы кальций, железо и калий. Если значения продуктов отсутствуют, их необходимо ввести.

         - «Содержание блюд»-откроется форма со списком наименований блюд и следующими значениями каждого блюда: энергетическая ценность, белки, жиры, углеводы, витамины А, В₁, С и минералы кальций, железо и калий. Все значения блюд считаются автоматически, если были правильно введены соответствующие значения для каждого продукта.

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

         -«Заболевания» - откроется форма всех наименований заболеваний пациентов (при их отсутствии их необходимо ввести).

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

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

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

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

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

На форме «Кухня» расположены следующие кнопки:

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

- «Содержание продуктов» - откроется форма со списком наименований продуктов и следующими значениями каждого продукта: энергетическая ценность, белки, жиры, углеводы, витамины А, В₁, С и минералы кальций, железо и калий. Если значения продуктов отсутствуют, их необходимо ввести.

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

2.5. Обоснование выбора системного обеспечения

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

Операционная система, ОС (англ. operating

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

С 1990-х наиболее распространёнными операционными системами для персональных компьютеров и серверов являются ОС семейства Microsoft Windows и Windows NT, Mac OS и Mac OS X, системы класса UNIX (особенно GNU/Linux).

Операционные системы, в свою очередь, нужны, если:

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

• различные программы нуждаются в выполнении одних и тех же рутинных действий. Напр., простой ввод символа с клавиатуры и отображение его на экране может потребовать исполнения сотен машинных команд, а дисковая операция — тысяч. Чтобы не программировать их каждый раз заново, ОС предоставляют системные библиотеки часто используемых подпрограмм (функций);
• между программами и пользователями системы необходимо распределять полномочия, чтобы пользователи могли защищать свои данные от чужого взора, а возможная ошибка в программе не вызывала тотальных неприятностей;
• необходима возможность имитации «одновременного» исполнения нескольких программ на одном компьютере (даже содержащем лишь один процессор), осуществляемой с помощью приёма, известного как «разделение времени». При этом специальный компонент, называемый планировщиком, «нарезает» процессорное время на короткие отрезки и предоставляет их поочередно различным исполняющимся программам (процессам);
• наконец, оператор должен иметь возможность, так или иначе, управлять процессами выполнения отдельных программ. Для этого служат операционные среды, одна из которых — оболочка и набор стандартных утилит — является частью ОС (прочие, такие, как графическая операционная среда, образуют независимые от ОС прикладные платформы).

Таким образом, современные универсальные ОС можно охарактеризовать прежде всего как

1.     использующие файловые системы (с универсальным механизмом доступа к данным),

2.     многопользовательские (с разделением полномочий),

3.     многозадачные (с разделением времени).

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

В рамках данного дипломного проекта было разработано программное обеспечение для автоматизации подсистемы «Диетпитания». Для разработки программного обеспечения использовалось среда разработки Borland Turbo C++ Explorer Edition, которая является бесплатным аналогом Borland C++ Builder6 . Ниже приведены ее основные преимущества

Быстрое создание сверхвысокопроизводительных приложений Win32 Turbo C++ - это единственное средство быстрой разработки приложений на языке C++ для платформы Win32. С его помощью можно создавать приложения для самой популярной платформы в мире, используя быстрое компилирование и высокоэффективную интегрированную среду разработки (IDE), и не прибегая к runtime-модулям для созданных приложений. Уникальная функция CodeGuard, существующая только в Turbo C++, позволяет без труда обнаруживать утечки памяти и ресурсов в коде. Turbo C++ позволит создавать приложения с графическим пользовательским интерфейсом (GUI), приложения для баз данных и веб-приложения в одной из самых надежных, функциональных и управляемых сред быстрой разработки приложений.

1.                 Расширяемая компонентная модель: более 200 компонентов приложений в комплекте поставки, возможность создания своих собственных компонентов, загрузки бесплатных компонентов или приобретения компонентов сторонних разработчиков Библиотека визуальных компонентов Turbo C++ (VCL) - это полнофункциональная и постоянно расширяемая платформа для разработки приложений. Широкий спектр компонентов - коммерческих, бесплатных и с открытым кодом - позволяет расширить функциональность существующей библиотеки, включающей более 200 встроенных компонентов.

2.                 Ускоренное программирование при помощи модулей Live Templates, Code Completion, Code Insight и Block Completion Расширяемые и настраиваемые шаблоны Live Templates ускоряют написание распространенных фрагментов кода. Модуль Block Completion обеспечивает правильность структуризации кода. Автоматическая подстановка имен переменных и подбор правильных методов, свойств и функций позволяет уменьшить затраты времени на создание кода.

3.                 Удобный доступ к данным Приложение можно с легкостью связать с данными, хранящимися в базе данных InterBase, MySQL, Microsoft Access, Paradox и dBase. Используя прямое подключение к настольной системе, веб-серверу, или с помощью технологии клиент/сервер можно обеспечить доступ к данным извне посредством веб-служб.

4.                 Создание приложений на C/C++ в соответствии с отраслевыми стандартами Turbo C++ обеспечивает поддержку стандартных языков и библиотек ANSI C и ISO/ANSI C++. Turbo C++ также содержит стандартные библиотеки Dinkumware C++ и поддерживает популярную библиотеку Boost.

При выборе языка программирования было обращено внимание на основные характеристики языков, поддерживающих объектно-ориентированное программирование.

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

Достоинствами языка Pascal являются:

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

-                                           достаточно низкие аппаратные и системные требования, как самого компилятора, так и программ, написанных на этом языке;

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

-                                           поддержка структурного программирования, программирования "сверху-вниз", а также объектно-ориентированного программирования.

Язык С++ – это структурированный, модульный, компактный язык программирования общего назначения, традиционно используемый для системного программирования. Это переносимый язык, т.е. программы, написанные на нем, могут легко быть установлены на другом компьютере. С++ может использоваться практически для любых задач.

Свойства языка С++:

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

С++ совмещает в себе возможности объектно-ориентированного программирования в терминах базирующихся на синтаксисе языка программирования С, позволяет программистам повторно использовать существующие компоненты, и проектировать новые компоненты исходя из уже существующих, для увеличения скорости разработки программного обеспечения;

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

Приложение реализовано на языке С++, выбор которого обусловлен тем, что данный язык более знаком и близок по своим качествам, чем Pascal, хотя оба эти языка обладают подобными свойствами.

Таким образом, разработка и отладка программы производилась на языке С++ в среде Turbo C++ Explorer Edition.

2.7. Обоснование выбора технического обеспечения п/с

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

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

·                     ПЭВМ типа IBM PC/AT с минимальной конфигурацией:

·                     процессор: Pentium, 133 MHz или более мощный;

·                     оперативная память: 256 Мб;

·                     емкость жесткого диска: 40 Гб;

·                     монитор Super VGA с разрешением 800x600 точек или более высоким, поддерживающий 256 цветов.

Данное техническое обеспечение обеспечит успешное функционирование создаваемой подсистемы.
3.Расчет экономической эффективности от внедрения подсистемы

«Диетпитание»

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

3.1.Разработка бизнес плана

Цель дипломного проекта: разработка подсистемы «Диетпитание», направленной на автоматизацию подбор систем питания пациентов Городской больницы № 2.

Разрабатываемая подсистема будет способствовать:

-    снижению трудоёмкости обработки информации;

-    формированию картотеки блюд;

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

-    работе с различными диетами;

-    соблюдению витаминного состава блюд;

-    учёту особенностей диет-столов.

Период реализации проекта – 3 года.

Подсистема разрабатывается силами инженеров – программистов, работающих в больнице.

3.2.Краткая характеристика предприятия

Городская больница № 2 оказывает амбулаторно-поликлиническую помощь населению, а также экстренную медицинскую помощь жителям г. Старый Оскол и Старооскольского района. В состав больницы входит больничный комплекс, рассчитанный на 420 коек и поликлиника, рассчитанная на 850 посещений в смену.

Основные функции Городской больницы №2:

- оказание медицинской помощи;

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

3.3.Расчёт экономической эффективности внедряемого проекта

Под эффективностью внедрения подсистемы «Диетпитание» для пациентов Городской больницы №2 понимается целесообразность применения данной подсистемы.

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

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

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

Оба вида рассмотренной экономической эффективности взаимосвязаны.

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

Внедрение подсистемы «Диетпитание» позволит:

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

- снизить расходы.

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

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

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

-      чистый дисконтированный доход (ЧДД);

-      индекс доходности (ИД);

-      период возврата инвестиций;

-      срок окупаемости.

Чистый дисконтированный доход — превышение интегральных результатов над интегральными затратами. Определяется как сумма текущих эффектов за весь расчетный период, приведенная к начальному шагу.

Если в течение расчетного периода не происходит инфляционного изменения цен или расчет производится в базовых ценах, то величина ЧДД для постоянной нормы дисконта вычисляется по формуле:

                                                                    (3.1)

где Дt — результаты, достигаемые на t-ом шаге расчета;

Рt — затраты, осуществляемые на том же шаге;

α – норма дисконта;

Дt – Рt - эффект достигаемый на t-ом шаге.

Если ЧДД инвестиционного проекта положителен, то проект является эффективным (при данной норме дисконта), и может рассматриваться вопрос о его принятии. Чем больше ЧДД, тем эффективнее проект. Если инвестиционный проект будет осуществлен при отрицательном ЧДД, инвестор понесет убытки (проект неэффективен).

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

                                                                              (3.2)

Индекс доходности строится из тех же элементов, что и ЧДД. Если ЧДД положителен, то ИД > 1 и наоборот.

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

ВНД является решением уравнения:

                                         (3.3.)                  

Расчет ЧДД инвестиционного проекта показывает, является ли он эффективным при некоторой заданной норме дисконта .

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

Календарный график создания проекта включает следующие этапы:

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

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

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

4. Тестирование. Комплексная отладка созданной подсистемы.

5.Внедрение проекта. Внедрение информационной подсистемы в эксплуатацию, обучение персонала больницы по работе в подсистеме.

6.Эксплуатация. Непосредственное использование подсистемы.

Произведем анализ расходов по созданию и внедрению подсистемы.

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

К единовременным затратам относятся затраты на техническое и системное программное обеспечения. Затраты на технические средства и на программные средства приведены в таблице 3.1. и таблице 3.2. соответственно.

                                               Таблица 3.1Затраты на технические средства

Оборудование	Сумма, руб.
Сервер	100000
Источник бесперебойного питания	10000
Компьютеры	40000
Итого	150000

                                                                                                                  
                       Таблица 3.2 Затраты на программное обеспечение

ПО	Сумма, руб.
Операционная система:	20000

Подсчитаем единовременные затраты по внедрению системы, сведя их в таблицу 3.3.

                                                                               Таблица 3.3 Единовременные затраты

 

Кроме единовременных затрат по внедрению в ходе эксплуатации системы будут неизбежно возникать постоянные затраты.

К постоянным затратам можно отнести: ремонт и обслуживание подсистемы, затраты на электроэнергию, затраты на расходные материалы.

Ремонт и обслуживание системы включает в себя администрирование и сопровождение (затраты на поддержку, услуги по сопровождению работы системы). Ремонт и обслуживание системы составит 20 % от стоимости оборудования (технического обеспечения), 180000*0,20=36000 рублей.

Эксплуатация включает затраты на электроэнергию 300*12=3600 рублей.

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

Постоянные затраты за срок эксплуатации системы приведены в Таблице 3.4.
                                                                       Таблица 3.4.Постоянные затраты

Расходы	Периоды
	1 год	2 год	3 год
Затраты на ремонт и обслуживание	36000	36000	36000
Эксплуатация	3600	3600	3600
Затраты на расходные материалы	5000	5000	5000
Консультации персонала	10000	10000	10000
Расходы на оплату труда оператора подсистемы	60000	60000	60000
Итого	114600	114600	114600

Так доходов данная подсистема не приносит и направлена на снижение расходов, то рассчитаем экономические показатели эффективности.

Рассчитаем норму дисконта с учетом инфляции.

α = (ставка рефинансирования – процент инфляции) (3.4)

 (1+процент инфляции)

Ставка рефинансирования ЦБ РФ установлена в размере 8,25 %.

Процент инфляции – 8 %.

Таким образом,

α = 8,25- 8 = 0,03

 1 + 8

Экономические показатели эффективности разрабатываемого проекта инвестиций приведены в таблицы 3.5.

                                                                                              Таблица3.5Инвестиции

Единовременные затраты	180000
Итого	180000

Так как Городская больница № 2 является государственной некоммерческой организацией и инвестиционный проект рассчитан на снижение расходов, то предполагаемая сумма снижения расходов ежегодно состоит из снижения расходов на оплату труда за счёт высвобождения 2 работников и снижения трудоёмкости обработки информации.

Таким образом, принимаем сумму снижения расходов как условную сумму доходов в 220000 рублей.

 Составим план денежных потоков (таблица 3.6).

 Таблица 3.6

                                                                      Таблица3.6План денежных потоков

	Периоды
	1 год	2 год	3 год
Инвестиции	-180000
Доходы	220000	220000	220000
Расходы	-114600	-114600	-165000
Коэффициент дисконтирования	0,97087	0,94260	0,91514
Чистый дисконтированный поток	-72427	99351	96456
Чистый дисконтированный поток нарастающим итогом	-72427	26924	123380

NPV (30%) =123380 руб.

NPV >0, значит проект эффективен.

На основании полученных данных построим финансовый профиль проекта (рис.3.1).



Рис 3.1. Финансовый профиль инвестиционного проекта

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

На графике видно, что срок окупаемости равен 10 месяцев.

Период возврата инвестиций – период, за который инвестор возвращает свои финансовые вложения. На рисунке 3.1 видно, что период возврата инвестиций равен:

П_в=1,7 года=18 мес.

Рассчитаем индекс доходности разрабатываемой системы, сведя необходимые для расчёта показатели в таблицу 3.7.

Таблица 3.7

                                                                       Таблица3.7Расчёт индекса доходности

	Периоды
	1 год	2 год	3 год
Доходы	220000	220000	220000
Расходы	114600	114600	114600
Коэффициент дисконтирования	0,97087	0,94260	0,91514
Дисконтированные доходы	213591	207372	201331
Дисконтированные расходы	111262	108022	104875

Далее рассчитаем индекс доходности.

Индекс доходности-представляет собой отношение суммы приведенных эффектов к величине капитальных вложений:

 ИД=(622294-324159)/180000=1,66

Так как индекс доходности положителен, то проект является эффективным.

В результате проведённых в данном разделе дипломного проекта расчётов можно сказать следующее:

- проект эффективен;

- чистый дисконтированный доход больше 0;

- срок окупаемости проекта 8 месяцев;

- период возврата инвестиций составляет 1,7 года;

- индекс доходности равен 1,66;

 -период реализации проекта 3 года.

Таким образом, инвестиционный проект рекомендуется применять.

1. Реферат Спортивно-боевые единоборства как синтез культур востока и запада
2. Контрольная работа Контрольная работа по Учёту на предприятиях малого бизнеса
3. Сочинение на тему Салтыков-щедрин m. e. - Мастерство сатирического изображения действительности в одном из произведений
4. Реферат на тему Туризм в Восточной Азии
5. Реферат на тему Enlightenment Essay Research Paper 18th Century European
6. Реферат Математическое моделирование высокочастотных радиоцепей на основе направленный графов
7. Реферат на тему Diabetes Mellitus Essay Research Paper Diabetes Mellitus
8. Реферат Міскантус гігантеус як джерело енергетичної сировини сільськогосподарського походження
9. Контрольная работа Политика как общественное явление 7
10. Реферат на тему Вредные привычки и их последствия