Информационная система мониторинга доступности ремонтных бригад

· Возможность индивидуальной настройки формы КЕ для каждой категории КЕ;

· Хранение всей истории событий с КЕ;

· Модуль универсального импорта для синхронизации базы данных КЕ системы с внешними системами, включая функцию аудита (проверка изменений в базе данных КЕ с результатами инвентаризации);

· Интеграция с системами MS SCCM, LANDesk, Nagios, MS SCOM и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Версия для PDA

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

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

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

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

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

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

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

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

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

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

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

· Экспорт в Excel

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

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

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

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

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



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

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

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

Критерии	Naumen	SolverMate	IntraService
Тип распространения	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. Построение отчетов по исполнению заявок, загрузке исполнителей и т.д.

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



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

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

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

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

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

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

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

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

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

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

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

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

Вывод: Для решения задачи проектирования информационной системы мониторинга доступности ремонтных бригад ремонтной службы ОАО "НЭСК-ЭЛЕКТРОСЕТИ" подходит технология Интернет/Интранет на базе многоуровневой архитектуры, так как в данной системе обрабатывается малый объем данных и не должно существовать никакого дополнительного ПО для ее использования на стороне клиента.

Архитектура информационной системы мониторинга доступности ремонтных бригад ремонтной службы ОАО "НЭСК-ЭЛЕКТРОСЕТИ" показана на рисунке 3.1.

Рисунок 3.1 - Архитектура системы

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

Сервер приложения реализуется в виде WEB-приложения, которое может исполняться в контексте среды исполнения, работающего например, на Java и реализующего стандарты Java-сервлетов. Для снижения нагрузки на сервер приложений за счет кэширования передаваемого контента, а также реализации дополнительных функций, таких как Virtual Hosts, SSL перед сервером приложений может проводиться установка одного из популярных Web-серверов: Apache, nginx, MS IIS.

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



3.4 Проектирование структуры информационной системы мониторинга доступности ремонтных бригад

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

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

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

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

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

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

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

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

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

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



5. Руководитель. Если у исполнителя есть флаг руководителя, то он может также менять приоритет, крайний срок, а также назначать других исполнителей (рисунок 3.6).

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

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

Таблица 3.2 - Маршрут заявок

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.5 Проектирование модели данных для информационной системы сектора сопровождения отдела управления сетями связи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



4. Реализация информационной системы мониторинга доступности ремонтных бригад ремонтной службы ОАО "НЭСК-ЭЛЕКТРОСЕТИ"

4.1 Выбор средств реализации

Чтобы реализовать информационную систему мониторинга доступности ремонтных бригад ремонтной службы ОАО "НЭСК-ЭЛЕКТРОСЕТИ" необходимо выбрать операционную систему для серверной части ИС, СУБД и систему управления сайтом, которая будет платформой для запуска информационной системы.

Выбор операционной системы.

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

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

Windows Server

Создание семейства Windows Server стало следующим шагом в развитии операционных систем Windows. Основными особенностями данного семейства операционных систем являются наличие в их составе платформы Microsoft .NET Framework, а также поддержка Web-сервисов XML (вплоть до наличия в составе операционной системы UDDI-сервера).

Windows Server существует в четырех редакциях:

* Windows Server Web Edition -- операционная система для развертывания и обслуживания Web-приложений и Web-сервисов, включая приложения ASP .NET;

* Windows Server Standard Edition -- сетевая операционная система для выполнения серверной части бизнес-решений и рассчитанная на применение в небольших компаниях и подразделениях. Здесь имеются средства совместного использования ресурсов и централизованного развертывания приложений для настольных компьютеров, а также реализована поддержка до 4 Гбайт оперативной памяти и симметричной многопроцессорной обработки с использованием двух процессоров;

* Windows Server Enterprise Edition -- ОС, которая прежде всего предназначена для средних и крупных компаний. Она поддерживает серверы на базе 64-разрядных процессоров (до восьми штук) и объем оперативной памяти до 64 Гбайт и выпускается в версиях для 32- и 64-разрядных платформ;

* Windows Server Datacenter Edition -- операционная система, которая служит для создания критически важных технических решений с высокими требованиями к масштабируемости и доступности. К таким решениям относятся приложения для обработки транзакций в режиме реального времени, а также решения, основанные на интеграции нескольких серверных продуктов. В данной ОС реализована поддержка симметричной многопроцессорной обработки с использованием до 32 процессоров, а также имеются службы балансировки нагрузки и создания кластеров, состоящих из восьми узлов. Эта ОС доступна для 32- и 64-разрядных платформ.

Solaris (Sun Microsystems)

С самых ранних этапов разработки операционная система Sun Solaris, являющаяся одной из самых популярных коммерческих версий UNIX, предназначалась для работы в корпоративных вычислительных сетях. Она обеспечивает чрезвычайно эффективный и надежный доступ к серверам, СУБД, принтерам и другим сетевым ресурсам. Эта ОС обладает развитыми средствами поддержки сетевого взаимодействия (например, серверы с операционной системой Solaris могут встраиваться в сети и домены сетей Novell и Microsoft) и является одной из самых популярных платформ для разработки корпоративных решений -- для нее существует около 12 тыс. различных приложений.

Предшественницей Solaris была операционная система Sun OS, а первая версия операционной системы Solaris, основанной на двух базовых разновидностях UNIX -- Berkley 4.2/4.3 (BSD) и AT&T System V, была выпущена в 1991 году.

ОС Solaris соответствует многим промышленным стандартам (X/Open UNIX 95, различные разделы POSIX 1003.1, X11R6). Эта операционная система обладает высокой масштабируемостью: она может использоваться на однопроцессорных серверах и даже на рабочих станциях, на серверах масштаба рабочей группы и на 64-процессорном сервере масштаба предприятия Sun Enterprise 10000. Для подавляющего большинства приложений эта ОС обеспечивает практически линейный рост производительности при увеличении числа процессоров за счет симметричных многопроцессорных вычислений.

В настоящее время Solaris представляет собой необычайно мощную и гибкую многозадачную многопользовательскую операционную систему, существующую в вариантах для процессоров SPARC и Intel x86. Последняя ее версия, Solaris 9, представляет собой уже третье (начиная с Solaris 7) поколение 64-разрядных операционных систем, оптимизированных для работы на 64-разрядных серверах Sun.

Операционная система Solaris 9 представляет собой основу открытой сетевой среды Sun Open Net Environment (Sun ONE). В комплект поставки Solaris 9 включены ключевые приложения Sun ONE, такие как Sun ONE Application Server, Platform Edition, Sun ONE Directory Server, Sun ONE Integration Server, Sun ONE Message Queue, Sun ONE Portal Server, Sun ONE Web Server.

Linux и FreeBSD

Операционная система Linux представляет собой некоммерческий продукт категории Open Source для платформы Intel, который создавали в течение десяти лет тысячи энтузиастов. Хотя эта ОС нередко применяется в качестве клиентской операционной системы, ее популярность связана главным образом с ее использованием в качестве серверной платформы. Список серверных продуктов для Linux, пожалуй, не менее внушителен, чем для Solaris, HP-UX и AIX, и включает такие популярные продукты, как Web-сервер Apache, серверные СУБД практически всех ведущих производителей, серверы приложений.

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

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

Еще одной популярной некоммерческой версией UNIX является FreeBSD, доступная для платформ Intel и DEC Alpha. Основой FreeBSD послужил дистрибутив BSD UNIX, выпущенный группой исследования вычислительных систем (Computer Systems Research Group) Калифорнийского университета (Беркли). Данная операционная система обладает такими особенностями, как объединенный кэш виртуальной памяти и буферов файловых систем, совместно используемые библиотеки, модули совместимости с приложениями других версий UNIX, динамически загружаемые модули ядра, позволяющие во время работы добавлять поддержку новых типов файловых систем, сетевых протоколов или эмуляторов без перегенерации ядра.

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

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

Выбор СУБД

Рассмотрим существующие варианты СУБД, подходящие для реализации ИС дистанционного обучения, на примере 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 как платформу данных во всех существенных областях, в том числе и по стоимости. Однако стоимость покупки СУБД не столь важна, как ее надежность. Поэтому остановимся на выборе СУБД Microsoft SQL Server.

Выбор системы управления сайтом

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

К лидерам относятся следующие компании и их продукты:

· IBM - IBM WebSphere Portal.

· Microsoft - MS Office SharePoint Server 2007 (MOSS 2007).

· Oracle - Oracle Portal и Oracle WebLogic (продукт, "унаследованный" от компании BEA).

· SAP - SAP NetWeaver Portal.

· Sun - Sun Java System Portal.

· Vignette - Vignette Portal.

Характеристика ключевых поставщиков

1. IBM

Преимущества:

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

WebSphere Portal поддерживает создание мэшап-решений (объединение данных из нескольких источников), интегрируется с другими технологиями (в частности с технологиями социальных сетей), а также внедряет технологию Web 2.0 в организации.

IBM предлагает единую интеграцию и внедрение приложений посредством настройки интерфейсов пользователей, поддержку множества каталогов пользователей по протоколу LDAP.

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

Предостережения:

Некоторые пользователи WebSphere Portal, которые используют другие продукты класса Enterprise Content Management, говорят о трудности управления процессом создания контента портала посредством двух сред.

WebSphere Portal требует существенного вклада в освоение WebSphere Platform для получения приемлемых навыков.

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

Абоненты и заказчики высказывают недовольство и путаницу связанную с методологией подсчета стоимости - IBM's Processor Value Unit (закупка должна проводиться через профессионального партнёра).

2. Microsoft

Преимущества:

Microsoft Office Sharepoint Server 2007 (MOSS 2007) сейчас переживает активное внедрение компаниями с персоналом менее 15,000 человек в качестве корпоративного B2E портала, а также в контенто-централизованных партнерских сетях с абонентским WEB-доступом. MOSS 2007 уже вырос за рамки уровня департаментов и используется в качестве корпоративного B2E портала во многих организациях.

MOSS 2007 представляет собой первую попытку лидирующего производителя предоставить организациям горизонтальный портал по схеме SaaS (software as a service - ПО как сервис). MOSS 2007 все еще не подходит для многих вариантов горизонтальных порталов уровня организации, но вполне удовлетворяет потребностям порталов уровня департаментов.

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

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

Предостережения:

MOSS 2007 не предоставляет полной поддержки мэшап-решений и некоторых других технологий (в частности технологий социальных сетей).

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

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

MOSS 2007 не имеет соответствующих средств поддержки для более крупных и более сложных установок порталов.

3. Oracle

Преимущества:

Oracle предлагает использование передовой технологии от BEA в своем стратегическом портале. Портал включает функциональность, заложенную в предыдущих продуктах BEA Ensemble, Pathways и Analytics, и .NET Accelerator. Все эти решения включены в WebCenter Services и WebCenter Suite и поддерживают мэшап-функциональность, возможность портальной аналитики и коллективной обработки информации, социальные сети и упрощенную интеграцию .NET- приложений в Java-портал.

Oracle в лице продуктов семейства WebLogic Portal предлагает надежный, испытанный продукт для широкомасштабных, объемных абоненто-ориентированных порталов.

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

Oracle - активный лидер по использованию передовых портальных стандартов, в частности он один из первых начал использование JSR 286 (Portlet 2.0) и WSRPv2.

Предостережения:

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

Oracle планирует интегрировать основные компоненты своих четырех портальных продуктов, включая AquaLogic User Interaction (ALUI) с WebCenter Framework в качестве продукта WebCenter Suite. Однако это является сложной технической задачей, и полная интеграция может занять более 12 месяцев.

Рынок в целом испытывает проблемы с пониманием политики Oracle по продвижению своих четырёх портальных и колаборационных технологий: WebCenter Services, WebCenter Suite, WebLogic Portal и Oracle Portal, особенно в части связи между этими четырьмя решениями.

Oracle обязалась поддерживать продукты в рамках своей программы "продолжение и покрытие", включая Oracle Portal, ALUI и WebLogic Portal, на срок минимум 9 лет. Однако существует немалый риск, что существующие абоненты, особенно, те, которые используют старшие версии продуктов BEA portal, скорее перейдут на портальный продукты конкурентов, чем будут поддерживать WebCenter Framework, как техническую основу своих портальных проектов.

4. SAP

Преимущества:

Пользователи SAP Portal, которые использовали Web Page Composer, отмечают существенное улучшение процесса создания контента для портала.

Дополнительное решение по ускоренной доставке приложений (AccAD), включённое в SAP NetWeaver, позволяет поднять производительность портала для удаленных пользователей.

Большой каталог iViews, обеспечивающий интеграцию между SAP Portal и бизнес-приложениями SAP, даёт большие возможности для пользователей SAP.

SAP Portal продолжает играть центральную роль в стеке NetWeaver и SAP Business Suite, обеспечивая использование SAP Portal большинством SAP-организаций для доступа к самым последним версиям бизнес-приложений SAP.

Предостережения:

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

SAP отстает от главных конкурентов по части предоставления мэшап-функций.

Внедрениям SAP Portal традиционно не хватает технологии совместной работы.

Хотя SAP и добавил поддержку JSR 168 в NetWeaver 7.1, они продолжают отставать от конкурентов в поддержке портальных стандартов, к примеру, до сих пор нет обязательств поддержки JSR 286 (Portlet 2.0)

5. Sun Microsystems

Преимущества:

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

Sun Java System Portal Server продемонстрировал высокую масштабируемость во многих критичных установках портала.

Sun включает Sun Java System Portal Server в свою платформу Java Composite Applications Platform System (CAPS), что вместе представляет комплексное окружение.

Предостережения:

Интерес рынка, возникший после заявления Liferay, все еще должен перерасти в новые продажи Sun Java System Portal Server.

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

6. Vignette

Преимущества:

Vignette Portal обладает проверенной масштабированностью и гибкостью, являясь основой многих абонентских критических B2C порталов.

Большая база продуктов класса ECM компании Vignette обеспечивает готовую площадку для продаж Vignette Portal вместе с дополнительными решениями, такими как Vignette Builder и Vignette Community Services.

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

Предостережения:

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

...