Автоматизированная системы "Поликлиника"

МИНОБРНАУКИ РОССИИ

 

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ  БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ  УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ОРЕНБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

 

 

Факультет вечернего  и заочного отделения

 

Кафедра экономики и  управления на предприятии

 

 

 

Контрольная работа

 

 

по дисциплине «Основы  менеджмента в медицинских учреждениях»

 

На тему: Автоматизированная системы "Поликлиника"

ГОУ ОГУ 200402,5012,07 ОО

 

 

 

 

 

 

Руководитель работы

____________ Лапаева 

«____»__________20___ г.

 

Исполнитель

Студент группы 07 ИДМБ

________ хххххххххххВ.М.

«____»__________ 20___ г.

 

 

 

 

 

 

Оренбург 2012г.

 

 

 

 

Содержание

 

Введение

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

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

3. Создание автоматизированной информационной системы "Поликлиника"

3.1 Информационная модель

3.2 Определение сущностей

3.3 Нормализация отношений

3.4 Определение взаимосвязей

3.5 Описание физической  модели

3.6 Проектирование интерфейса

4. Алгоритм работы  программы

5. Руководство пользователя

Заключение

 

 

Введение

 

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

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

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

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

Цель работы: собрать  материал и разработать Автоматизированную информационную систему для работы регистратуры поликлиники № 4.

 

 

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

 

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

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

• Обследование объекта автоматизации (анализ) и формулирование требований пользователей к системе управления.
• Постановка целей. Анализ существующих методов и средств автоматизации аналогичных объектов и формулирование на основании требований пользователя достижимых целей функционирования системы управления. Цели должны быть четкими, явными и измеримыми. Цели должны определять: общее назначение системы, определение разных групп пользователей и их роли, подробное перечисление функций системы, виды необходимой документации, параметры эффективности (производительности), совместимость с другими продуктами и стандартами, конфигурации аппаратуры, средства обеспечения безопасности, методы и средства настройки и обслуживания, методы обеспечения надежности системы. Цели не должны конфликтовать между собой, так как ими необходимо руководствоваться для выработки компромисных решений на следующих этапах проектирования.
• Разработка архитектуры системы (декомпозиция функциональной структуры и определение связей между ее элементами). Выделение уровней управления, подсистем, комплексов задач, задач и функций управления.
• Разработка инфологической модели системы, описывающей статику и динамику объекта. Формализация моделей состояния объекта, материальных, финансовых и информационных (управляющих) потоков и их взаимодействия между собой.
• Разработка системы классификации объектов учета и управления и идентификации их параметров. Словари описывают основные понятия предметной области системы, необходимые для разработки стандартных алгоритмов обработки данных. Классификаторы описывают структуру объекта (подразделения, сотрудники, должности), внешней среды (клиенты, районы, пункты погрузки/разгрузки), характеристики материальных потоков (партии, фонды, ед. измерения, показатели качества, типы цен, виды оплаты). Типовые операции описывают алгоритмы управления (обработки информации).
• Разработка информационной модели системы (проектирование структур баз данных и их связей).
• Синтез структуры программного обеспечения (агрегирование системы). При объединении отдельных функций управления в программные модули необходимо стремиться к высокой "прочности" и слабому "сцеплению" модулей. Прочность и сцепление модуля являются, соответственно, мерами его внутренних и внешних связей. В зависимости от назначения модулей необходимо стремиться либо к их функциональной прочности (объединение взаимосвязанных функций управления), либо к информационной прочности (объединение функций, выполняемых на ограниченном подмножестве информационного пространства системы).
• Выбор метода сборки и тестирования системы. Известно несколько методов сборки и тестирования сложных программных систем: восходящий, нисходящий, модифицированный нисходящий, большого скачка, метод сэндвича, модифицированный метод сэндвича. Рекомендуется использовать для тестирования системы модифицированный метод сэндвича, при котором модули нижних уровней управления тестируются снизу вверх, а модули верхних уровней управления сначала тестируются автономно, а затем собираются в агрегаты нисходящим методом. Преимуществами предложенного метода являются: высокий параллелизм в программировании модулей, небольшое количество заглушек, минимальное время появления рабочей версии системы. Отметим, что от выбранного метода сборки и тестирования сильно зависит последовательность проектирования и программирования отдельных модулей. Поэтому метод сборки системы необходимо выбрать до начала этапа проектирования модулей.
• Проектирование модулей. Разработка внешних спецификаций, описывающих сопряжения (связи) между модулями, и проектирование логики (алгоритмов) модулей.
• Программирование модулей на выбранных программных средствах. При программировании необходимо помнить, что текст программы необходим для общения с людьми, а не с машиной. Важность этого утверждения станет очевидна, когда наступит этап сопровождения системы. Для повышения надежности программного обеспечения необходимо использовать при программировании метод взаимного недоверия модулей, то есть каждый модуль системы должен относиться с определенной долей недоверия, в разумных пределах, к полученным входным данным и проверять их перед обработкой.
• Интеграция (сборка) системы в соответствии с выбранным методом и ее тестирование. Этапы тестирования: автономное тестирование - контроль отдельного программного модуля изолированно от других модулей, тестирование сопряжений - контроль сопряжений между частями системы, тестирование функций - контроль выполнения системой автоматизируемых функций управления, комплексное тестирование - испытание поведения системы по отношению к исходным целям, тестирование приемлемости - проверка соответствия системы требованиям пользователей. Тестирование - процесс выполнения программы с целью найти в ней ошибки. Существует два подхода к проектированию тестов - тестирование по отношению к спецификациям (не заботясь о тексте программы) и тестирование по отношению к тексту программы (не заботясь о спецификациях). Разумный компромис лежит где-то посередине, смещаясь в ту или другую сторону в зависимости от функций, выполняемых конкретным модулем. Также отметим, что стоимость этапа тестирования составляет до 25% от общей стоимости затрат на разработку системы.
• Разработка методического обеспечения. Руководства пользователей, инструкции по эксплуатации, технологические инструкции.
• Внедрение системы на объекте.
• Сопровождение системы: устранение ошибок и замечаний пользователей, разработка дополнительных режимов и функций управления, функциональное расширение системы. В соответствии со спиральной моделью жизненного цикла программного обеспечения осуществляется переход на 1 - 10 этапы проектирования системы.

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

 

 

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

 

Современные СУБД в основном являются приложениями Windows, так как  данная среда позволяет более  полно использовать возможности  персональной ЭВМ, нежели среда DOS. Снижение стоимости высокопроизводительных персональных компьютерах обусловил не только широкий переход к среде Windows, где разработчик программного обеспечения может в меньше степени заботиться о распределении ресурсов, но также сделал программное обеспечение ПК в целом и СУБД в частности менее критичными к аппаратным ресурсам элетроннно-вычислительной машины.

Среди наиболее ярких  представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии “клиент-сервер”. Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще – диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом “де-факто” стала “быстрая разработка приложений” или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе “открытом подходе”, то есть необходимость и возможность использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных. Поэтому в одном ряду с “классическими” СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами “классических” СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии “клиент-сервер”.

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

Рассмотрим более подробно программные продукты компании Microsoft, а именно Visual FoxPro 3.0, Paradox, Visual Basic 4.0, Visual С++, Access 7.0.

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

FoxPro (фирма Fox Software) обладала  исключительно высокими скоростными  характеристиками и в этом  отношении заметно выделялась  среди интерпретирующих систем. Сравнительно с dBaseIV ее скорость в несколько раз выше и не уступает скорости систем-компиляторов. Практически по всем показателям Fox-программы работают значительно быстрее Clipper-программ. (Напоминаем - речь пока о версии для DOS’a.) Набор команд и функций, предлагаемых разработчиками FoxPro, по мощи и гибкости отвечает любым требованиям к представлению и обработке данных. Может быть реализован максимально удобный и эффективный пользовательский интерфейс. В FoxPro поддерживаются разнообразные всплывающие и многоуровневые меню, работа с окнами и мышью, реализованы функции низкоуровнего доступа к файлам, управление цветами, настройками принтера, данные могут быть представлены с виде «электронных таблиц» и много еще приятностей и удобностей. В «довиндовскую» эпоху FoxPro был самой быстрой, самой удобной и самой мощной СУБД для компьютеров стандарта IBM PC.

версии 3.0 – процессор 468DX, Windows 3.1, 95, NT, объем оперативной памяти 8 (12) Мб, занимаемый объем на ЖМД 15-80 Мб, а для Visual FoxPro версии 5.0 (выпущена в 1997 году) – Windows 95 или NT, 486 с тактовой частотой 50 МГц, 10 Мб ОЗУ, от 15 до 240 Мб на ЖМД.

Paradox был разработан  компанией Ansa Software, и первая его  версия увидела свет в 1985 году. Этот продукт был впоследствии  приобретен компанией Borland. С июля 1996 года он принадлежит компании Corel и является составной частью Corel Office Professional.В конце 80-х - начале 90-х годов Paradox, принадлежавший тогда компании Borland International, был весьма популярной СУБД, в том числе и в нашей стране, где он одно время занимал устойчивые позиции на рынке средств разработки настольных приложений с базами данных.

Принцип хранения данных в Paradox сходен с принципами хранения данных в dBase - каждая таблица хранится в своем файле (расширение *.db), MEMO- и BLOB-поля хранятся в отдельном файле (расширение *.md), как и индексы (расширение *.px).

Однако, в отличие от dBase, формат данных Paradox не является открытым, поэтому для доступа к данным этого формата требуются специальные  библиотеки. Например, в приложениях, написанных на C или Pascal, использовалась некогда популярная библиотека Paradox Engine, ставшая основой Borland Database Engine. Эта библиотека используется ныне в приложениях, созданных с помощью средств разработки Borland (Delphi, C++Builder), в некоторых генераторах отчетов (например, Crystal Reports) и в самом Paradox. Существуют и ODBC-драйверы к базам данных, созданным различными версиями этой СУБД.

Отметим, однако, что отсутствие <открытости> формата данных имеет  и свои достоинства. Так как в этой ситуации доступ к данным осуществляется только с помощью <знающих> этот формат библиотек, простое редактирование подобных данных по сравнению с данными открытых форматов типа dBase существенно затруднено. В этом случае возможны такие недоступные при использовании <открытых> форматов данных сервисы, как защита таблиц и отдельных полей паролем, хранение некоторых правил ссылочной целостности в самих таблицах - все эти сервисы предоставляются Paradox, начиная с первых версий этой СУБД.

По сравнению с аналогичными версиями dBase ранние версии Paradox обычно предоставляли разработчикам баз данных существенно более расширенные возможности, такие как использование деловой графики в DOS-приложениях, обновление данных в приложениях при многопользовательской работе, визуальные средства построения запросов, на основе интерфейса QBE - Query by Example (запрос по образцу), средства статистического анализа данных, а также средства визуального построения интерфейсов пользовательских приложений с автоматической генерацией кода на языке программирования PAL (Paradox Application Language).

Windows-версии СУБД Paradox, помимо перечисленных выше сервисов, позволяли также манипулировать  данными других форматов, в частности  dBase и данными, хранящимися в  серверных СУБД. Такую возможность пользователи Paradox получили благодаря использованию библиотеки Borland Database Engine и драйверов SQL Links. Это позволило использовать Paradox в качестве универсального средства управления различными базами данных (существенно облегченная версия Paradox 7 под названием Database Desktop по-прежнему входит в состав Borland Delphi и Borland C++Builder именно с этой целью). Что же касается базового формата данных, используемого в этом продукте, то он обладает теми же недостатками, что и все форматы данных настольных СУБД, и поэтому при возможности его стараются заменить на серверную СУБД, даже сохранив сам Paradox как средство разработки приложений и манипуляции данными.

Текущая версия данной СУБД - Paradox 9, поставляется в двух вариантах - Paradox 9 Standalone Edition и Paradox 9 Developer's Edition. Первый из них предназначен для использования  в качестве настольной СУБД и входит в Corel Office Professional, второй - в качестве как настольной СУБД, так и средства разработки приложений и манипуляции данными в серверных СУБД. Обе версии содержат: