Алгоритм Безапосности: издание для профессионалов
Санкт-Петербург:
тел.: +7 911 137-88-32 magazine@algoritm.org
Москва:
тел.: +7 499 641-05-26moscow@algoritm.org

Главная
Новости
О журнале
Архив
Свежий номер
Реклама
Подписка
Контакты
Сотрудничество
 

Если вы хотите стать распространителем нашего журнала

 
 
 
 
 

"Алгоритм Безопасности" № 1, 2019 год.

Содержание

Пользовательский интерфейс унифицированного АРМ дежурного пульта управления
А. И. Кротов, К. В. Колесов, А. Н. Морозов


Пользовательский интерфейс унифицированного АРМ дежурного пульта управления

Кротов Андрей Игоревич, начальник ФКУ НИЦ «Охрана» Росгвардии
Колесов Константин Викторович, ученый секретарь ФКУ НИЦ «Охрана» Росгвардии
Морозов Алексей Николаевич, старший научный сотрудник ФКУ НИЦ «Охрана» Росгвардии

Наши цифровые инструменты сложны для изучения и понимания, сложны в применении; они часто препятствуют достижению наших целей [1]

В статье рассмотрены вопросы «юзабилити» типовых пользовательских интерфейсов АРМ дежурных пунктов централизованной охраны. Предложен подход к построению пользовательского интерфейса на основе использования метода персонажей и унифицированных информационных сущностей — зон и разделов объектов охраны.

Введение

В настоящее время во вневедомственной охране эксплуатируются более десяти типов программно-аппаратных комплексов (ПАК) централизованного наблюдения, несовместимых между собой ни на аппаратном, ни на программном уровнях. В связи с этим, на пунктах централизованной охраны (ПЦО) вынуждены устанавливать столько типов АРМ дежурных пультов управления (ДПУ) и АРМ дежурных офицеров (ДПЦО), сколько типов ПАК находятся в эксплуатации.

В различных ПАК однотипная информация отображается, а одни и те же операции выполняются по-разно-удобствам и, как следствие, к снижению надежности охраны. Для решения этих проблем коллективом предприятий-изготовителей под общим руководством ФКУ НИЦ «Охрана» Росгвардии проводится работа по созданию программного обеспечения (ПО) унифицированного АРМ (УАРМ) ПЦО [2]. В его задачу входит обеспечение сквозной автоматизации деятельности оперативного и инженерно-технического персонала, начиная от составления актов обследования объектов и заканчивая расчетом платы за услуги охраны.

Создание УАРМ ПЦО является сложной задачей, связанной в частности с выбором критерия унификации [3].

Использовать существующие АРМ в качестве прототипов не представляется возможным, поскольку их архитектура базируется на специфических особенностях конкретной СПИ, несовместимой с прочими. В результате проведенной ФКУ НИЦ «Охрана» научно-исследовательской работы, в качестве критерия унификации было выбрано единообразие средств общения пользовательского интерфейса на основе структурных элементов объекта охраны — зон и разделов [4]. Следующим шагом при разработке УАРМ является построение на их основе «дружественного» пользовательского интерфейса (ПИ).

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

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

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

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

  • современных концепций в области проектирования взаимодействия;
  • исследований, выполненных ФКУ НИЦ «Охрана» Росгвардии;
  • многолетнего личного опыта авторов по созданию и эксплуатации программного обеспечения ПЦО.

Теоретические основы построения пользовательского интерфейса УАРМ

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

Пользовательский интерфейс и класс программного обеспечения

Об удобстве и простоте («юзабилити») пользовательского интерфейса можно говорить только во взаимосвязи с предметной областью и классом (видом, типом) программного обеспечения. В зависимости от задач исследования, ПО классифицируют по различным признакам. Например, международный стандарт ISO/IEC 12182 [5] предусматривает 16 критериев классификации программных средств, которые в зависимости от предметной области могут наполняться разным содержанием.

В контексте настоящей статьи можно выделить три класса ПО:

  • автоматическое;
  • инструментальное;
  • автоматизированное.

Автоматическое ПО работает без участия человека по заранее заложенным в него алгоритмам, поэтому вопросы удобства ПИ для него не актуальны.

К инструментальному будем относить ПО, содержащее набор «орудий» для воздействия на какой-либо информационный объект. В этом смысле в качестве примера инструментального ПО можно привести Microsoft Word. Он содержит набор возможностей («инструментов») для работы с текстовыми документами, но не предписывает последовательности их использования. Отметим, что обычно под инструментальным понимается программное обеспечение, предназначенное для разработки других программ. В этом смысле относить Microsoft Word к инструментальным ПО не вполне «классически». Однако в контексте настоящей статьи важным является не то, что создается при помощи программы — другая программа или текстовый документ, а то, как это создается. И в том и в другом случае ресурсы программы используются не в соответствии с заранее предписанным алгоритмом, а в объеме и в последовательности, определяемой потребностями задачи, квалификацией и предпочтениями пользователя или разработчика.

ПО систем безопасности относится к классу автоматизированных, обладающих признаками двух вышеперечисленных. Часть операций персонала может быть автоматизирована — например, последовательность действий при нормализации оперативной обстановки, начиная с отображения вновь поступившего тревожного сообщения в сочетании с необходимыми реквизитами и заканчивая задержанием нарушителя. Другая часть операций, в том числе указанных в должностных инструкциях персонала ПЦО, должна быть доступна оператору через элементы ПИ. Правила, определяющие взаимосвязь действий пользователя и реакций системы, должны быть просты и естественны.

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

Вывод. При разработке ПИ УАРМ необходимо заранее определить перечень подлежащих и не подлежащих автоматизации операций, в сочетании с алгоритмами их выполнения.

Связь пользовательского интерфейса и существа программного обеспечения

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

По результатам анализа ПИ можно судить о многом:

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

О формальных признаках хорошего интерфейса

Назначение ПИ — обмен информацией между компьютером и человеком в условиях ограниченной пропускной способности «канала» — сочетания характеристик ПИ и возможностей оператора [6]. Поэтому один из признаков хорошего ПИ — высокая информативность.

Из определения следует, что существуют, как минимум, два способа повысить информативность: добавить «сигнал» и уменьшить «шум».

«Сигнал» — это доля необходимой для данной операции смысловой части в общем объеме информации на мониторе.

«Шум» — это вспомогательная (разделители, заголовки и т.д.), повторяющаяся и возможно другая, не относящаяся непосредственно к выполняемой операции информация.

Некоторые рекомендации по уменьшению «шума»:

  • «убрать все лишнее»;
  • «вынести за скобки»;
  • «соединить информационные функции» — наделить новой функцией существующий элемент, а не вводить новый.

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

После удаление «шума» следует решить вопрос, как повысить «сигнал» — добавить на освободившееся место полезную информацию.

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

Некоторые сведения об особенностях восприятия информации человеком

Психологи полагают, что мы воспринимаем зрительную информацию в последовательности, напоминающей написание буквы Z — слева направо и сверху вниз, в последовательности «как пишем».

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

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

Психологи полагают, что человек только 10% информации видит глазами, остальное — мозгом в форме устойчивых логических связей между элементами информации. На эту тему существует множество примеров, в частности, приведенные на рисунках 1, 2 [7]. При беглом взгляде представленные на рисунке 1 лица кажутся одинаковыми, хотя это не так (рис. 2). Поэтому:

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

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

Рис. 1. Тестовый пример

Рис. 2. Контрольный пример

Анализ пользовательских интерфейсов некоторых АРМ ДПУ

Опираясь на вышеперечисленные теоретические положения, проведем анализ двух пользовательских интерфейсов АРМ ДПУ, приведенных в ГОСТ Р 55017-2012 «Пульты централизованного наблюдения для использования в системах противокриминальной защиты. Требования к информации» и одного из АРМ, разработанного в процессе проведения технического эксперимента по созданию «дружественного» пользовательского интерфейса.

В контексте критериев, изложенных в п. 2 интерфейс, рекомендованный ГОСТ Р 55017-2012, имеет следующие недостатки:

  • Информация в окне «Краткие данные об объекте» ориентирована по вертикали, а не по горизонтали;
  • Много «шума».

Правое окно носит название «Краткие данные об объекте» из чего можно заключить следующее:

  • Предполагается наличие как минимум еще одного окна «Полные данные»;
  • Полные данные на рассматриваемую экранную форму по какой-то причине не поместились. Однако при внимательном рассмотрении оказывается, что информация в правом окне во многом дублирует информацию в строке окна «Протокол событий». В обоих окнах отображаются: состояние пультового номера, пультовой номер, время, тип объекта, Ф.И.О. абонента и его адрес.
  • Потребность в заголовках таблицы «Протокол событий» не очевиден, поскольку тип информации однозначно определяется ее содержанием.

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

Рис. 3. Пример неинформативных заголовков и полей таблицы

Дежурный пульта управления как инструмент создания пользовательского интерфейса

Одним из самых ранних, а со временем ставшим еще более полезным, инструментом моделирования ПИ являются персонажи [1,8].

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

Детальная разработка ПИ ДПУ выходит за рамки настоящей статьи, поэтому остановимся на основных предложениях.

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

Обслуживание заключается в диспетчеризации ДПУ групп задержания по тревожной ситуации на конкретном объекте (высылка групп задержания с указанием реквизитов объекта, прием докладов и др.).

С учетом ограниченной пропускной способности «канала» (площади монитора) основные задачи ДПУ вступают в противоречие друг с другом: полная информация обо всех тревожных объектах на экране попросту не помещается.

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

Макет одного из возможных вариантов компоновки ПИ АРМ дежурного оператора приведен на рисунке 4. Он имеет следующие достоинства:

  • Окна и информация в них вытянуты преимущественно «в ширину».
  • В зоне наивысшей концентрации внимания — левом верхнем («красном») углу расположена панель абонентского номера объекта (АН).
  • Логически связанная с АН панель доступных команд расположена справа от абонентского номера.
  • Логически связанная со списком АН тревожных объектов панель реквизитов расположена справа от абонентского номера.
  • Панель «Протокол» отображается на мониторе всегда (для контроля происходящих событий).
  • Отображаемые в панели «Протокол» сообщения имеют большую длину (особенно сообщения функциональной диагностики), поэтому панель имеет максимально возможную ширину. 
  • Заголовок панели «Протокол» позволяет реализовать принцип «совмещения функций», путем расположения на нем элементов управления для фильтрации событий (по диапазонам времени и дат, состоянию, абонентским номерам и т.д.) и поиска событий.
  • Минимизирован «шум» по причине отсутствия необоснованного дублирования информации.
  • Используется минимальное число разделителей из-за отсутствия табличной формы представления информации и соответственно наименований столбцов.

Рис. 4. Макет компоновки интерфейса АРМ ДПУ.
1 — панель абонентского номера, 2 — панель тревог, 3 — панель команд управления, 4 — панель реквизитов объекта и абонентов, 5 — панель «Протокол»

Литература

1. Купер А. Психбольница в руках пациентов, или Почему высокие технологии сводят нас с ума и как восстановить душевное равновесие. СПб: Символ-Плюс, 2004.
2. Баринов И.А., Никифоров С.А., Морозов А.Н. Унификация программного обеспечения КСА ПЦО // Безопасность. 2018. № 1.
3. Колесов К.В., Морозов А.Н. О нормативном обеспечении разработки унифицированного АРМ пунктов централизованной охраны // Алгоритм безопасности. 2018. № 5.
4. Тактико-технические требования к информационному обеспечению комплексов средств автоматизации пунктов централизованной охраны. ФКУ НИЦ «Охрана» МВД России, 2013.
5. ISO/IEC TR 12182:2015 Systems and software engineering — Framework for categorization of IT systems and software, and guide for applying it.
6. bureau.ru/bb/soviet/20160809/.
7. Кэрролл Ли, Стерлинг Фред, Брежнева Елена. Все зависит от тебя. Матрица восприятия реальности. М.: АСТ, 2013.
8. Брайн Пол. Актуален ли метод создания персонажей для реализации UX-стратегии? 30 октября 2017.
9. Р 78.36.021-2012. Примерные должностные инструкции инженерно-технического состава и дежурной смены пунктов централизованной охраны подразделений вневедомственной охраны. Методические рекомендации.
 

скачать
скачать

 

Rambler's Top100 Интернет портал. Каталог фирм. бжд. Охрана. Обеспечение безопасности. Безопасность предприятия. Оборудование. Видеонаблюдение.