39899

Повышение эффективности работы стоматологической поликлиники «Мастер-дент»

Дипломная

Информатика, кибернетика и программирование

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

Русский

2013-10-11

2.96 MB

346 чел.

PAGE  35


СОДЕРЖАНИЕ

[1]
Введение

[2]
1. Аналитическая часть

[2.1] 1.1. Описание процесса работы стоматологической поликлиники «Мастер-дент»

[2.2] 1.2. Функциональное моделирование процесса работы стоматологической поликлиники «Мастер-дент»

[2.3]
1.3. Обзор программ - аналогов

[2.4] 1.4. Выводы

[2.5] 2.1. Основание для разработки

[2.6] 2.2. Назначение разработки

[2.7] 2.3. Требования к разрабатываемому ПО

[2.7.1] 2.3.1. Требования к функциональным характеристикам

[2.7.2] 2.3.2. Требования к надежности

[2.7.3] 2.3.3. Условия эксплуатации

[2.7.4] 2.3.4. Требования к составу и параметрам технических средств

[2.7.5] 2.3.5. Требования к информационной и программной совместимости

[2.8] 2.4. Этапы разработки

[2.8.1] 2.4.1. Стадии разработки

[2.8.2] 2.4.2. Содержание работ по этапам

[2.9] 2.5. Порядок контроля и приемки

[2.9.1] 2.5.1. Виды испытаний

[2.9.2] 2.5.2. Общие требования к приемке работы  

[2.10] 2.6. Требования к программной документации

[2.10.1] 2.6.1. Руководство администратора

[2.10.2] 2.6.2. Руководство пользователя

[3]
3. Исследовательская часть

[3.1] 3.1. Цели и задачи исследования

[3.2] 3.2. Исследование существующих технологий в различных СУБД

[3.2.1] 3.2.1. Организация защиты данных в MS Access

[3.2.2] 3.2.2. Безопасность данных в Oracle 7

[3.2.3] 3.2.3. Организация защиты данных в MS SQL SERVER

[3.3] 3.3. Выводы и результаты исследования

[4]
4. Конструкторская часть

[4.1] 4.1. Архитектура программной системы

[4.2] 4.2. Обоснование выбора средств разработки

[4.3] 4.3. Проектные модели данных

[4.3.1] 4.3.1. Подсистема АРМа врача-стоматолога

[4.3.2] 4.3.2. Подсистема АРМа работников регистратуры  

[4.4] 4.6. Проектирование интерфейса

[5]
5. Техническая документация

[5.1] 5.1. Руководство администратора

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

[6]
6. Экспериментальная часть

[6.1] 6.1. Описание методики тестирования

[6.2] 6.2. Тест работы в штатных условиях

[6.3] 6.3. Нагрузочное тестирование

[6.4] 6.4. Тестирование в исключительных ситуациях

[6.5] 6.5. Оценка полноты тестирования системы

[7]
7. ЭКОНОМИЧЕСКАЯ ЧАСТЬ

[7.1] 7.1. Обоснование необходимости и актуальности работы

[7.2] 7.2. Оценка рынка сбыта

[7.3] 7.3. Расчет времени на создание программного продукта

[7.4] 7.4. Расчет заработной платы исполнителей работ по созданию программного продукта

[7.5] 7.5. Расчет начислений на заработную плату

[7.6] 7.6. Затраты на эксплуатацию ЭВМ

[7.7] 7.7. Расчет себестоимости программного продукта

[7.8] 7.8. Расчет цены программного продукта

[7.9] 7.9. Оценка эффективности внедрения программной системы

[8]
8. Безопасность и экологичность проекта

[8.1] 8.1. Анализ опасных и вредных факторов

[8.2] 8.2. Требования к эксплуатации

[8.3] 8.3. Разработка мер защиты от опасных и вредных факторов

[8.4] 8.4. Экологическая оценка компьютера как объекта загрязнения окружающей среды

[8.5] 8.5. Выводы

[9]
Заключение

[10]
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

[11] ПРИЛОЖЕНИЯ


Введение

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

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

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

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

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

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

Объектом исследования является работа стоматологической поликлиники «Мастер-дент».

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


1. Аналитическая часть

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

1.1. Описание процесса работы стоматологической поликлиники «Мастер-дент»

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

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

Поликлиника работает по трем основным направлениям:

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

Структурная схема стоматологической поликлиники «Мастер-дент» представлена на рис. 1.1

Рис. 1.1. Организационная структура

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

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

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

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

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

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

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

Рис. 1.2. Кадровая структура

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

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

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

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

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

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

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

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

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

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

1.2. Функциональное моделирование процесса работы стоматологической поликлиники «Мастер-дент»

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

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

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

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

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

  •  работа регистратуры;  
  •  работа врача-стоматолога;
  •  работа ассистентов врача-стоматолога.

Функциональная модель представлена на рис. 1.2-1.6.

Как видно из рис. 1.3, основным процессом для разрабатываемой модели является непосредственный процесс «Работы стоматологической поликлиники». Эта работа процесс разбивается на работу регистратуры, врача-стоматолога и его ассистентов (рис. 1.4).  

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

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

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







1.3. Обзор программ - аналогов

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

Система АИС «Стоматолог» (рис 1.8): программа предназначена для автоматизации работы стоматологических кабинетов и клиник.

Основные возможности программы:

  •  Предварительный заказ материалов.
  •  Терапевтическое лечение пациентов.
  •  Финансовый отчёт (можно создать по конкретному врачу и дате).
  •  Журнал посещений.
  •  Чековый отчёт (можно создать по конкретной дате).
  •  Предварительный расчёт пациента.
  •  Возможно введение индивидуальной формулы оплаты для персонала.

Рис. 1.8. Интерфейс программы «Стоматолог»

Цена на данное программное обеспечение составляет примерно 1150 долларов США, что приблизительно составляет 33920 тысяч рублей.

Программа "Dental 4 Windows"(рис 1.9): программа для автоматизации работы стоматологической клиники (practice management software). Была первой в Астралии, разработанной для среды Windows 3.1. Первая в мире программа для стоматологии на базе SQL-сервера (1997 г.). Разработана стоматологами для стоматологов. Самая распространенная стоматологическая программа в Австралии (более 2000 клиник). Наибольшее число внедрений в России и странах бывшего СССР (более 600 клиентов с 1996 года). На сегодняшний день программа Dental 4 Windows - это оптимальное решение как индивидуально для врача-стоматолога, так и для клиники любого типа - государственной, частной, госпиталя или сети клиник. Успешно работает в поликлиниках и медицинских центрах. Основные модули программы: регистратура, касса, план/факт лечения, связь с RVG, модуль маркетинга, бизнес-аналитика, SMS-напоминания с возможностью обратной связи. Программа чрезвычайно гибкая, имеет несколько схем внедрения.

Как утверждает разработчик, стоимость владения программой невысока, экономический эффект наступает уже через несколько месяцев после внедрения. Срок полной окупаемости составляет около 1 года. Цена на данную программную разработку составляет 18920 рублей на одно рабочее место. Российская компания ООО "Сентор Софтвер" осуществляет полную поддержку.

Рис. 1.9. Интерфейс программы "Dental 4 Windows"

1С:Стоматология(рис. 1.10) – программа для автоматизации стоматологической клиники. К её преимуществам можно отнести:

  •  Сочетает управление лечебным процессом и административное управление клиникой.
  •  Учитывает все этапы работы клиники;
  •  Предоставляет возможность индивидуальной настройки;
  •  Надежно работает в крупных компьютерных сетях;
  •  Интегрируется с базой 1С: Бухгалтерия;
  •  Имеет удобный интерфейс.

Далее в таблице1.1. приведена стоимость программного комплекса.

Описание

цена

Базовая конфигурация на 1 пользователя.

4400

Подключение дополнительного пользователя.

800

Базовая конфигурация на неограниченное количество пользователей.

10000

Компонента учета материалов (требуется для списания материалов).

1400

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

1200

Справочник по диагнозам.

1000

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

550

Таблица 1.1. Цены на программу «1С:Стоматология»

В ценах не учтена стоимость платформы "1С: Предприятие 7.7". Стоимость платформы составляет 25000 рублей.  Приблизительная стоимость "1С: Предприятие 7.7" для работы в компьютерной сети составляет 480 $, локальная версия "1С: Предприятие 7.7" стоит примерно 240 $.

«Дентал-Софт» - компьютерная стоматологическая программа для частных практикующих врачей стоматологов или стоматологических клиник, как платных, так и работающих в системе ОМС. Программа предназначена для автоматизации документооборота стоматологического кабинета и ведения электронных медицинских карт стоматологического пациента. Компьютерная программа для стоматологии разработана на языке программирования MS Visual C++ 2010, в качестве хранилища данных может использоваться MS Access, MySQL Server или MS SQL Server.

Стоимость данной программы порядка 40000 тысяч рублей.

Результаты сравнения программ-аналогов приведены в табл. 1.2.


1.4. Выводы

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

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

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

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

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

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

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

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

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

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

Объектом исследования является работа стоматологической поликлиники «Мастер-дент».

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


2. ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Данная работа направлена на разработку автоматизированной системы стоматологической поликлиники с использованием баз данных (БД) на примере работы «Мастер-дент»

2.1. Основание для разработки 

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

Основной задачей «Мастер-дент» являются удовлетворение потребностей населения в лечении стоматологических заболеваний, зубопротезировании, повышении качества диагностики и лечения стоматологических заболеваний.

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

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

Основанием для разработки автоматизированной системы кардиологического отделения Брянского областного кардиологического диспансера является задание на дипломную работу, выданное
доц. Лагеревым Д.Г., на основе приказа ректора БГТУ проф. Лагерева А.В.
«О допуске к дипломному проектированию, утверждению тем дипломных работ и руководителей» от
?????????????????????.

2.2. Назначение разработки

Автоматизированная система предназначена для использования врачами и средним медицинским персоналом.

Она должна позволять:

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

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

2.3. Требования к разрабатываемому ПО 

К разрабатываемой системе предъявляются следующие требования:

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

2.3.1. Требования к функциональным характеристикам 

Данная АС должна обеспечивать:

  •  Хранение данных, необходимых для работы системы: о пациентах (фамилия, имя, отчество, дата рождения, номер и серия паспорта, дата первичного обращения), о медицинском персонале (фамилия, имя, отчество, дата рождения, номер и серия паспорта, должность, отделение), о назначенных процедурах и медикаментах (название, дозировка, частота приема или проведения).
  •  Возможность просмотра истории болезни пациента.
  •  Возможность редактирования основного и сопутствующего диагноза.
  •  Наличие возможности назначения анализов.
  •  Наличие возможности назначения процедур.
  •  Наличие возможности настройки внешнего вида программы.
  •  Возможность создания расписания для предварительной записи на приём.
  •  Осуществление поиска необходимых данных.
  •  Осуществление сортировки данных.
  •  Возможность составления отчетов о занятости врачей.
  •  Возможность печати бланков с картой зубов.
  •  Составление и печать договора о предоставляемых услугах.
  •  Обеспечение пользователя правовой и справочной информацией.
  •  Наличие возможности построения отчетов в виде выписки
    из истории болезни. При этом необходима поддержка правильности заполнения полей в зарегистрированных нормами формах.
  •  Возможность восстановления данных в случае непредвиденных сбоев, таких как отключение электроэнергии и так далее.
  •  Запрет на завершение работы в случае, если это может повлечь нарушение целостности данных.
  •  Поддержку клиент-серверной архитектуры.
  •  Защиту от несанкционированного доступа к системе. Каждый пользователь должен иметь свой логин и пароль.

2.3.2. Требования к надежности

Программа система должна обеспечивать:

  •  устойчивую и корректную работу в многозадачной среде Windows XP/2003/Vista/7;
  •  ошибки входных данных не должны приводить к некорректной работе, порче информации или зависанию программы;
  •  все ошибки должны отображаться, желательно с комментариями или подсказками по их устранению;
  •  гарантировать надёжность сохранности данных под влиянием некорректной работы внешних устройств;
  •  фиксировать в журнале изменения данных все основные операции над данными, а также информацию о самих пользователях, действия которых приводят к изменению или порче данных.

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

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

2.3.3. Условия эксплуатации 

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

2.3.4. Требования к составу и параметрам технических средств 

Данная автоматизированная система спроектирована с учетом имеющегося в «Мастер-дент» оборудования и требует обеспечения следующих технических характеристик.

Для клиентской части:

  •  минимальные требования к процессору – платформа х86 с тактовой частотой не ниже 800 МГц;
  •  минимальный объем оперативной памяти RAM 1024 Мб;
  •  минимальное пространство на диске HDD 50 Гб;
  •  видеоадаптер SVGA;
  •  поддерживаемое разрешение 800 х 600;
  •  клавиатура;
  •  сетевой адаптер;
  •  подключенный принтер, локальный или сетевой;
  •  наличие сетевого оборудования и загруженного программного обеспечения для работы в сети;
  •  CD-ROM; 
  •  манипулятор мышь.

Для серверной части:

  •  минимальные требования к процессору – платформа х86 с тактовой частотой не ниже 1,45 ГГц;
  •  минимальный объем оперативной памяти RAM 4096 Мб;
  •  минимальное пространство на диске HDD 500 Гб;
  •  видеоадаптер SVGA;
  •  поддерживаемое разрешение 800 х 600;
  •  клавиатура;
  •  сетевой адаптер;
  •  CD-ROM.

2.3.5. Требования к информационной и программной совместимости 

Разработанное программное обеспечение (ПО) функционирует
на платформе
Win32 (Windows XP/2003/Vista/7). Так же необходимо наличие установленного на сервере Microsoft SQL Server 2008 R2, а так же
Microsoft .NET Framework 3.5 и выше. Для работоспособности клиента необходим установленный Microsoft .NET Framework 3.5 и выше.

2.4. Этапы разработки 

В данном подпункте рассмотрены основные стадии и этапы разрабатываемой АС.

2.4.1. Стадии разработки 

Разработка должна быть проведена в три стадии:

  •  системный анализ;
  •  проектирование и разработка;
  •  внедрение.

2.4.2. Содержание работ по этапам 

В соответствии с международным стандартом ISO/IEC 12207 [24], регламентирующим жизненный цикл программного обеспечения,
при разработке АС для автоматизации деятельности стоматологической поликлиники были выделены следующие этапы и работы.

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

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

На этапе разработки программы должны быть выполнены перечисленные ниже работы:

  •  выбор архитектуры программной системы;
  •  выбор средств разработки (среда разработки, язык программирования, СУБД);
  •  разработка приложения;
  •  отладка программной системы.

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

На этапе испытаний программы должны быть выполнены перечисленные ниже работы:

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

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

2.5. Порядок контроля и приемки 

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

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

2.5.1. Виды испытаний 

Автоматизированная система должна пройти следующие виды испытаний:

• предварительные;

• опытная эксплуатация;

• приемочные.

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

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

Ход проведения приемо-сдаточных испытаний заказчик и исполнитель документируют в протоколе проведения испытаний.

2.5.2. Общие требования к приемке работы  

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

2.6. Требования к программной документации

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

2.6.1. Руководство администратора 

Руководство администратора содержит следующую информацию:

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

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

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

Руководство пользователя содержит следующую информацию:

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


3. Исследовательская часть

3.1. Цели и задачи исследования 

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

Задачами исследования являются:

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

Предметом исследования является …….

Объектом исследования является…..

3.2. Исследование существующих технологий в различных СУБД

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

Далее будут рассмотрены технологии защиты данных в различных СУБД.

3.2.1. Организация защиты данных в MS Access

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

Access хранит информацию о защите в двух местах. Во время установки программа Setup создаст в папке Program Files Microsoft Oficeffice стандартный файл рабочей группы (System.mdw), который впоследствии используется по умолчанию при запуске Access. Этот файл содержит информацию обо всех пользователях и группах. При создании базы данных Access сохраняет сведения о правах, предоставляемых конкретным пользователям и группам, в файле базы данных.Общая структура защиты Access отображена на рис. 3.2.1. Учётные записи пользователей и групп хранятся в файле рабочей группы. Разрешение на доступ к конкретным объектам сохраняются в файле базы данных.

Рис. 3.2.1. Общая структура защиты в СУБД MS Access

Расположение текущего файла рабочей группы хранится в реестре Windows. Можно использовать служебную программу Wrkadm.exe (администратор рабочих групп) для изменения текущего или определения нового файла рабочей группы. Кроме того, можно выбирать нужный файл рабочей группы во время выполнения приложения, задав соответствующий параметр командной строки в ярлыке запуска. Если вам приходится часто запускать в сети совместно используемое защищенное приложение, нужно позаботиться о том, чтобы системный администратор задал вашу рабочую группу, используемую по умолчанию, как общий файл в сетевой папке.

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

3.2.2. Безопасность данных в Oracle 7

Если существует уверенность, что подключаться к базе данных могут лишь уполномоченные пользователи и что они могут запускать только те модули, на выполнение которых им явно предоставлено право, то нужно подумать о следующем уровне безопасности - ограничении доступа этих пользователей к данным. Огромным шагом вперед в обеспечении безопасности данных стало введение ролей в Oracle7. До Oracle7 каждому пользователю приходилось явно предоставлять права доступа к каждому объекту базы данных, который ему разрешено было использовать. Этот процесс упрощается за счет того, что доступ к совокупности объектов предоставляется роли, а затем право на использование этой роли предоставляется соответствующим лицам. С помощью команды GRANT можно предоставить пользователям право выполнять над объектами БД (например, над таблицами) операции SELECT, INSERT, UPDATE и DELETE. Однако само по себе это не обеспечивает значительной гибкости. Можем ограничить доступ пользователей к частям таблицы, разделив ее по горизонтали (ограничив пользователя определенными строками), по вертикали (ограничив его определенными столбцами) или и по горизонтали, и по вертикали.

3.2.3. Организация защиты данных в MS SQL SERVER

В критических для бизнеса приложениях, когда сервер СУБД должен быть постоянно доступен для клиентов, большинство профилактических работ по поддержке базы данных приходится выполнять фактически в режиме on - line. MS SQL Server обладает возможностями динамического резервного копирования данных, т. е. даже когда эти данные используются и изменяются клиентами. В случае сбоя оборудования, отключения питания и т. д. механизм автоматического восстановления MS SQL Server восстанавливает все базы данных до их последнего целостного состояния без вмешательства администратора. Все завершенные, но не отраженные в базе транзакции из журнала транзакций применяются к базе данных (это фактически то, что происходит при событии chekpoint), а незавершенные транзакции, т. е. те, которые были активными на момент сбоя, вычищаются из журнала.

Операции резервного копирования и восстановления могут распараллеливаться на несколько потоков и выполняться одновременно, используя преимущества асинхронного ввода/вывода. На каждое резервное устройство отводится свой поток. Параллельное резервное копирование поддерживает до 32 одновременных резервных устройств (backup devices), что позволяет быстро создавать страховочные копии баз данных даже очень большой емкости. Возможность резервного копирования и восстановления отдельных таблиц, о чем мы упоминали, рассматривая Transact-SQL, позволяет экономить место и время, не выполняя копирование всей базы ради только некоторых ее объектов.

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

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

В отличие от резервирования базы данных дамп журнала транзакций очищает его неактивную часть, т. е. все завершившиеся (зафиксированные или абортированные) с момента последнего дампа транзакции, если только не использована опция NO_TRUNCATE. Команда DUMP TRANSACTION TRUNCATE_ONLY, очищающая журнал транзакций, полезна в случае его переполнения, которое можно контролировать, например, оператором DBCC SQLPERF (LOGSPACE). Если степень переполнения журнала очень высока, можно при его очистке отказаться от журналирования факта самого этого события: DUMP TRANSACTION NO_LOG. Если резервное копирование транзакций не представляет интереса, можно включить опцию очистки последних завершенных транзакций в базе по наступлению события checkpoint. Cмысл механизма checkpoint состоит в периодической записи данных из кэша на диск, чтобы не допускать грязных данных.

Такого рода события постоянно генерируются MS SQL Server или возникают по инициативе пользователя. Включенная опция truncate log on checkpoint гарантирует выполнение с определенной частотой обработчиком события действий, приблизительно эквивалентных команде DUMP TRANSACTION TRUNCATE_ONLY.При восстановлении журнала транзакций соответствующие транзакции применяются к базе данных. Это означает, что если в начале недели была сделана резервная копия всей базы, а потом ежедневно архивировались транзакции за каждый день, то при необходимости восстановления поднимается состояние базы на начало недели и на него последовательно накатываются дампы журнала транзакций за все дни, предшествующие моменту восстановления. MS SQL Server 6.5 имеет возможность восстановления данных из журнала транзакций на произвольный момент времени (разумеется, отраженный в журнале) при помощи команды LOAD TRANSACTION STOPAT или в окне database backup and restore выбором опции until time. Все содержащиеся в этом дампе транзакции, отмеченные завершившимися после этого момента, будут откачены. Возможность планирования задач резервного копирования во времени и отсылки сообщений по e-mail в случае успешного/неуспешного завершения рассматривалась нами при обсуждении SQL Executive.

MS SQL Server предусматривает возможность зеркалирования устройств, переключения на зеркальные устройства в качестве основных, выключения зеркалирования и уничтожения зеркального устройства также "на лету", т. е. без остановки штатной работы сервера по обслуживанию пользовательских запросов. Зеркалирование и дуплексирование устройств для работы с MS SQL Server может быть также выполнено средствами Windows NT, а также на аппаратном уровне (поддержка различных RAID-систем и т. д.). По-видимому, следует предполагать, что реализация первого этапа кластерной технологии WolfPack будет поддерживать MS SQL Server 6.5 в отказоустойчивых кластерах из двух узлов. Появление следующей версии MS SQL Server должно обеспечить работу серверов в кластере как единого виртуального сервера.Transfer Manager используется для экспорта/импорта объектов и данных БД на MS SQL Server между разными аппаратными платформами, например между процессорами Intel и Alpha, а также между разными версиями MS SQL Server, в частности из более ранних в более поздние или между равноценными.

Очень часто проектирование объектов базы ведется с помощью различных графических средств, но проектная документация может требовать структуру объектов с точностью до операторов DDL. Для получения скриптов, описывающих создание отдельного объекта базы данных, можно использовать команду transfer из контекстного меню объекта или выбрать соответствующий класс и имя объекта в Transfer Manager. Кроме этого, содержимое данных может быть выгружено/загружено при помощи утилиты bcp.

Говоря о преимуществах интеграции с операционной системой, MS SQL Server использует в своей работе сервисы безопасности Windows NT. Windows NT на сегодня сертифицирована по классам безопасности С2/Е3. MS SQL Server может быть настроен на работу в одном из трех режимах безопасности. Интегрированный режим предусматривает использование механизмов аутентификации Windows NT для обеспечения безопасности всех пользовательских соединений. В этом случае к серверу разрешаются только трастовые, или аутентифицирующие, соединения (named pipes и multiprotocol). Администратор имеет возможность отобразить группы пользователей Windows NT на соответствующие значения login id MS SQL Server при помощи утилиты SQL Security Manager. В этом случае при входе на MS SQL Server login name и пароль, переданные через DB-Library или ODBC, игнорируются. Стандартный режим безопасности предполагает, что на MS SQL Server будут заводиться самостоятельные login id и соответствующие им пароли. Смешанный режим использует интегрированную модель при установлении соединений по поименованным каналам или мультипротоколу и стандартную модель во всех остальных случаях.

MS SQL Server обеспечивает многоуровневую проверку привилегий при загрузке на сервер. Сначала идентифицируются права пользователя на установление соединения с выбранным сервером (login name и пароль) и выполнение административных функций: создание устройств и баз данных, назначение прав другим пользователям, изменение параметров настройки сервера и т.д. Максимальными правами обладает системный администратор. На уровне базы данных каждый пользователь, загрузившийся на сервер, может иметь имя пользователя (username) базы и права на доступ к объектам внутри нее. Имеется возможность отобразить нескольких login id на одного пользователя базы данных, а также объединять пользователей в группы для удобства администрирования и назначения сходных привилегий. По отношению к объектам базы данных пользователю могут быть назначены права на выполнение различных операций над ними: чтение, добавление, удаление, изменение, декларативная ссылочная целостность (DRI), выполнение хранимых процедур, а также права на доступ к отдельным полям. Если этого недостаточно, можно прибегнуть к представлениям (views), для которых сказанное остается справедливым. Наконец, можно вообще запретить пользователю непосредственный доступ к данным, оставив за ним лишь права на выполнение хранимых процедур, в которых будет прописан весь сценарий его доступа к базе. Хранимые процедуры могут создаваться с опцией WITH ENCRYPTION, которая шифрует непосредственный текст процедуры, хранящийся обычно в syscomments. Права на выполнение некоторых команд (создание баз, таблиц, умолчаний, правил, представлений, процедур, резервное копирование баз и журналов транзакций) не являются объектно-специфичными, поэтому они назначаются системным администратором сервера или владельцем (создателем) базы данных при редактировании базы данных.

Администрирование пользовательских привилегий обычно ведется в SQL Enterprise Manager, тем не менее в Transact-SQL имеются хранимые процедуры (sp_addlogin, sp_password, sp_revokelogin, sp_addalias, sp_adduser) и операторы (GRANT, REVOKE), которые позволяют осуществлять действия по созданию пользователей, назначению и отмене прав при выполнении скриптов. Дополнительную возможность администрирования привилегий предоставляют рассмотренные нами выше SQL-DMO.

Объектные права доступа позволяют контролировать доступ к объектам в SQL Server, предоставляя и аннулируя права доступа для таблиц, столбцов, представлений и хранимых процедур. Чтобы выполнить по отношению к некоторому объекту некоторое действие, пользователь должен иметь соответствующее право доступа. Например, если пользователь хочет выполнить оператор SELECT * FROM table, то он должен и меть права выполнения оператора SELECT для таблицы table. Командные права доступа определяет тех пользователей, которые могут выполнять административные действия, например, создавать или копировать базу данных.

Ниже приведены командные права доступа:

CREATE DATABASE - право создания базы данных;

CREATE DEFAULT - право создания стандартного значения для столбца таблицы;

CREATE PROCEDURE - право создания хранимой процедуры.

CREATE TABLE - право создания таблицы;

CREATE VIEW - право создания представления;

BACKUP DATABASE - право создания резервной копии;

BACKUP TRANSACTION - право создания резервной копии журнала транзакций.

3.3. Выводы и результаты исследования

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

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

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


4. Конструкторская часть

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

4.1. Архитектура программной системы

В основе разрабатываемой АС лежит клиент-серверная
архитектура (рис. 4.1).

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

Данная архитектура обладает рядом достоинств:

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

Наряду с достоинствами, существуют и недостатки архитектуры:

  •  Неработоспособность сервера может сделать неработоспособной всю вычислительную сеть.
  •  Поддержка работы данной системы требует отдельного специалиста – системного администратора.
  •  Высокая стоимость оборудования.

На основании предложенной архитектуры программной системы дальнейшее описание будет построено с учетом разделения основных составных систем разрабатываемого программного продукта на 2 подсистемы: подсистема «АРМ врача-стоматолога» и подсистема «АРМ работника регистратуры».

4.2. Обоснование выбора средств разработки 

Для разработки автоматизированной системы стоматологической поликлиники «Мастер-Дент» можно использовать следующие языки программирования:

  •  Delphi;  
  •  C#;  
  •  C++.

Delphi – среда программирования, в которой используется язык программирования Object Pascal. Начиная со среды разработки Delphi 7.0,
в официальных документах Borland стала использовать название Delphi
для обозначения языка Object Pascal. Начиная с 2007 года уже язык Delphi (производный от Object Pascal) начал жить своей самостоятельной жизнью
и претерпевал различные изменения связанные с современными тенденциями (например, с развитием платформы .net) развития языков программирования.

Язык C# – объектно-ориентированный язык программирования. Разработан в 1998-2001 годах группой инженеров под руководством Андерса Хейлсберга в компании Microsoft как основной язык разработки приложений
для платформы Microsoft .NET Framework и впоследствии был стандартизирован как ECMA-334 и ISO/IEC 23270. Компилятор C# входит
в стандартную установку .NET Framework.

C# относится к семье языков с C-подобным синтаксисом,
из них его синтаксис наиболее близок к C++ и Java. Язык имеет статическую типизацию, поддерживает полиморфизм, перегрузку операторов (в том числе операторов явного и неявного приведения типа), делегаты, атрибуты, события, свойства, обобщённые типы и методы, итераторы, анонимные функции
с поддержкой замыканий, LINQ, исключения, комментарии в формате XML.

В язык C# входит много полезных особенностей – простота, объектная ориентированность, типовая защищенность, «сборка мусора», поддержка совместимости версий и многое другое.

Язык C++ – компилируемый статически типизированный язык программирования общего назначения. Поддерживая разные парадигмы программирования, сочетает свойства как высокоуровневых,
так и низкоуровневых языков. В сравнении с его предшественником – языком C, – наибольшее внимание уделено поддержке объектно-ориентированного
и обобщённого программирования. Название «C++» происходит от языка C,
в котором унарный оператор ++ обозначает инкремент переменной.

Область его применения включает создание операционных систем, разнообразных прикладных программ, драйверов устройств, приложений
для встраиваемых систем, высокопроизводительных серверов, а также развлекательных приложений (например, видеоигры). Существует несколько реализаций языка C++ — как бесплатных, так и коммерческих. Их производят Проект GNU, Microsoft, Intel и Embarcadero (Borland). C++ оказал огромное влияние на другие языки программирования, в первую очередь на Java и C#.

Таким образом, для разработки автоматизированной системы стоматологической поликлиники «Мастер-дент» был выбран язык C++.

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

  •  Microsoft Visual Studio 2008;
  •  Borland C#Builder 2006.

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

Microsoft Visual Studio 2008 включает новые возможности,
такие как наглядные средства разработки для более быстрой работы с .NET Framework 3.5, улучшенные средства разработки веб-приложений и улучшения языков, ускоряющие работу со всеми типами данных.

Borland C#Builder 2006 – эффективная среда разработки приложений
для Microsoft Windows. Предоставляет функции корпоративной разработки, например, UML-моделирование, управление жизненным циклом проекта. Borland C#Builder 2006 сокращает время и затраты на разработку корпоративных .NET приложений при помощи интегрированных инструментов аудита и метрик, управления требованиями и исходным кодом. Упрощает разработку баз данных с поддержкой функции перетаскивания, управления схемами и переноса данных.

C#Builder 2006 входит в состав Borland Developer Studio - многоязычной среды разработки приложений компании Borland для приложений Microsoft Windows и .NET. Borland C#Builder 2006 дополняет эту общепризнанную среду быстрой разработки приложений новыми настраиваемыми направляющими для автоматического выравнивания, оперативной системой шаблонов кода, интеллектуальным завершением блоков, машинами состояния ECO и др.

В итоге для разработки автоматизированной системы стоматологической поликлиники «Мастер-дент» была выбрана среда Borland C#Builder 2006.

Для проектирования базы данных были рассмотрены следующие системы управления базами данных (СУБД):

  •  Microsoft Office Access 2003;
  •  My SQL 5.5;
  •  Microsoft SQL Server 2008 R2.

Microsoft Office Access или просто Microsoft Access – реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.

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

MySQL 5.5 – свободная система управления базами данных. MySQL 5.5 является собственностью компании Oracle Corporation, получившей её вместе
с поглощённой Sun Microsystems, осуществляющей разработку и поддержку приложения. Помимо этого разработчики создают функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

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

Гибкость СУБД MySQL 5.5 обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL 5.5 поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц.

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

Microsoft SQL Server 2008 – система управления реляционными базами данных, разработанная корпорацией Microsoft . Основной используемый язык запросов – Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия; конкурирует с другими СУБД в этом сегменте рынка.

SQL Server 2008 в сочетании с .NET Framework упрощает разработку новых приложений. Среда ADO.NET Entity Framework повышает эффективность труда разработчиков, поскольку теперь они имеют дело
не непосредственно с таблицами и полями, а с логическими информационными сущностями, согласованными с бизнес-требованиями. Более того, они могут создавать приложения, позволяющие пользователям копировать данные
на собственные устройства, а позже синхронизовать их с центральными серверами. Инфраструктура SQL Server 2008 стала более масштабируемой.
Она способна формировать отчеты и выполнять анализ любого объема
и сложности, одновременно облегчая пользователям доступ к данным за счет более тесной интеграции с Microsoft Office .

Так же в Microsoft SQL Server 2008 есть возможность работы
как со скриптами, так и в графическом интерфейсе, что существенно упрощает работу.

Последняя версия SQL Server – SQL Server 2008 R2. Была выпущена
21 апреля 2010 года.

Для второго выпуск (R2) также доступные следующие расширенные
по функциональным возможностям (по сравнению с
Enterprise) редакции:

  •      Datacenter;
  •      Parallel Data Warehouse.

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

В SQL Server 2008 была добавлена поддержка структурированных
и частично структурированных данных, включая цифровые форматы для изображений, звуков, видео и других типов мультимедиа. Поддержка мультимедиа-форматов внутри СУБД позволила специализированным функциям взаимодействовать с этими типами данных.

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

Для повышения эффективности администрирования в SQL Server были включены библиотеки Declarative Management Framework, позволяющие распределять полномочия для баз данных или отдельных таблиц. Были улучшены методы компрессии данных. SQL Server Katmai поддерживает набор библиотек ADO.NET Entity Framework и средства оповещения, репликации
и определения данных.

В процессе сравнения СУБД было принято решение об использовании  Microsoft SQL Server 2008 R2.

Таким образом, в качестве инструментальных средств разработки автоматизированной системы стоматологической поликлиники «Мастер-дент»  были выбраны следующие:

  •  Среда разработки Borland C#Builder 2006, язык С++;
  •  Microsoft SQL Server 2008.

4.3. Проектные модели данных

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

Метод структурного проектирования предполагает построение моделей, иллюстрирующих функции, выполняемые системой, которая представлена
с помощью
DFD-модели потоков данных.  

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

4.3.1. Подсистема АРМа врача-стоматолога 

Контекстная диаграмма для моделирования работы врача-стоматолога представлена на рис. 4.2.

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

Сбор данных осуществляется на основе осмотра пациента и полученных результатов проведенных анализов и диагностик. Все эти сведенья заносятся в историю болезни пациента (рис. 4.4).  

Рис. 4.2. Контекстная диаграмма модели потоков данных

АРМа врача-стоматолога

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

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

 

 

 

Рис. 4.5. Диаграмма 2-го уровня модели потоков данных. Анализ полученных данных

Рис. 4.6. Диаграмма 2-го уровня модели потоков данных. Корректировка лечения

4.3.2. Подсистема АРМа работников регистратуры  

Контекстная диаграмма для моделирования работы сотрудников регистратуры, работающих в стоматологической поликлиники «Мастер-дент», представлена на рис. 4.7.

Рис. 4.7. Контекстная диаграмма модели потоков данных
АРМа сотрудников регистратуры

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

Рис. 4.8. Диаграмма 1-го уровня АРМа сотрудников регистратуры

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

Рис. 4.9. Диаграмма 2-го уровня АРМа сотрудников регистратуры

4.4. Логическое моделирование 

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

В логической модели представленной программной системы присутствуют следующие основные сущности:

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

Схема спроектированной на Microsoft SQL Server 2008 [9] базы данных, представлена на рис. 4.11.  



4.5. Алгоритмическое конструирование 

Фрагмент блок-схемы изображен на рис. 4.12. В ней описан пример работы системы.

 

Рис. 4.12. Фрагмент блок-схемы

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

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

После выполнения необходимых операций производится выход
из системы.

На рис. 4.13 представлен алгоритм работы врача
при поступлении пациента. В случае вторичного обращения врач делает запрос на получение прошлой истории болезни для оценки динамики состояния пациента и анализа успешности выбранного ранее лечения. Далее создается новая история болезни.

Исходя из своего опыта, врач определяет, верен ли диагноз, поставленный пациенту при поступлении. Если диагноз не верен или не ясен, кардиолог назначает дополнительные анализы и, исходя из их результата, корректирует диагноз.

Далее производятся различные назначения.

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

Рис. 4.13. Алгоритм работы врача при поступлении пациента

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

В данном пункте представлен интерфейс разработанной системы.

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

Рис. 4.14. Главное окно программы

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

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

  •  жалобы;
  •  анамнез;
  •  лечение;
  •  зубная карта.   

Рис. 4.15. Электронная история болезни

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

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

Рис. 4.17. Выбор цвета для обозначения болезни

Рис. 4.16. Печатный вид полной карточки пациента


5. Техническая документация

В состав программной документации входят следующие документы:

  •  руководство системного администратора;
  •  руководство пользователя.

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

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

5.1. Руководство администратора 

Для установки автоматизированной системы стоматологической поликлиники необходимо открыть установочный диск, на котором записаны 2 файла:  Install_Master-dent.exe и папка «for SQL Server». На компьютер, который устанавливается система, должна быть установлена СУБД SQL Server, которая является бесплатной (за исключением некоторых коммерческих версий).

После запуска файла Install_Master-dent.exe начинается установка программы в выбранную администратором папку (рис. 5.1).

Рис. 5.1. Начало установки

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

Рис. 5.2. Информирование об ответственности за нарушение авторских прав

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

После завершения установки необходимо перезагрузить компьютер.

Администратор назначает логин и пароль для каждого из сотрудников (рис. 5.3).

Рис. 5.3. Регистрация и настройка пользователей

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

Рис. 5.3. Статистика посещений

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

После запуска приложения появляется окно авторизации – приглашение ввести имя пользователя и пароль для входа в систему (рис.5.3).

Рис. 5.3. Окно авторизации

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

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

Рис. 5.5. Создание расписания врача

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

Рис. 5.6. Список пациентов на приём

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


6. Экспериментальная часть

В данной части описаны основные понятия и принципы тестирования ПО, также предоставлен набор тестов для будущей системы.

6.1. Описание методики тестирования

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

В традиционной форме классификация методов тестирования основана
на разделении методов на две категории – «черный ящик» (функциональное)
и «белый» (структурное) – и учитывает только два подхода к проектированию тестов [5].

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

6.2. Тест работы в штатных условиях

Данный вид тестирования предполагает проверку работоспособности системы на наличие ошибок при выполнении стандартного набора функций. При тестировании системы были заполнены все основные справочники:

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

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

При тестировании проверялись следующие функции:

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

Проведенное тестирование подтвердило корректность работы системы
в штатных условиях.

В случае несанкционированной попытки войти в систему или в случае некорректного заполнения полей логина или пароля появляется сообщение
о соответствующей ошибке (рис. 6.1).

Рис. 6.1. Ошибка входа в систему

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

Рис. 6.2. Ошибка: некорректный ввод данных

6.3. Нагрузочное тестирование 

Нагрузочное тестирование применяется для анализа работы АС
на различных уровнях нагрузки.

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

В случае, если пользователь попытается закрыть программу в момент «зависания», система выдает предупреждающее сообщение (рис. 6.3).

Рис. 6.3. Предупреждающее сообщение

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

Рис. 6.5. Ошибка: одновременное редактирование несколькими пользователями системы

Установление верхнего предела записей в таблицы базы данных
не представляется возможным.

6.4. Тестирование в исключительных ситуациях 

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

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

Рис. 6.6. Ошибка: отсутствие доступа к БД

6.5. Оценка полноты тестирования системы 

В ходе тестирования была проведена проверка корректности
и работоспособности автоматизированной системы стоматологической поликлиники «Мастер-дент».

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

Таким образом, тестирование было проведено в полном объеме
и полностью доказывает корректность работы автоматизированной системы стоматологической поликлиники «Мастер-дент».


7. ЭКОНОМИЧЕСКАЯ ЧАСТЬ

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

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

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

Цель дипломной работы – автоматизировать работу стоматологической поликлиники «Мастер-дент». Автоматизированная система предназначена для обеспечения удобства работы персонала и сокращения бумажного документооборота.

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

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

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

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

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

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

В представленной АС все эти недостатки отсутствуют, и можно говорить о достаточной универсальности системы.

7.2. Оценка рынка сбыта

АС рассчитана на внедрение в медицинские учреждения.

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

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

7.3. Расчет времени на создание программного продукта

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

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

Таблица 7.1

Перечень этапов разработки: структура времени, затраченного на создание программного продукта

№ этапа

Обозначение

Содержание

1

Tp

Анализ предметной области

2

To

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

3

Ta

Проектирование архитектуры

4

Tf

Разработка алгоритмов

5

Tr

Разработка алгоритмов

6

Tc

Кодирование

7

Tt

Отладка и тестирование

8

Td

Документирование

Расчет данных показателей производится в человеко-часах. Время Tp, затраченное на анализ предметной области, определяется фактическими величинами (реальные затраты времени разработчика). Базой для расчета остальных показателей служит условное число команд Q, которое может быть найдено по следующей формуле:

,                                                     (7.1)

где q – коэффициент, учитывающий условное число команд в зависимости
от типа задачи;
с – коэффициент, учитывающий новизну и сложность задачи.

Существует предопределенный набор значений указанных коэффициентов для различных типов задач (табл. 7.2)

Таблица 7.2

Значения коэффициента q для различных типов задач

Тип задачи

Пределы изменений коэффициента

Задачи учета

от 1 400 до 1 500

Задачи оперативного управления

от 1 500 до 1 700

Задачи планирования

от 3 000 до 3 500

Многовариантные задачи

от 4 500 до 5 000

Комплексные задачи

от 5 000 до 5 500

Для данной задачи коэффициент q принимается равным 4 500.

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

  1.  «А» – разработка принципиально новых задач.
  2.  «Б» – разработка оригинальных программ.
  3.  «В» – разработка программ с использованием типовых решений.
  4.  «Г» – разовая типовая задача.

Разработчик данного программного продукта оценивает степень новизны как высокую и относит его к классу «Б».

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

  1.  Задачи оптимизации и моделирования.
  2.  Задачи учета и статистики.
  3.  Типовые задачи (стандартные).

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

Пересечение двух показателей – новизны и сложности – определяет коэффициент с (табл. 7.3).

Таблица 7.3

Значения коэффициента с для различных типов задач

Язык программирования

Группа сложности

Степень новизны

А

Б

В

Г

Высокого уровня

1

1,38

1,26

1,15

0,69

2

1,30

1,19

1,08

0,65

3

1,20

1,10

1,00

0,60

Низкого уровня

1

1,58

1,45

1,32

0,79

2

1,49

1,37

1,24

0,74

3

1,38

1,26

1,15

0,69

Таким образом, для разработанного программного продукта (с учетом выбора высокоуровневого языка программирования) коэффициент с составляет 1,26. Исходя из найденных значений коэффициентов q и c, по формуле (7.1) условное число команд Q рассчитывается как произведение

Q = 4500 ∙ 1,26 = 5670.

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

  1.  Продолжительность анализа предметной области Tp берется как фактическая и составляет

Tp = 45 (чел./ч.).

  1.  Продолжительность постановки задачи To определяется по формуле

                                                            

где B – коэффициент учета изменений задачи, K – коэффициент, учитывающий квалификацию программиста.

Коэффициент B может принимать значения в интервале от 1,2 до 1,5
в зависимости от сложности задачи и числа изменений. Для данного проекта коэффициент учета изменений принимается равным 1,35.

Выбрать значение коэффициента K можно из табл.7.4.

Таблица 7.4

Значения коэффициента K

Стаж программиста

Значение коэффициента К

до 2-х лет

0,8

от 2 до 3 лет

1,0

от 3 до 5 лет

1,1-1,2

от 5 до 10 лет

1,2-1,3

свыше 10 лет

1,3-1,5

В данном случае коэффициент K = 1,2.

Таким образом, продолжительность постановки задачи по формуле (7.2) рассчитывается как

(чел./ч.).

  1.  Продолжительность проектирования архитектуры Ta определяется формулой

(чел./ч.).

  1.  Продолжительность разработки алгоритмов Tf определяется аналогично Ta по формуле (7.3) и составляет

Tf = 95 (чел./ч.).

  1.  Продолжительность реализации алгоритмов Tr определяется формулой:

                                                              

(чел./ч.).

  1.  Продолжительность кодирования Tc определяется формулой:

;                                                                 

(чел./ч.).

  1.  Продолжительность отладки и тестирования Tt определяется формулой:

;                                                               

(чел./ч.).

Продолжительность документирования Td берется как фактическая
и составляет:

Td = 60 (чел./ч.).

Итак, мы определили все компоненты общего времени, потраченного
на создание программного продукта (рис. 7.1).
 

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

T = Tp + To + Ta + Tf + Tc + Tt + Td;

Т = 45 + 128 + 95 + 95 + 142 + 113 + 397 + 60 = 1075 (чел./ч.).

Рис. 7.1. Структура временных затрат

7.4. Расчет заработной платы исполнителей работ по созданию программного продукта

Основная заработная плата исполнителя работ по созданию программного продукта (в данном случае программиста) определяется
по формуле:

,                                

где  – месячная зарплата, руб.;

– общее время на создание программного продукта, чел/час.;

– число рабочих дней в месяц;

– продолжительность рабочего дня, ч.;

– процент премии, %.

Месячная заработная плата исполнителя работ по созданию программного продукта определяется исходя из условий трудового договора, заключенного между исполнителем работ и руководителем организации
и составляет:

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

Общая заработная плата по созданию ПС будет равна заработной плате исполнителя.

7.5. Расчет начислений на заработную плату

Работники должны осуществлять страховые взносы в ПФР, ФСС, федеральный и территориальные ФОМСы. В 2011 году базовая ставка суммарного налога составляет 30% и распределяется между различными фондами (табл. 7.5).

Нзп = 0,30 ЗПобщ;                                                     

Нзп = 0,30 ∙ 83185 = 24956 (руб.).

Таблица 7.5

Структура отчислений ЕСН

Назначение

Ставка, %

Сумма, руб.

1

Отчисления в пенсионный фонд

22

18301

2

Отчисления на социальное страхование

2,9

2412,5

3

Отчисления на медицинское страхование

5,1

4242,5

Итого

30,0

24956

7.6. Затраты на эксплуатацию ЭВМ

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

1. Основная заработная плата работников, обеспечивающих функционирование ЭВМ.

К числу этих работников относятся: инженер-электроник и системный программист. ЗПгод каждого из этих категорий работников определяется
по формуле

,                               

где  – месячная зарплата, руб.;

– количество ЭВМ, обслуживаемых одним работником, ед.;

П  процент премии, .

Для инженеров-электроников руб.,  ед.

Для системных программистов руб.,  ед.

Подставляем значения в формулу 7.9, получаем

(руб.);

(руб.).

Теперь можно определить суммарную годовую заработную плату работников, обеспечивающих функционирование ЭВМ

(руб.).

2. Начисления на заработную плату обслуживающего персонала.

(руб.).

3. Амортизационные отчисления определяются в размере 25%
от балансовой стоимости оборудования

 А = 0, 25  Pb,       (7.10)

где Рь – балансовая стоимость одной ЭВМ с периферией.

Принимая балансовую стоимость оборудования Рь равной 28000 руб., получаем

А = 0, 25 28000 = 7000 (руб.).

4. Затраты на электроэнергию складываются из:

  •  затрат на силовую электроэнергию;
  •  затрат на электроэнергию для освещения.

Затраты на силовую электроэнергию определяются по формуле:

Зэc = Fe pe  Р ,      (7.11)

где Fe – эффективный годовой фонд времени работы техники в часах; pe – стоимость 1 кВт/ч в руб.; Р – суммарная мощность вычислительной техники
с периферией в кВт/ч.

Учитывая, что работа ведется в одну смену и в году 240 рабочих дней, Fe равен 1920 ч. Для коммерческих организаций pe равна 6,00 руб. за 1 кВт/ч. Суммарная мощность оборудования Р равна 1,0 кВт/ч.

По формуле (7.11) получаем

Зэc = 1920 6 1 = 11520 (руб.).

Затраты на электроэнергию для освещения определяются по формуле

 Зэо = Fe pe  Рo ,                (7.12)

где Fe – эффективный годовой фонд времени работы техники в часах; pe – стоимость 1 кВт/ч в руб.; Рo – суммарная мощность осветителей в кВт/ч.

Учитывая, что Ро = 0,2 кВт/ч, получаем:

Зэо = 1920 6 0,2 = 2304 (руб.).

Таким образом, общие затраты на электроэнергию составляют:

Зэ = Зэс + Зэо;

Зэ = 11520 + 2304 = 13824 (руб.).

5. Затраты на расходные материалы определяются по факту и составляют:

Зрм = 540 (руб.).

В их число входят

  •  компакт-диски (3 шт.), общей стоимостью 90 руб.;
  •  канцелярские товары, общей стоимостью 300 руб.;
  •  упаковка бумаги, стоимостью 150 руб.

6. Затраты на профилактику составляют 2% от балансовой стоимости вычислительной техники с периферией:

Зпр = 0, 02 28000 = 560 (руб.).

7. Затраты на отопление производственных площадей определяются
по формуле:

        Зот = pw  S  12,      (7.13)

где pw – расходы на отопление 1 м2 (8,20 руб./мес.); S – площадь, отводящаяся на одну ЭВМ (примем равной 6 м2). По формуле (7.13) получаем:

Зот = 8,20 6 12 = 590, 40 (руб.).

8. Затраты на обслуживание производственных площадей определяются по формуле

Зобс = ps  S  12,                 (7.14)

где ps – расходы на обслуживание 1 м2 (190 руб./мес.); S – площадь, отводящаяся на одну ЭВМ (6 м2). По формуле (7.14) получаем

Зобс = 190 6 12 = 13680 (руб.).

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

Зпроч = 0,3 ∙ ЗПосн;

Зпроч = 0,3 21667 = 6500,1 (руб.).

Определим суммарные годовые затраты на содержание и эксплуатацию 1-ой ЭВМ

Зобщ = ЗПгод + НЗП + А + Зэ + Зрм + Зпр + Зот + Зобс + Зпроч;

  Зобщ =  21667 +  7367  +  7000  +  13824  +  540  +  700  +  590,40  + 13680 +

+ 6500,1 = 71148,1 (руб.).

Далее определяем себестоимость 1-го часа работы оборудования

     (7.15)

где Fe – эффективный годовой фонд времени работы техники в часах.

(руб.).

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

Зэт = Смч Т, (7.16)

где Смч – себестоимость 1-го машино-часа работы оборудования; Т – суммарное время этапов, требующих использования вычислительной техники.

Зэт = 37,06 1075 = 63181 (руб.).

7.7. Расчет себестоимости программного продукта

В себестоимость программного продукта входят следующие элементы:

  1.  Основная заработная плата исполнителя работ по созданию программного продукта.
  2.  Начисления на заработную плату (единый социальный налог).
  3.  Расходы на содержание и эксплуатацию ЭВМ, относящихся к данному программному продукту.
  4.  Прочие расходы.

Первые 3 элемента нам уже известны, а прочие расходы составляют 10% от их суммы

Здоп = 0,1 ∙ (ЗПосн + Нзп + Зэт);                               (7.17)

Здоп = 0,1 ∙ (83185 + 24956 + 63181) = 17132,2 (руб.).

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

С = ЗПосн + Нзп + Зэт + Здоп;                                (7.18)

С = 83185 + 24956 + 63181 + 17132,2 = 188454,2 (руб.).

Визуально структура себестоимости представлена на рис. 7.2.

Структура себестоимости программного продукта отражена в табл. 7.6.

Таблица 7.6

Структура себестоимости программного продукта

Элементы себестоимости

Сумма (руб.)

1

Основная заработная плата исполнителя

83185

2

Начисления на заработную плату

24956

3

Затраты на эксплуатацию ЭВМ

63181

4

Прочие расходы

17132,2

Итого

188454,2

Рис. 7.2. Структура себестоимости программного продукта

7.8. Расчет цены программного продукта

Цена складывается из нескольких компонентов

,                                    (7.19)

где С – себестоимость программного продукта; П – прибыль; НДС – налог
на добавленную стоимость (18% от суммы себестоимости и прибыли).

С учетом нормы прибыли (40% от себестоимости продукта) получаем

П = 0,4 ∙ С;                                               (7.20)

П = 0,4 ∙ 188454,2= 75381,86 (руб.).

НДС = 0,18 (188454,2+ 75381,86) = 47490,5 (руб.).

Подставляя значения в формулу (7.19), определяем цену программного продукта.

Ц = 188454,2+ 75381,86 + 47490,5 = 311326,52 (руб.).

Цена копии программы определяется как:

,      (7.21)

где Ц – суммарные затраты на разработку этой программы; N – количество организаций, которые приобретут данную программу.

Считая, что N не окажется меньше 30, получаем стоимость одной копии программной системы

(руб.).

Результаты расчетов сведем в итоговую табл.7.7.

Таблица 7.7

Структура цены программного продукта

Наименование показателя

Сумма, руб.

1

Себестоимость

188454,2

2

Прибыль

75381,86

3

НДС

47490,5

4

Цена

311326

5

Цена реализации

20755

7.9. Оценка эффективности внедрения программной системы

Разработанная АС используется в ООО «Мастер-дент» стоматологическая поликлиника с целью:

  •  увеличения производительности поликлиники (обслуживание большего числа человек за меньший период времени);
  •  сведения к минимуму заказов бланков для историй болезни.

Внедрение АС позволяет сократить время доставки анализов до сведенья врача.

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

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

Следующим критерием эффективности внедрения АС является снижение временных затрат. На момент написания экономической части стоимость приложения сходного направления составила примерно 382675 рублей.
По расчетам себестоимости стоимость разработанного ПС составляет 311326, что на 17% дешевле стоимости прямого аналога. Также улучшилась сохранность корпоративных данных, передаваемых по сети.


8. Безопасность и экологичность проекта

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

Установлено, что при работе с использованием персональных ЭВМ приблизительно у 80% пользователей наблюдаются физические расстройства различной степени тяжести. Основные из них: расстройства органов зрения
и различные мышечные расстройства. Для устранения и снижения воздействия этих вредных факторов на организм человека специалистами разработан ряд эргономических требований к использующейся аппаратуре.

8.1. Анализ опасных и вредных факторов

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

Все требования к помещению ВЦ и используемому компьютерному оборудованию отражены в Санитарных правилах и нормах СанПиН 2.2.2/2.4.1340-03 «Гигиенические требования к персональным электронно-вычислительным машинам и организации работы», утвержденных Главным государственным санитарным врачом Российской Федерации 30 мая
2003 года [23].

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

8.2. Требования к эксплуатации

Помещения БОКД с ПК имеют естественное и искусственное освещение.

Естественное освещение осуществляется через светопроёмы, ориентированные преимущественно на север и северо-восток и обеспечивают коэффициент естественной освещенности (КЕО) не ниже 1,2% в зонах
с устойчивым снежным покровом и не ниже 1,5% на остальной территории.

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

Полимерные материалы, используемые для внутренней отделки интерьера помещений с ВДТ и ПЭВМ, разрешены для применения органами
и учреждениями Государственного санитарно-эпидемиологического надзора.

Пол в помещениях эксплуатации ПК в Брянском областном кардиодиспансере ровная, нескользкая. В помещения необходимо защитное зануление.

При выполнении работы на ПК уровень шума не превышает 65 дБ (СанПиН 2.2.2/2.4.1340-03).

Уровень вибрации в производственном помещении не превышает допустимых норм вибрации согласно «Санитарным нормам вибрации
рабочих мест».

Работа за ПК относится к зрительным работам высокой точности
для любого типа помещений.

Освещенность на поверхности стола в зоне размещения рабочего документа составляет 300-500 лк. Местное освещение не создает бликов
на поверхности экрана.

В качестве источников света при искусственном освещении применяются преимущественно люминесцентные лампы типа ЛБ.

Рабочее место - это часть пространства, в котором обслуживающий персонал осуществляет трудовую деятельность, и проводит большую часть рабочего времени [22].

Главными элементами рабочего места врача и медсестры являются письменный стол и кресло. Основным рабочим положением является положение сидя.

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

В помещениях с ПК в БОКД ежедневно проводиться влажная уборка.

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

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

При выполнении в течение рабочей смены работ, относящихся к разным видам трудовой деятельности, за основную работу с ПЭВМ и ВДТ следует принимать такую, которая занимает не менее 50% времени в течение рабочей смены или рабочего дня.

Согласно СанПиН 2.2.2./2.4.1340-03, режимы труда и отдыха при работе
с ПЭВМ организовываются в зависимости от вида и категории трудовой деятельности [23].

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

Так как автоматизируются рабочие места врачей и медсестер, у которых помимо работы в дневное время есть и ночные дежурства, в БОКД предусмотрена ночная смена. При работе с ВДТ и ПЭВМ в ночную смену
(с 22 до 8 часов), независимо от категории и вида трудовой деятельности, продолжительность регламентированных перерывов увеличивается
на 60 минут. При 8-ми часовой рабочей смене и работе на ВДТ и ПЭВМ регламентированные перерывы согласно СанПиН 2.2.2./2.4.1340-03 установлены через 2 часа от начала рабочей смены и через 2 часа после обеденного перерыва продолжительностью 15 минут каждый.

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

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

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

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

8.3. Разработка мер защиты от опасных и вредных факторов

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

Для обеспечения надежного и удобного считывания информации
при соответствующей степени комфортности ее восприятия в СанПиН 2.2.2/2.4.1340-03 определены оптимальные и допустимые диапазоны визуальных эргономических параметров [23].

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

Монитор расположен так, что свет на него падает под углом. Экран монитора располагается примерно на расстоянии 28-60 см от оператора, причем верхний край экрана находится на уровне глаз.

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

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

Соблюдение описанных выше требований поможет избежать неприятных последствий при работе на ПК.

Для защиты используется нулевой защитный провод.

В сеть вставляется предохранитель (автомат). Принцип защиты пользователей при занулении заключается в отключении сети за счет тока короткого замыкания, который вызывает перегорание предохранителя
и отключает сеть [19].

Определим по заданным параметрам величину тока короткого замыкания Jк.з:

,

где:  Jк.з. – ток короткого замыкания [А];

– фазовое напряжение [B];

rm – сопротивление катушек трансформатора [Ом];

rобщ – общее сопротивление [Ом].

= 220 В

,

l – длина проводника [м];

s – площадь поперечного сечения проводника [мм2].

Возьмем l1= 400 м , l2= 150 м и l3= 70 м .

r1= 0.028*400/2 = 22,4 Ом

r2 = 0.0175*150/1= 2,625 Ом

r 3 = 0.0175*70/1= 1,225 Ом

r общ= 26,25 Ом

Jкз= 8,38 А

По величине Jкз определим, с каким Jном необходимо включить в цепь питания ПЭВМ автомат.

Jкз ≥ Jном × k

Jном =Jкз / k

Jном= 2,79 А

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

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

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

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

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

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

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

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

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

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

8.5. Выводы 

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


Заключение

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

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

В настоящее время разработанная система внедрена и используется
в кардиологическом отделении Брянского областного кардиологического диспансера, что подтверждается актом о внедрении (см. приложения).

Результаты работы докладывались на 65-й и 66-й студенческой научной конференции [36-37].

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

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


СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

  1.  Брауде, Э.Д. Технологии разработки программного обеспечения. Учебник для вузов / Э.Д. Брауде. – СПб.: Питер, 2007. – 464.       
  2.  Стэкер, М. Разработка клиентских Windows-приложений на платформе Microsoft .NET Framework: Учебный курс Microsoft / М. Стэкер. –
    СПб.: Питер, 2008. – 624.
           
  3.  Трофимов, С.А. CASE-технологии: практическая работа в Rational Rose / С.А. Трофимов. – M.: Бином, 2001. – 272.
  4.  Дьюсон, Р. SQL Server 2008 для начинающих разработчиков /
    Р. Дьюсон. – СПб.: БХВ-Петербург, 2009. – 704.
  5.  Калбертсон, Р. Быстрое тестирование / Р. Калбертсон, К. Браун. –
    М.: «Вильямс», 2005. – 384.
  6.  Криспин, Л. Гибкое тестирование: практическое руководство
    для тестировщиков ПО и гибких команд / Л. Криспин, Д. Грегори. –
    М.: «Вильямс», 2010. – 464.
  7.  Фаронов, В.В. Создание приложений с помощью С#. Руководство программиста / В.В. Фаронов – М.: Эксмо, 2008. – 576.
  8.  Рихтер, Д. CLR via C#. Программирование на платформе Microsoft .NET Framework 2.0 на языке C# / Д. Рихтер. – СПб.: БХВ-Петербург,
    2008. – 656.
     
  9.  Клейн, С. Professional SQL Server 2008 /С.Клейн. – Издательство WROX, 2009. – 513.
  10.  Дейт, К. Дж. Введение в системы баз данных / К.Дж.Дейт. – 8-е изд. –
    М.: «Вильямс», 2005. – 354.
  11.   Шилдт, Г. C#. Учебный курс / Г.Шилдт. – СПб.: БХВ-Петербург,
    2009. – 402.
  12.  Официальный сайт разработчиков МИС “Medsoft”, 2011. – Режим доступа: http://www.med-soft.net/.  
  13.  Официальный информационный сайт МИС «Инфоклиника», 2011. – Режим доступа: http://www. sdsys.ru/page/Prod3/.  
  14.  Официальный сайт разработчиков МИС «Медиалог», 2011. – Режим доступа: http://www. medialog.ru/.  
  15.  Официальный сайт ГБУЗ БОКД, 2011. – Режим доступа: http://кардиобрянск.рф/index.html/.
  16.  Портал «Медицина сегодня» - сайт о здоровье и медицине, 2011. – Режим доступа: http://medichina-today.ru/.
  17.  Журнал «Кардиология», 2011. – Режим доступа: http://www.cardio-journal.ru/.
  18.  ГОСТ 12.0.003-99. Опасные и вредные производственные факторы – Взамен ГОСТ 12.0.003-74; Введ.01.09.1999г. – М. Изд-во стандартов, 2010. – 12.
  19.  ГОСТ 12.1.030-01. Электробезопасность. Защитное заземление. Зануление – Взамен ГОСТ 12.1.013-78; Введ.01.06.2001г. – М. Изд-во стандартов, 2010. – 12.
  20.  ГОСТ 12.1.045-01. Электростатические поля. Допустимые уровни
    на рабочих местах. – Взамен ГОСТ 12.1.045-84; Введ.01.06.2001г. –
    М.
     Изд-во стандартов, 2010. – 12.
  21.  ГОСТ 12.4-99. Средства защиты от статического электричества.
  22.  ГОСТ Р 50948, 49-96. Общие эргономические требования и требования безопасности и ее параметры для ЭВМ.
  23.  СанПиН 1340-03. Гигиенические требования к персональным ЭВМ
    и организация работы. Санитарно-гигиенические правила и нормы.
  24.  ISO/IEC 12207:2008.  Информационные технологии. Процессы жизненного цикла программного обеспечения. – Взамен
    ISO/IEC 12207:1995, ISO/IEC 12207:1995/Amd.1:2002,
    ISO/IEC 12207:1995/Amd.2:2004; Введ.18.03.2008г. – 138.
  25.  Хайкин, С. Нейронные сети: полный курс / С.Хайкин. – М.: Вильямс, 2006. – 1104.  
  26.  Савельев, А. В. На пути к общей теории нейросетей. К вопросу
    о сложности // журнал «Нейрокомпьютеры: разработка, применение», Издательство Радиотехника. – 2006. – № 4-5. – С. 4-14.
  27.  Тульев, Л.А. Байесовские сети. Логико-вероятностный подход /
    Л.А. Тульев. – Издательство: Наука. – 2006. – 608.
  28.  Фаронов, В.В. DELPHI. Программирование на языке высокого уровня: Учебник для вузов / В.В. Фаронов. – СПб.: Питер, 2010. – 640.
  29.   Майо, Д. C# Builder / Д.Майо. – Издательство Бином, 2006. – 384.
  30.  Труб, И. Объектно-ориентированное моделирование на С++: Учебный курс / И.Труб. – СПб.: Питер, 2006. – 417.
  31.  Пауэрс, Л. Microsoft Visual Studio 2008 / Л.Пауэрс, М.Снелл. –
    СПб.: БХВ-Петербург, 2009. – 1200.
  32.  Кузнецов, М. Самоучитель MySQL 5 / М.Кузнецов, И.Симдянов. –
    СПб.: БХВ-Петербург, 2006. – 546.
  33.  Чубукова, И. А. Data Mining: учебное пособие. – М.: Интернет-университет информационных технологий / И.А. Чубукова. –
    БИНОМ: Лаборатория знаний, 2006. – 382.
  34.  Журавлёв, Ю.И. РАСПОЗНАВАНИЕ. Математические методы. Программная система. Практические применения / Ю.И. Журавлёв,
    В.В. Рязанов, О.В. Сенько.  – М.: Изд. Фазис, 2006. – 176.
  35.  Джарратано Д. Экспертные системы: принципы разработки
    и программирование / Д.Джарратано, Г. Райли. –
    Пер. с англ. – М.: Издательский дом Вильямс, 2006. – 1152.
  36.  Женчевская, Н.В. Разработка архитектуры автоматизированной системы для Брянского областного кардиодиспансера / Н.В. Женчевская // Матер. 65-й студ. научной конф. / БГТУ. – Брянск. – С. 296-298.
  37.  Женчевская, Н.В. Автоматизированное рабочее место врача-кардиолога / Н.В. Женчевская // Матер. 66-й студ. научной конф. / БГТУ. – Брянск. –
    В печати.

ПРИЛОЖЕНИЯ

  1.  Приложение 1 – заявка на разработку автоматизированной системы кардиологического отделения Брянского областного кардиологического отделения.
  2.  Приложение 2 – акт внедрения результатов дипломной работы студента Женчевской Н.В. «Автоматизированная система кардиологического отделения Брянского областного кардиологического отделения».


 

А также другие работы, которые могут Вас заинтересовать

79553. Великая Отечественная война: основные этапы, важнейшие события, итоги, значения победы 21.34 KB
  Основные сражения Московская битва 30 сентября 1941 20 апреля 1942 Блокада Ленинграда 8 сентября 1941 27 января 1944 Ржевская битва 8 января 1942 31 марта 1943 Сталинградская битва 17 июля 1942 2 февраля 1943 Битва за Кавказ 25 июля 1942 9 октября 1943 Курская битва 5 июля 23 августа 1943 Битва за Правобережную Украину 24 декабря 1943 17 апреля 1944 Белорусская операция 1944 23 июня 29 августа 1944 ВислоОдерская операция 12 января 3 февраля 1945 Битва за Берлин 16 апреля 8 мая 1945 Итоги Победа...
79554. Развитие ведущих капиталистических стран после второй мировой войны. Европейская интеграция 21.61 KB
  США вышли из войны самой мощной в экономическом и военном отношении страной в капиталистическом мире. В разных уголках мира было оборудовано свыше пятисот военных баз США. Крупный бизнес остался главным представителем производственного капитала в США где в отличие от Европы в этой сфере государственного сектора не было. Это было общим показателем сдвига вправо в политической жизни США.
79555. Социально экономическое развитие Российской Федерации в 90-е года 20 века и начале 21 века 20.61 KB
  Либерализация цен привела к галопирующей инфляции росту неплатежей обесценению заработной платы обесценению доходов и сбережений населения росту безработицы а также к усилению проблемы нерегулярности выплаты заработков социальные последствия В 90е годы произошло значительное ухудшение здоровья населения и роста смертности. Наиболее негативным последствием системного прежде всего экономического кризиса в России явился рост смертности населения.Факторами роста преступности являлись в частности обнищание населения ослабление милиции и...
79556. Советское общество после Сталина. Преобразования Н.С.Хрущева: успехи и неудачи 21.98 KB
  ЦК КПСС возглавил Н. На XX съезде КПСС доклад Хрущёва о культе личности Сталина. пытались сместить Хрущёва с его поста но он на июльском пленуме ЦК КПСС изгнал их из Политбюро а позднее и из партии. XXII съезд КПСС объявил курс на построение коммунизма к концу XX в.
79557. Социально-экономическое развитие СССР в середине 60-х - середине 80-х годов. Достижения и проблемы 25.38 KB
  Социальноэкономическое развитие СССР. он занимал еще один пост Председателя Президиума Верховного Совета СССР. проводившаяся под руководством Председателя Совета Министров СССР А.
79558. Советский Союз в годы перестройки. Распад СССР и его последствия 24.41 KB
  Распад СССР и его последствия. Перестройка общее название нового курса советского партийного руководства совокупности политических и экономических перемен происходивших в СССР с 1987 по 1991 годы. Этот период характеризовался признанием некоторых недостатков существовавшей политикоэкономической системы СССР и попытками исправить их несколькими крупными компаниями административного характера лозунг и политический курс генерального секретаря КПСС Михаила Горбачёва провозглашённый 20 апреля 1985 на апрельском пленуме ЦК КПСС одно из...
79559. Государственно-политическое развитие после распада СССР (конец 20 века - начало 21 века). 21.38 KB
  Первым президентом России был избран в 1991 г. Ельцин вицепрезидентом А. началась борьба за власть и изменение Конституции между президентом Ельциным и Верховным Советом кончившаяся незаконным роспуском последнего 21 сентября 1993 г.
79560. Глобальные проблемы человечества и роль России в их решении 21.17 KB
  Понятие глобальные проблемы появилось в международном лексиконе в последней трети XX в. Благодаря обмену информацией общению на международных конференциях и в международных организациях постепенно пришло понимание того что многие проблемы являются действительно глобальными. Проблемы межнациональных отношений Россия является крупнейшей ядерной державой с огромным промышленным научнотехническим интеллектуальным и культурным потенциалом.
79561. История в системе социально-гуманитарных наук. Предмет, принципы изучения и значение истории 20.8 KB
  Предмет принципы изучения и значение истории. Место истории в системе наук. История России – неотъемлемая часть всемирной истории: общее и особенное в историческом развитии. Основные принципы изучения истории: Принцип дополнительности Нильс Бор: ни одна концепция не может описать объект столь исчерпывающим образом чтобы полностью исключить возможность других подходов.