Анализ и отчетность:

· Встроенные средства построения отчетов по заданным шаблонам по всем объектам в системе;

· Возможность детализации отчетов по временным периодам (год, месяц, неделя, сутки, час);

· Возможность экспорта содержания отчетов во внешние системы;

· Использование внешних OLAP средств для построения отчетов.

База знаний компании:

· Ведение разделов базы знаний;

· Вопросы и ответы с возможностью вставки HTML (форматирование);

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

· Полнотекстовый поиск по базе знаний.

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

Sevrice DesKit

Sevrice DesKit - это сервис, который состоит из комплекса модулей коллективной работы для управления заявками клиентов, задачами и рабочим временем сотрудников, объединенных единой рабочей средой. Он объединяет в себе несколько систем:

· системы клиентской поддержки;

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

· систему управления временем;

· систему управления взаимоотношениями с клиентами.

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

1. Управление заявками клиентов.Учет заявок клиентов, отслеживание и совместная работа. Отражение работ в личном кабинете клиента. Централизация взаимодействия с клиентом.

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

3. Ленты активности. Полная история общения и работ над заявкой/задачей. Отражение коллективной работы.

4. Интеграция с e-mail. Полное взаимодействие по электронной почте как между клиентами и сотрудниками, так и между сотрудниками.

5. Учет времени. Листы учета времени на основании списываемых часов в задачах и заявках. Экспорт в CVS. Срезы по клиентам и услугам.

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

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

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

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

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 или любой другой учетной системы.

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

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

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

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

Критерии	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, Google Chrome или Safari, доступ на скорости не менее 256 кбит/cек	ПК с доступом в интернет, любой браузер, доступ на скорости не менее 512 кбит/cек. Для серверной части ОС Microsoft Windows Server 2003 или 2008, IIS 6.0 или 7.0, .NET Framework 3.5 СУБД Microsoft SQL Server 2005 или 2008. Рекомендуемая конфигурация сервера: Core 2 Duo 2.5 GHz, 2GB RAM, 80GB HDD

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

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

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

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

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

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

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

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

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

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

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

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

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

- системы на основе технологии интернет/интранет.

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

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

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

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

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

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

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

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

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

Архитектура клиент-сервер предназначена для разрешения проблем файл-серверной архитектуры путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов 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 размыты, прикладная логика может появиться на всех трех уровнях. Сервер приложений с помощью монитора транзакций обеспечивает интерфейс с клиентами и другими серверами, может управлять транзакциями и гарантировать целостность распределенной базы данных. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов. С ростом систем клиент-сервер необходимость трех уровней становится все более очевидной.

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

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

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

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

Также немаловажным фактором при выборе архитектуры стал разнородный характер мобильных устройств, присутствующих у технических специалистов - коммуникаторы, смартфоны, мобильные телефоны, планшетные ПК. Разработка мобильного клиента под каждую платформу или покупка всем устройств одного типа вышла бы дорого, а использование интернет/интранет архитектуры позволяет минимизировать затраты на создание и использование подсистемы мобильного доступа, так как практически любое устройство сегодня обладает доступом к мобильному интернету по каналам 3G, EDGE или GPRS, а следовательно способно просматривать адаптированные веб-страницы.

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

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

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

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

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

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

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

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

В системе предусмотрены следующие роли:

1. Администратор. Отвечает за настройки системы, выдачу прав и ролей пользователям, наполнением справочников. Имеет доступ ко всем объектам системы (рисунок 12).

Рисунок 12 - Варианты использования информационной системы для администратора

2. Инициатор. Создает новую заявку, имеет доступ на просмотр своих открытых заявок, добавляет комментарии к своим открытым заявкам, а также меняет статус. После создания заявки ее статус становится «Открыта». Инициатор может закрыть свою заявку (рисунок 13).



Рисунок 13 - Варианты использования информационной системы для инициатора

3. Диспетчер. Заполняет дополнительные атрибуты заявки: классифицирует заявку, назначает приоритет и крайний срок, назначает исполнителей. После назначения исполнителя статус заявки становится «Назначен исполнитель». Диспетчер может зарыть заявку (рисунок 14).

Рисунок 14 - Варианты использования информационной системы для диспетчера

4. Исполнитель. Исполнитель может менять статус заявки на «Выполняется» и «На проверке», вносить комментарии. Получив или отредактировав заявку, исполнитель меняет ее статус на «Выполняется». Выполнив заявку, исполнитель меняет ее статус на «На проверке» (рисунок 15).

Рисунок 15 - Варианты использования информационной системы для исполнителя

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

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

Начнем с процесса создания заявки (рисунок 16).

Рисунок 16 - Создание заявки в системе

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

Следующий процесс - обработка заявки диспетчером (рисунок 17)



Рисунок 17 - Обработка заявки диспетчером

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

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

Рисунок 18- Обработка заявки исполнителем

И последний аспект - то, как может быть обработана заявка по факту ее выполнения исполнителем (рисунок 19)



Рисунок 19 - Закрытие или возврат заявки на доработку

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

3.5 Проектирование модели данных для информационной системы отдела АСУ

Методология IDEF1X [8] - один из подходов к семантическому моделированию данных, основанный на концепции "сущность-связь" (Entity-Relationship). Это инструмент для анализа информационной структуры систем различной природы. Информационная модель, построенная с помощью IDEF1X-методологии, отображает логическую структуру информации об объектах системы

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

Основными объектами концептуальной модели являются сущности и связи.

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

Правила для атрибутов сущности:

1. Каждый атрибут должен иметь уникальное имя.

2. Сущность может обладать любым количеством атрибутов.

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

4. Для каждого экземпляра сущности должно существовать значение каждого его атрибута (правило необращения в нуль - Not Null).

5. Ни один из экземпляров сущности не может обладать более чем одним значением для ее атрибута.

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

Стандарт IDEF1X описывает способы изображения двух типов сущностей - независимой и зависимой, и связей - идентифицирующих и неидентифицирующих.

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

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

Диспетчеры. Список пользователей, сопоставленных с ролью «диспетчеры»

Исполнители. Список пользователей, сопоставленных с ролью «исполнители»

Категории заявок. Список, служащий для категоризации заявок

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

Мы определили концептуальную модель, теперь можно перейти к созданию логической и физической модели с помощью программы ER Win Data Modeller (рисунки 20 и 21 соответственно).

Рисунок 20 - Логическая модель данных

Логическая модель данных показывает основные объекты, данные о которых необходимо хранить в процессе работы информационной системы выставления заявок на обслуживание оборудования и компьютерной техники МБУЗ ГБ г. Армавира. Для перехода на физический уровень следует исключить связи «многие ко многим», такая связь одна - «заявка - исполнители» (рисунок 21).

Рисунок 21 - Физическая модель данных

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

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

4.1 Спецификация средств реализации информационной системы

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

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

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

Первое, на что стоит обратить внимание при выборе серверной операционной системы - это системные требования ОС и совместимость оборудования с ней. Как можно видеть из таблицы 8, системные требования Ubuntu, по сравнению с текущими операционными системами Windows Server 2008, достаточно низкие и сопоставимы разве что с довольно старыми версиями ОС Windows XP и 2003, что несомненно является плюсом. Более того, в семействе Ubuntu имеются также версии и для платформ, отличных от PC. Однако основным минусом Ubuntu Linux является то, что из-за ее пока еще относительно низкой распространенности некоторые производители просто не хотят создавать драйверы для этой системы, и в целом для Linux.

Таблица 8. Минимальные системные требования

Название компонента/ОС	Windows Server 2008 (R2)	Ubuntu Server
Процессор	1 ГГц (x86) или 1.4 ГГц (x64)	300 МГц
ОЗУ	512 МБ	192 МБ (32-разрядная версия) / 256 МБ (64-разрядная версия)
Свободное место на диске	10 ГБ	2-3 ГБ
Видеокарта	Super VGA (800 x 600)	VGA (640 x 480)

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

Широко распространенные компоненты серверных операционных систем, такие как web-сервер Apache, СУБД MySQL, PHP и т.д., изначально создавались для работы в Unix/Linux. Поэтому для их настройки в Windows Server придется делать то же самое, что и в Linux-системах, а удобство установки, стабильность работы компонентов и их совместимость в случае использования Windows зачастую оставляет желать лучшего.

Компания Microsoft разработала web-сервер IIS, технологию ASP.NET, а также за дополнительную плату предлагает приобрести надежную и функциональную СУБД SQL Server. Кроме того, можно найти и другие качественные и функциональные альтернативы СУБД Microsoft SQL Server, которые будут отлично работать в операционной системе Windows Server 2008, в том числе и бесплатные (например кроссплатформенная Postgre).Данные по сравнению серверных ос приведены в таблице 9.

Таблица 9. Основные функции серверных ОС

Роль сервера	Ubuntu Server 10.04	Windows 2008 Enterprise	Windows 2008 Datacenter	Windows 2008 Standard	Windows 2008 Itanium	Windows 2008 Web	Windows 2008 Foundation	Windows 2008 HPC
Web-сервер	+	+	+	+	+	+	+	+
DHCP-сервер	+	+	+	+	-	-	+	-
DNS-сервер	+	+	+	+	-	+	+	+
Файловые службы	+	+	+	*	-	-	*	*
Сервер печати	+	+	+	+	-	-	+	-
Сервер приложений	+	+	+	+	+	-	+	-
Службы Active Directory	*	+	+	*	-	-	*	*
Сервисы обновления (WSUS/Репозиторий)	+	+	+	+	-	-	+	+
Службы удаленных рабочих столов	+	+	+	*	-	-	*	*
Встроенная СУБД	+	-	-	-	-	-	-	-
Обозначения : '+' - доступно полностью; '-' - недоступно; ' * ' - доступно частично или ограничено.
Примерная стоимость	$0	$3999	$2999	$1029-1209	$2999	$469	нет данных	нет данных

Как следует из представленного выше материала, оба семейства операционных систем имеют как преимущества, так и недостатки. Явного лидера среди серверных ОС нет - обслуживание серверов как с установленной операционной системой Ubuntu, так и Windows, в любом случае потребует временных, а значит, и финансовых затрат. Тем более, что благодаря отсутствию качественной литературы, посвященной Ubuntu Server, суммарные затраты на приобретение и обслуживание Ubuntu в целом сопоставимы с аналогичными затратами для Windows Server. Поскольку в группе клиентских подключений отдела управления сетями связи на большинстве ПК используется ОС семейства Unix, а персонал, занимающийся администрированием обладает достаточными знаниями по работе с ОС данного семейства, то остановим выбор на серверной ос Unix.

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

Рассмотрим существующие варианты СУБД, подходящие для реализации ИС дистанционного обучения, на примере Microsoft SQL Server и MySQL.

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

Microsoft SQL Server в качестве языка запросов использует версию SQL, получившую название Transact-SQL (сокращённо T-SQL), являющуюся реализацией SQL-92 (стандарт ISO для SQL) с множественными расширениями. T-SQL позволяет использовать дополнительный синтаксис для хранимых процедур и обеспечивает поддержку транзакций (взаимодействие базы данных с управляющим приложением). Microsoft SQL Server и Sybase ASE для взаимодействия с сетью используют протокол уровня приложения под названием Tabular Data Stream (TDS, протокол передачи табличных данных). Протокол TDS также был реализован в проекте FreeTDS с целью обеспечить различным приложениям возможность взаимодействия с базами данных Microsoft SQL Server и Sybase.

Microsoft SQL Server также поддерживает Open Database Connectivity (ODBC) -- интерфейс взаимодействия приложений с СУБД. Версия SQL Server 2005 обеспечивает возможность подключения пользователей через WEB-сервисы, использующие протокол SOAP. Это позволяет клиентским программам, не предназначенным для Windows, кроссплатформенно соединяться с SQL Server. Microsoft также выпустила сертифицированный драйвер JDBC, позволяющий приложениям под управлением Java (таким как BEA и IBM WebSphere) соединяться с Microsoft SQL Server 2000 и 2005.

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

SQL Server поддерживает избыточное дублирование данных по трем сценариям:

– Снимок: Производится «снимок» базы данных, который сервер отправляет получателям.

– История изменений: Все изменения базы данных непрерывно передаются пользователям.

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

В SQL Server 2005 встроена поддержка .NET Framework. Благодаря этому, хранимые процедуры БД могут быть написаны на любом языке платформы .NET, используя полный набор библиотек, доступных для .NET Framework, включая Common Type System (система обращения с типами данных в Microsoft .NET Framework). Однако, в отличие от других процессов, .NET Framework, будучи базисной системой для SQL Server 2005, выделяет дополнительную память и выстраивает средства управления SQL Server вместо того, чтобы использовать встроенные средства Windows. Это повышает производительность в сравнении с общими алгоритмами Windows, так как алгоритмы распределения ресурсов специально настроены для использования в структурах SQL Server.

MySQL -- свободная система управления базами данных (СУБД). MySQL является собственностью компании Sun Microsystems, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License и под собственной коммерческой лицензией, на выбор. Помимо этого компания MySQL AB разрабатывает функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

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

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

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

Язык веб-разработки

Предположительно подсистема разрабатывается в среде php. Для обоснования выбора было произведено сравнение РНР с другими языками программирования Web-приложений. Это его основные конкуренты -- Perl, ASP.NET, ColdFusion и Java.

1. РНР и Perl

Язык Perl был создан программистом Ларри Уоллом (Larry Wall) и расшифровывается как Practical Extraction and Report Language. Перевести это можно как "язык для практического извлечения данных и составления отчетов. Perl является интерпретатором и появился намного раньше, чем Web. С появлением интернета язык Perl оказался удобным инструментом для создания динамических Web-страниц. Большое распространение Perl получил потому, что был доступен на каждом Web-сервере, поскольку практически все они работали под управлением UNIX, и альтернативой ему являлся лишь более сложный язык С.

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

2. РНР и Java

Вообще говоря, различают язык Java и технологию Java. Язык Java представляет собой С-подобный язык, который разрабатывался как "улучшенный C++". Технология Java включает в себя клиентскую и серверную часть, а также доступ к базам данных, поэтому наиболее корректно проводить сравнение технологии Java со связкой Apache/PHP/MySQL. Технология Java разрабатывалась как межплатформенная технология, позволяющая создавать Web-приложения корпоративного масштаба. Основными достоинствами этой технологии являются межплатформенная переносимость и объектно-ориентированный язык, что позволяет создавать сложные и объемные приложения. К числу недостатков можно отнести медленное выполнение, потребление большого количества памяти (плата за межплатформенную переносимость) и сложность разработки Web-приложений по сравнению с РНР. Между тем РНР почти не уступает Java в гибкости и масштабируемости созданных приложений. Кроме того, использование Java для разработки достаточно простых приложений вряд ли оправдано, а при работе над серьезными задачами Java обходится дороже.

3. РНР и ASP.NET

ASP (Active Server Pages) - язык сценариев от Microsoft. Если язык ASP значительно уступал РНР по многим параметрам, в первую очередь, по времени выполнения сценариев, то с появлением технологии ASP.NET ситуация изменилась.

Основное достоинство ASP.NET заключается в возможности применения всей мощи интерфейса Windows для разработки Web-приложений. Это позволяет разрабатывать страницы со сложным интерфейсом, не заботясь о сохранении, шифровании и передаче переменных, используемых на динамических страницах.

ASP.NET тесно интегрирован в новую технологию NET компании Microsoft. Главной особенностью разработки Web-приложений при помощи ASP.NET является возможность использовать любой язык программирования среды исполнения NET. Это может быть как модифицированный вариант Visual Basic - Visual Basic.NET, так и новый язык С# или клон Java - J#. Более того, в рамках одного Web-приложения могут быть использованы несколько языков программирования. Все это позволяет объединять в рамках одного проекта программистов, владеющих разными языками программирования. Код Web-приложения на ASP.NET компилируется в промежуточный язык MSIL (Microsoft Intermediate Language), иногда просто называемый IL. Аппаратно-независимый код на языке IL помещается в кэш Web-сервера для повышения производительности, по аналоги с байт-кодом Java. Но в отличие от технологии Java, обеспечивающей платформенную независимость, NET обеспечивает независимость от языка разработки. Выполнение Web-приложений ASP.NET на серверах, работающих не под Windows, практически невозможно. Более того, если Web-приложение интенсивно использует компоненты NET, просмотр динамической страницы будет возможен только под Windows и только с помощью браузера Internet Explorer. Поэтому в смысле переносимости РНР, безусловно, отличается от ASP.NET в лучшую сторону. Другой крайне немаловажный довод в пользу РНР заключается в быстром исправлении обнаруженных ошибок. Теоретически исправить их можно самостоятельно, если обладаете достаточной квалификацией. Также можно написать письмо разработчикам, и с большой долей вероятности, в следующей версии ошибка будет исправлена. А версии РНР выходят очень часто. С другой стороны, попробуйте написать об ошибке в Microsoft и попросить ее исправить. Если вы не глава Пентагона, вам это вряд ли удастся. Еще одним плюсом РНР, особенно важным для начинающих, является то, что его легче использовать для построения Web-приложений.

Выбрав среду реализации PHP, можно без проблем решить следующие задачи:

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

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

· простота реализации.

4.2 Описание работы информационной системы отдела АСУ

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

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

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

3. Исполнители видят все незакрытые заявки, где они назначены. Сообщение о смене исполнителей приходят инициатору заявки. Если исполнитель не является руководителем, то он может только добавлять комментарии и перевести заявку в состояние «Исполняется». В результате этого, инициатору заявки приходит письмо с уведомлением о начале работ по его заявке. После завершения работы исполнитель указывает потраченное время и переводит заявку в состояние «На проверке». Об этом инициатор заявки и руководитель уведомляется по электронной почте.

4. Руководитель и инициатор могут отправить заявку со статусом «На проверке» обратно на доработку или закрыть ее. Пользователи с этой ролью оповещаются об изменении статуса по электронной почте.

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

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

Главная страница

· Новости от IT подразделения;

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

· Доска объявлений

Документы

· Нормативные документы отдела IT

· Образцы и шаблоны служебных документов

· Новому сотруднику отдела IT

Заявки (зависит от роли)

· Создание заявки

· Заявки в работе

· Архив

Отчеты

· Заявки у исполнителей

· Распределение заявок по подразделениям

· Активность пользователей

· Распределение заявок по категориям

· Распределение заявок по времени

· Эффективность инженеров

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

Рисунок 22 - Полная версия интерфейса проектируемой системы

Далее изображен интерфейс мобильной версии мобильных устройств на базе WML (рисунок 23).

Рисунок 23 - Интерфейс для смартфонов

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

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

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

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

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

Заключение

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

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

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

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

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

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

...