В рубрику "Комплексные системы безопасности" | К списку рубрик | К списку авторов | К списку публикаций
Д.А. Шестаков
Руководитель проекта компании "ААМ Системз"
Эргономичность пользовательских приложений ПК
ИСБ - это сложная, многокомпонентная и гетерогенная автоматизированная система. Человеческий фактор играет здесь огромную роль. Именно от продуманности интерфейса будет зависеть эффективность работы пользователя и успех функционирования системы в целом. Эргономичность означает обеспечение точности, функциональной полноты и завершенности при выполнении производственных заданий на рабочем месте пользователя. Точность работы определяется тем, насколько правильно пользователь выполнил в рамках системы поставленную задачу. Этот показатель включает процент ошибок, совершенных пользователем: число ошибок набора, варианты ложных путей или ответвлений, число неправильных обращений к данным, запросов и пр. Функциональная полнота отражает степень использования первичных и обработанных данных, списка необходимых процедур обработки или отчетов, число пропущенных технологических операций или этапов при выполнении поставленной задачи. То есть отвечает на вопрос, насколько имеющийся функционал требует вмешательства пользователя при решении задачи. Завершенность работы описывает степень исполнения производственной задачи средним пользователем за определенный срок, а также число пользователей, которые выполнили задание в фиксированные сроки. Производительность работы пользователя отражает объем затраченных при выполнении задачи ресурсов как вычислительных, так и пси-хофизиологических (условно говоря, сколько кликов мышкой или нажатий на клавиши должен произвести пользователь при выполнении той или иной задачи в системе). Дизайн и функционал пользовательского ин-терфейса должны обеспечивать:
ПК для ИСБ предназначен для управления про-цессами, обеспечивающими безопасность на объекте, и решает вполне определенные задачи. Взаимодействие пользователя с системой осуществляется через автоматизированные рабочие места (АРМ) - компьютеры с соответствующим программным обеспечением. Каждое АРМ предназначено для выполнения жестко определенных функций. Их набор зависит от роли пользователя на данном АРМ. На практике в основном можно выделить следующие основные роли:
1. Администратор системы. В обязанности данного пользователя входит:
2. Оперативный дежурный. Как правило, в его обязанности входит мониторинг тревожных событий на объекте и своевременное реагирование на них. Выделим следующие функции оперативного дежурного:
3. Сотрудник службы безопасности. В отличие от оперативного дежурного, сотрудник данной службы занимается анализом произошедших событий, то есть "разбором полетов", что подразумевает построение и анализ отчетов:
4. Сотрудник отдела кадров. Ведет базу данных сотрудников организации. Отвечает за:
5. Сотрудник бюро пропусков. Обеспечивает регистрацию посетителей и выдачу им гостевых пропусков. Его основные задачи:
Реализация пользовательских приложений
При анализе существующих на рынке ПК для управления ИСБ можно выделить 2 подхода к реализации пользовательских приложений:
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).
Второй вариант с точки зрения поддержки комплекса и исправления в нем ошибок более предпочтителен: если в логике функционирования комплекса была допущена ошибка, то в случае одной реализации она будет поправлена быстрее, а значит, быстрее устранена у заказчика. В случае существования отдельных реализаций заказчику придется ждать, пока дойдет очередь до исправления ошибки его ОС.
Выводы
Современная интегрированная система безопасности представляет собой программно-аппаратное решение и предназначена для объединения в общую систему управления и обработки информации средств технической безопасности (охранно-пожарной сигнализации, контроля до-ступа, охранного видеонаблюдения), средств контроля нормального течения производственных процессов и различных информационных подсистем предприятия. Она решает задачи по сбору и обработке информации от различных программных и аппаратных комплексов, не связанных между собой напрямую. К программному комплексу, использующемуся в качестве основы для создания интегрированной системы, предъявляются особые требования, связанные с надежностью, защищенностью и другими качествами.
Подведя итог, перечислим те требования, которые были рассмотрены в данной статье:
Опубликовано: Журнал "Системы безопасности" #2, 2007
Посещений: 11089
Автор
| |||
В рубрику "Комплексные системы безопасности" | К списку рубрик | К списку авторов | К списку публикаций