Требования к современным программным комплексам ИСБ. Часть 2

Эргономичность пользовательских приложений ПК

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

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

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

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

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

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

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

Их набор зависит от роли пользователя на данном АРМ. На практике, в основном, можно выделить следующие основные роли:

1) Администратор системы.

В обязанности данного пользователя, как правило, входит:

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

2) Оперативный дежурный.

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

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

3) Сотрудник службы безопасности.

В отличие от оперативного дежурного, сотрудник данной службы занимается анализом произошедших событий, то есть «разбором полетов», что подразумевает построение и анализ отчетов:

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

В сферу его компетенции входит также поиск и анализ записанных видеофрагментов;

4) Сотрудник отдела кадров.

Ведет базу данных сотрудников организации.

Отвечает за:

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

5) Сотрудник бюро пропусков.

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

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

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

Реализация пользовательских приложений ПК

При анализе существующих на рынке ПК для управления ИСБ, можно выделить два подхода к реализации пользовательских приложений:

1. Для каждой роли, или для каждой более-менее крупной пользовательской функции реализуется отдельное приложение (например, «Генератор отчетов», «Учет рабочего времени», «Дежурный режим» - такого рода приложения можно увидеть во многих ПК);

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

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

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

Согласно с указанным ролям, опишем пользовательский функционал для соответствующих АРМ:

1) АРМ администратора.

 Для эффективного решения задач администратора АРМ должно обеспечивать:

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

2) АРМ оперативного дежурного.

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

• в списке планов должна быть возможность автоматического показа графического плана, содержащего аппаратный объект, от которого пришло сообщение (причем, после отображения  плана объект – источник сообщения - должен находиться в поле видимости оператора и должен быть выделен;
• в списке сообщений пришедшее новое сообщение,  должно попадать в поле видимости;
• аппаратные элементы, размещаемые на плане, должны иметь пиктограммы, отображающие реальное состояние соответствующей аппаратуры;
• если в состав ИСБ входит подсистема видеонаблюдения, то при наступлении тревожных событий на соответствующем АРМ должны автоматически выводиться изображения с камер, размещенных в районе возникновения тревоги;

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

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

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

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

3) АРМ службы безопасности.

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

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

4) АРМ сотрудника отдела кадров.

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

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

5) АРМ оператора Бюро пропусков.

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

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

Дополнительные требования

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

Открытость

Под открытостью понимается возможность расширения функционала программного комплекса путем внедрения новых модулей, реализованных как силами заказчика, так и силами третьих сторон. Такая возможность значима для организаций, имеющих в своем составе IT-подразделение. В этом случае программный комплекс может быть сравнительно быстро и недорого модифицирован разработчиками ПО данной организации. Ограничения по расширению функционала зависят от архитектуры комплекса. Если ПК имеет модульную архитектуру, строился на стандартной технологии с открытым интерфейсом (типа COM, .NET, CORBA, J2EE, OPC и т.д.), то это позволяет разработать полноценный функциональный модуль для данной системы (новый драйвер оборудования, специализированное рабочее место и т.д.).

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

Переносимость (межплатформенность)

Переносимость – это возможность запуска комплекса на разных платформах (Intel, SUN SPARK) и операционных системах (ОС) – Windows, Linux, Unix, Solaris и т.д. Она позволяет использовать комплекс в гетерогенных сетях. Например, если в соответствии с политикой организации, для серверов запрещено использовать ОС Windows (по соображениям надежности, безопасности), то в этом случае серверная часть комплекса работает под управлением любой другой поддерживаемой операционной системы, а  для пользовательских станций может также применяться ОС семейства Windows.

Если ПК обладает переносимостью, то возможно 2 варианта реализации:

1) для каждой поддерживаемой ОС существует своя реализация;
2) общая для всех ОС реализация (например, комплекс написан на Java).

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

Выводы

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

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

1. Надежность:

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

2. Защита от НСД (несанкционированного доступа):

•  контроль прав операторов на действия в системе;
•  протоколирование действий операторов;
•  контроль целостности системы;
•  защита информационных потоков;

3. Масштабируемость:

•  функциональная и по мощности в рамках системы одного класса.

4. Эргономичность:

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

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

 При этом ожидается выделение и развитие в структуре ИСБ подсистемы поддержки принятия решений. Все это приведет к появлению новых требований к ПК. Названные в статье базовые требования  в том или ином виде будут присутствовать и в дальнейшем.

Данная статья призвана оказать помощь заказчикам на этапе формирования технического задания и помочь проектировщикам на этапе проектирования системы.