Разработка АРМ регистратуры учреждения здравоохранения ООО «Меридиан»

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

5.4. Информирование пользователей об изменениях в работе АИС

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

5.5. Обеспечение восстановления работоспособности АИС

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

6. Требования к программному обеспечению.

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

6.1.Требования к режимам функционирования системы

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

Обеспечение работоспособности серверного оборудования и сетевого оборудования производится силами ИТ-отдела  ООО «Меридиан».

6.2.Требования  по диагностированию  системы

Система должна удовлетворять следующим  требованиям по диагностированию:

автоматический  контроль за нарушениями заложенных в систему правил;

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

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

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

6.3. Перспективы развития, модернизации системы

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

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

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

Система должна обеспечивать стандартный для Windows систем пользовательский интерфейс, отвечающий следующим требованиям:

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

6.6.Требования  по стандартизации  и унификации

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

7.Требования к численности персонала

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

 

8.Состав и содержание работ по созданию системы

 
 
 
 
 

9. Требования к документации

Исполнителем  должны быть разработаны:

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

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

Руководства пользователей для всех модернизируемых  подсистем

Руководство системного администратора

10. Проектирование базы данных в MS Access

Разработку  информационного обеспечения АРМ регистратора проведем на базе системы управления базами данных (СУБД) Access XP из состава выбранного интегрированного пакета Microsoft Office XP.

СУБД Access предназначена  для разработки баз данных реляционного типа для локального их использования  на персональных компьютерах и для  работы с этими базами.

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

Данная СУБД была выбрана по следующим причинам:

§ простота средств  реализации,

§ легкость освоения инструментарием разработчика (VBA),

§ наглядность  визуализации информации.

Также «Microsoft Access»  предоставляет большое количество внутренних средств по оптимизации  работы проектируемого приложения. К  ним относятся:

• загрузка  модулей по требованию;

• оптимизация дерева вызовов;

•  использование  файлов MDE;

• автоматическая поддержка компилированного состояния;

• использование библиотек Windows API;

• индивидуальная  настройка системы;

• эффективное использование индексов;

• встроенный  оптимизатор запросов.

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

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

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

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

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

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

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

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

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

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

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