10. SMS. Уведомления сотрудников с помощью sms-сообщенийо статусе выполнения заказа. Автоматическая отправка sms сотрудникам, находящимся offline, для оперативного слежения за заявками.

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

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

ISDesk

ISDesk -- это Service Desk система с WEB-интерфейсом.Может поставляться как WEB-сервис или как комплект установки на сервере пользователя.

Эта система обладает следующими возможностями:

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

· Прием заявок по электронной почте, через сайт и по телефону;

· Интеграция с Active Directory

· Настраиваемые уведомления

· Версия для PDA

· Древовидная оргструктура

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

· Список заявок

· Карточка заявки

· Приоритеты заявок

· Категории заявок

· Назначение исполнителей

· Вложение файлов и скриншотов

· Срок исполнения

· Статусы заявки

· Учет трудозатрат, выставление счетов

· Экспорт в Excel

· История изменений

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

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

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

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

Сравнительный анализ рассмотренных систем

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

Таблица 6 Сравнительный анализ рассмотренных систем

Критерии	Aquaria SD	Sevrice DesKit	ISDesk
Тип распространения	OEM	Сервис	Сервис и OEM
Стоимость	129000 рублей	До 2-х сотрудников бесплатно, далее от 166 рублей за сотрудника	От 900 рублей в месяц за сервис и 95000 за OEM
Интерфейс, особенности	web-интерфейс, раздельная работа со списками и документами. Есть кастомизация интерфейса.	RIA web-интерфейс, возможна одновременная работа со список документов и самим документов. Проблемы при работе в IE.	Легкий web-интерфейс, раздельная работа со списками и документами.
Учет и управление заявками	Есть	Есть	Есть
Ленты активности по документам	Есть (Жизненный цикл заявки)	Есть, но не все действия отражаются	Есть (Жизненный цикл заявки)
Поддержка преднастроенных тем заявок и сроков	Есть (через Сервисы)	Есть (через Услуги)	Есть (через Сервисы)
Учет трудозатрат	Есть	Есть	Есть
Управление задачами	Есть	Есть	Есть
Средства коллективной работы	Есть	Есть	Есть, частично (без приглашений участников)
Личный кабинет сотрудника	Есть	Есть	Есть
Аналитические отчеты	Есть	Есть	Есть простые отчеты
Экспорт отчетов в CVS	Есть	Есть	Есть
Интеграция с электронной почтой	Есть, полная, 2х-сторонняя	Есть, полная, 2х-сторонняя	Есть, частичная, 2х-сторонняя
Минимальные системные требования	длясервера:ОС Linux MS Window Server; Microsoft Windows Server 2008 R2; Sun Solaris 10 Sun JDK версии 1.6.20 и выше; сервер приложений Apache Tomcat версии 5.0.28 и выше. СУБД MS SQL Server 2005 или 2008; PostgreSQL 8.4.4	ПК с доступом в интернет, Браузер Firefox, GoogleChrome или Safari, доступ на скорости не менее 256 кбит/cек	ПК с доступом в интернет, любой браузер, доступ на скорости не менее 512 кбит/cек. Для серверной части ОС MicrosoftWindowsServer 2003 или 2008, IIS 6.0 или 7.0, .NETFramework 3.5 СУБД MicrosoftSQLServer 2005 или 2008. Рекомендуемая конфигурация сервера: Core 2 Duo 2.5 GHz, 2GB RAM, 80GB HDD

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

1. Наличие базы знаний по решенным инцидентам;

2. Поиск в базе знаний;

3. Регистрация заявок на устранение инцидентов;

4. Классификация и диспетчеризация приходящих заявок, в том числе для назначения исполнителей, категорий и приоритетов;

5. Протоколирование работ, выполняемых по заявке, а также всех вносимых в нее изменений;

6. Построение отчетов по исполнению заявок, загрузке исполнителей и т.д.

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

3.2 Выбор архитектуры информационной системы

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

По способу организации групповые и корпоративные информационные системы подразделяются на следующие классы:

· системы на основе архитектуры файл-сервер;

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

· системы на основе многоуровневой архитектуры;

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

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

Таблица 7- Типовые функциональные компоненты информационной системы

Обозна-чение	Наименование	Характеристика
PS	Presentation Services (средства представления)	Обеспечиваются устройствами, принимающими ввод от пользователя и отображающими результаты обработки.
PL	Presentation Logic(логика представления)	Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя при выборе команды в меню, нажатии кнопки или выборе элемента из списка.
BL	Business or Application Logic (прикладнаялогика)	Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение.
DL	Data Logic (логика управления данными)	Операции с базой данных (SQL-операторы), которые нужно выполнить для реализации прикладной логики управления данными.
DS	Data Services (операции с базой данных)	Действия СУБД, вызываемые для выполнения логикиу правления данными, такие как: манипулирование данными, определение данных, фиксация или откат транзакций и т. п. СУБД обычно компилирует SQL-предложения.
FS	File Services (файловые операции)	Дисковые операции чтения и записи данных для СУБД (файловые операции) и других компонентов. Обычно являются функциями операционной системы (ОС)

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

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

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

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

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

Большинство конфигураций сотрудник-сервер использует двухуровневую модель, в которой сотрудник обращается к услугам сервера. Предполагается, что диалоговые компоненты PS и PL размещаются на сотруднике, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL), логики BL и DL - на сотруднике. Двухуровневая архитектура сотрудник-сервер использует именно этот вариант: приложение работает на сотруднике, СУБД - на сервере.

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

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

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

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

Многоуровневая архитектура стала развитием архитектуры сотрудник-сервер и в классической форме состоит из трех уровней:

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

· средний уровень представляет собой сервер приложений, на котором выполняется прикладная логика BL и с которого логика обработки данных DL вызывает операции с базой данных DS;

· верхний уровень представляет собой удаленный специализированный сервер базы данных, выделенный для услуг обработки данных DS и файловых операций FS (без использования хранимых процедур).

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

Централизация логики приложения упрощает администрирование и сопровождение. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовывать их специалистами узкого профиля. Наконец, изменения прикладной логики не затрагивают интерфейс, и наоборот. Но поскольку границы между компонентами PL, BL и DL размыты, прикладная логика может появиться на всех трех уровнях. Сервер приложений с помощью монитора транзакций обеспечивает интерфейс с сотрудниками и другими серверами, может управлять транзакциями и гарантировать целостность распределенной базы данных. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов. С ростом систем сотрудник-сервер необходимость трех уровней становится все более очевидной. Таким образом, многоуровневая архитектура распределенных приложений позволяет повысить эффективность работы корпоративной информационной системы и оптимизировать распределение ее программно-аппаратных ресурсов. Но пока на российском рынке по-прежнему доминирует архитектура сотрудник-сервер. Для решения задачи проектирования информационной системы управления сопровождением поставляемого программного обеспечения будем использоватьтехнологиюсотрудник-сервер, так как в данной системе обрабатывается малый объем данных и она является простой в реализации.

Архитектура информационной системы МБУЗ ГБ г. Армавира, разрабатываемой в моей работе, показана на рисунке 11.

Рисунок 11 - Архитектура информационной системы МБУЗ ГБ г. Армавира

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

3.3 Проектирование базы данных информационной системы МБУЗ ГБ г. Армавира

Методология IDEF 1.x. IDEF1X [7] является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы. Концептуальной схемой мы называем универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу "AS IS", тем не менее, он иногда применяется в этом качестве, как альтернатива методу IDEF1. Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы (скажем с помощью метода IDEF1) и решение о внедрении реляционной базы данных, как части корпоративной информационной системы, было принято. Однако не стоит забывать, что средства моделирования IDEF1X специально разработаны для построения реляционных информационных систем, и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы моделирования.

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

Сущности в IDEF1X и их атрибуты.

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

Связи между сущностями

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

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

Идентификация сущностей. Представление о ключах.

Сущность описывается в диаграмме IDEF1X графическим объектом в виде прямоугольника. Каждый прямоугольник, отображающий собой сущность, разделяется горизонтальной линией на часть, в которой расположены ключевые поля и часть, где расположены неключевые поля. Верхняя часть называется ключевой областью, а нижняя часть областью данных. Ключевая область содержит первичный ключ для сущности. Первичный ключ - это набор атрибутов, выбранных для идентификации уникальных экземпляров сущности. Атрибуты первичного ключа располагаются над линией в ключевой области. Как следует из названия, неключевой атрибут - это атрибут, который не был выбран ключевым. Неключевые атрибуты располагаются под чертой, в области данных. При создании сущности в IDEF1X модели, одним из главных вопросов, на который нужно ответить, является: "Как можно идентифицировать уникальную запись?". Для этого требуется уникальная идентификация каждой записи в сущности для того, чтобы правильно создать логическую модель данных. Напомним, что сущности в IDEF1X всегда имеют ключевую область и, поэтому в каждой сущности должны быть определены ключевые атрибуты.

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

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

· Уникальным образом идентифицировать экземпляр сущности.

· Не использовать NULL значений.

· Не изменяться со временем. Экземпляр идентифицируется при помощи ключа. При изменении ключа, соответственно меняется экземпляр.

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

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

Потенциальные ключи, которые не выбраны первичными, могут быть использованы в качестве вторичных или альтернативных ключей. С помощью альтернативных ключей часто отображают различные индексы доступа к данным в конечной реализации реляционной базы. Если сущности в IDEF1X диаграмме связаны, связь передает ключ (или набор ключевых атрибутов) дочерней сущности. Эти атрибуты называются внешними ключами. Внешние ключи определяются как атрибуты первичных ключей родительского объекта, переданные дочернему объекту через их связь. Передаваемые атрибуты называются мигрирующими. Преимущества IDEF1XОсновным преимуществом IDEF1X, по сравнению с другими многочисленными методами разработки реляционных баз данных, такими как ER и ENALIM является жесткая и строгая стандартизация моделирования. Установленные стандарты позволяют избежать различной трактовки построенной модели, которая несомненно является значительным недостатком. Согласно данной методологии, [7], процесс построения информационной модели состоит из следующих шагов:

· определение сущностей; определение зависимостей между сущностями;

· задание первичных и альтернативных ключей;

· определение атрибутов сущностей;

· приведение модели к требуемому уровню нормальной формы;

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

· задание триггеров, процедур и ограничений;

· генерация базы данных.

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



Рисунок 12 - логическая структура базы данных информационной системы МБУЗ ГБ г. Армавира.

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

4 Реализация информационной системы специалиста сервисного и ремонтного обслуживания оборудования и компьютерной техники отдела АСУ МБУЗ ГБ г. Армавира

4.1 Спецификация средств реализации информационной системы специалиста сервисного и ремонтного обслуживания оборудования и компьютерной техники отдела АСУ МБУЗ ГБ г. Армавира

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

Операционная система

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

1) Распространенность;

2) Совместимость с аппаратной частью;

3) Стоимость

Оценка будет производиться по 10ти бальной шкале, где 10 макс, 1 мин.

Таблица 8 - Сравнительный анализ ОС

	Windows 7	Linux ubuntu	MacOSX
Распространенность	10	5	8
Совместимость с аппаратной частью	10	7	6
Стоимость	5	10	8

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

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

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

Для того что бы выбрать СУБД приведем таблицу 9 сравнения самых распространенных СУБД

Таблица 9 - Сравнительный анализ СУБД

	ORACLE	ACCESS	MySQL	Microsoft SQL Server
Стоимость	~6810 руб.	~3500 руб.	бесплатно	~ 25000 руб.
Дружественный интерфейс	-	+	-	+
Простота внедрение СУБД	сложно	легко	средне	средне
Возможность создания форм с поддержкой VBA	-	+	-	-

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

Среда разработки

Borland Delphi 2007 - эффективная среда разработки приложений для Microsoft Windows. BorlandDelphi2007 предоставляет исключительный "коэффициент повышения производительности", позволяя устранить утомительный труд и максимально увеличить производительность при помощи революционной среды разработки корпоративных приложений, библиотеки многократно используемых визуальных компонентов и полностью интегрированного пакета инструментов моделирования и управления жизненным циклом проектов (ALM).

Новая версия продукта C++Builder 2007, ведущей интегрированной среды для быстрой разработки приложений на С++, сочетает поддержку операционной системы Windows Vista API и технологий Web 2.0 с самыми последними стандартами: значительно выросшей производительностью, интегрированными функциями проверки и множеством сочетаний клавиш, позволяющих экономить время и значительно упрощать выполнение типовых задач.

C#(MSVisualStudio 2007) - являясь последним из широко распространенных языков программирования, впитал в себя весь имеющийся опыт и вобрал лучшие стороны существующих языков программирования, при этом являясь специально созданным для работы в NET. Сама архитектура NET продиктовала ему объектно-ориентированную направленность.

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

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

Таблица 10 - Сравнение сред программирования

Критерии сравнения	Borland Delphi	C++Builder	C#(MS Visual Studio 2013)
Степень соответствия назначения языка и целей разработки	Ориентирован на разработку систем любой степени сложности	Ориентирован на разработку систем любой степени сложности	Ориентирован на разработку систем любой степени сложности
Использованиемеждународных стандартов	Имеет собственный стандарт	Полностью стандартизирован	Полностью стандартизирован
Поддерживаемые СУБД	InterBase 7.5, Oracle, IBM DB2, Microfost SQL Server 2000/2005, Informix, SQL Anywhere, MySQL, Sybase	MS SQL Server 2000/2005, My SQL, Oracle, Sybase, Interbase 2007, SQL Anywhere, DB2, Informix	InterBase 7.5, Oracle, IBM DB2, Microfost SQL Server 2000/2005, Informix, SQL Anywhere, MySQL, Sybase
Поддерживаемые ОС	Microsoft Windows 2000/ XP Professional (SP2 иливыше)/ Vista Professional/ Microsoft Windows Server 2003.	Windows Vista/ Server 2003/ XP Professional/ 2000 Professional / 2000 Server	MS Windows OC
Квалификация разработчиков	Высокая	Высокая	Высокая
Стоимость продукта	900 у.е.	900 у.е.	900 у.е.

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

Таблица 11 - Оценка технико-экономической эффективности

Параметры сравнения/ оценка	Весовой коэффициент	C++Builder	BorlandDelphi	C#(MSVisualStudio 2013)
		Ajk	kj •Ajk	Ajm	kj •Ajm	Aji	kj •Aji
Степень соответствия назначения языка и целей разработки	0,25	3	0,75	2	0,5	4	1
Использованиемеждународных стандартов	0,10	2	0,2	2	0,2	3	0,3
Поддерживаемые СУБД	0,20	2	0,4	2	0,4	3	0,6
Поддерживаемые ОС	0,15	2	0,3	3	0,45	4	0,6
Квалификация разработчиков	0,2	4	0,8	4	0,8	4	0,8
Стоимость продукта	0,1	3	0,3	3	0,3	3	0,3
Интегральный технико-экономический показатель, Q		Qc = 2,75	Qb = 2,65	Q# = 3,6

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

4.2 Описание работы информационной системы специалиста сервисного и ремонтного обслуживания оборудования и компьютерной техники отдела АСУ МБУЗ ГБ г. Армавира

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

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

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

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

4.3 Разработка прототипаинформационной системы специалиста сервисного и ремонтного обслуживания оборудования и компьютерной техники отдела АСУ МБУЗ ГБ г. Армавира

Для разработки прототипа информационной системы МБУЗ ГБ г. Армавира в СУБД MicrosoftAccessбыла реализована схема данных, отвечающая логической модели (см. рисунок 12).

Рисунок 12 - Схема данных в MSAccess

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

Для создания прототипа системы использовался инструмент BorlandDelphi 2007 и такие его компоненты, как:

1. ADOConnection - для подключения к БД;

2. ADOTable - для выборки данных через подключение ADOConnection;

3. DataSource- для создания источника данных внутри приложения;

4. DBGrid, DBEdit и DBRichEdit - для отображения и изменения данных.

Далее на рисунках 13-15 приведены примеры работы программы, в Приложении 1 приводится исходный код модулей.

Рисунок 13 -Главное окно информационной системы МБУЗ ГБ г. Армавира

Рисунок 14 -Окна выбора способа и добавления данных

Рисунок 15 -Окно добавления сведений о ремонте оборудования

Вывод: Произведен выбор средств реализации информационной системы МБУЗ ГБ г. Армавира, описан интерфейс и реализован ее прототип. В качестве путей развития и дальнейшего наращивания функциональности можно отметить такие первоочередные задачи, как реализация подсистемы отчетности.

5. Социальный аспект разработки

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

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

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

Заключение

В ходе выполнения работы была исследованадеятельность МБУЗ ГБ г. Армавира. Мною была выявлена проблема затруднения получения сведений об установленном оборудовании, а именно- отсутствия оперативного доступа к ним.

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

По результатам обследования был произведен реинжиниринг бизнес-процессов, построена модель «как должно быть». Разработка модели осуществлялась с использованием нотаций IDEF0 иIDEF3 с использованием CASE средств BPWinиMSOfficeVisio 2007 professional. В течение практики велся сбор статистических данных, позволивший получить количественные оценки и провести математическое моделирование.

Мною определена архитектура и функцииинформационной системы МБУЗ ГБ г. Армавира и реализован ее прототип, описаны средства реализации и интерфейс пользователя.

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

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