Текст книги "Человеко-компьютерное взаимодействие"

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

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

• USTM (User Skill and Task Match – соответствие навыков пользо-вателяи требований задачи) и ее форму для малых предприятий CUS-TOM;

• OSTA (Open System Task Analysis – анализ задач открытой системы);

• ETHICS (Effective Technical and Hyman Implementation of Computer Systems – эффективная реализация технической и человеческой составляющих в компьютерных системах).

USTM/CUSTOM. USTM (User Skill and Task Match – соответствие навыков пользователя и требований задачи) – это схематическое представление структуры задачи со словесным описанием. Этим достигается объединение структурности и человеческого фактора. Модификация USTM для малых предприятий именуется CUSTOM, где упор делается на учете требований совладельцев; при этом предполагается, что совладельцы не являются конечными пользователями системой. Совладельцы определяются как лица, на которых сказываются (которые зависят от) успех либо неудачи системы. Выделяют четыре категории совладельцев:

1) первичные – используют систему;

2) вторичные – непосредственно не используют систему, но получают ее «выход» или могут определять исходные данные для системы (например, те, кто получает отчеты, сгенерированные системой);

3) третичные – не попадают в категории 1 и 2, но на них влияет успех или неудача системы (например, директор, который может получать пользу (прибыль) либо убыток в зависимости от работы системы);

4) обеспечивающие – участвуют в разработке, развитии и сохранении системы.

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

Модель CUSTOM применяется на начальных этапах разработки: в начале работы над проектом и, возможно, на этапе постановки задачи, когда только определены возможности продукта. Это методология, основанная на заполнении формуляров (готовых форм), которая предполагает определенный набор вопросов на каждой стадии разработки. Краткий пример типичного перечня вопросов в модели CUSTOM таков:

• Чего хотят достичь совладельцы и как измеряется успех?

• Что является источником удовлетворения от работы для совладельцев и что – источником неудовлетворения и стресса?

• Какими знаниями и навыками обладают совладельцы?

• Каково отношение совладельцев к работе и к компьютерным технологиям?

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

• Каковы характеристики задачи совладельцев в смысле ее частоты, фрагментации (или декомпозиции) и выбора действий?

• Встают ли перед совладельцами вопросы, касающиеся конкретной ответственности, безопасности или конфиденциальности (исходя из работы системы)?

• Каковы физические условия работы совладельцев?

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

OSTA (Open System Task Analysis – анализ задач открытой системы) описывает прежде всего организационное окружение технической системы. В OSTA пользовательские аспекты системы, такие, как потребительские свойства и доступность, объединены с техническими аспектами, например с системным функционированием. В OSTA различают восемь стадий:

1) в терминах целей пользователя описывается основная задача, которую технология должна реализовать;

2) определяются способы ввода задач в систему. Эти способы могут иметь разные характеристики, что может явиться некоторым ограничением для разработки;

3) описывается внешнее окружение, в котором могут быть представлены физические, экономические и даже политические аспекты;

4) описываются процессы трансформации внутри системы в терминах выполняемых действий или объектов;

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

6) описывается техническая система в терминах ее конфигурации и объединения с другими системами;

7) определяются показатели функционирования, охватывающие и технические, и социальные характеристики системы;

8) точно определяется новая техническая система.

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

ETHICS (Effective Technical and Hyman Implementation of Computer Systems – эффективная реализация технической и человеческой составляющих в компьютерных системах). ETHICS, так же как и OSTA, имеет дело с техническими и человеческими требованиями, но отличается от OSTA тем, что использует две принципиально разные команды разработчиков. Одна направлена на техническое решение вопроса, не вдаваясь в человеческие проблемы, другая заботится в основном об адекватности системы и человеческих проблем, не особо вдаваясь в их программную реализацию. Иначе говоря, модель ETHICS основана на двух параллельных и до какого-то времени независимых частях разработки – человеческом и техническом аспектах. В модели ETHICS соответствующие команды разработчиков работают отдельно и только потом пытаются объединить свои решения. Предполагается, что тем самым уменьшается влияние разных специалистов друг на друга. Суть метода – независимая работа двух команд: человеческих и технических предпочтений. Затем результаты предлагаемых каждой командой проектов пытаются совместить, создавая продукт, удовлетворяющий требованиям обеих команд. В методе ETHICS различают несколько основных стадий:

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

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

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

4) проверяются на совместимость решения, выделенные на третьей стадии;

5) ранжируются в соответствии с ранее выбранным критерием совместные пары человеко-технических решений;

6) разрабатываются детали проекта.

Методология разработки программных продуктов (Soft Systems Methodology – SSM) – второе направление учета характеристик человека при разработке программных продуктов в целом и ПИ в частности. Мы рассматривали социотехнические модели как средство, позволяющее определить потребности, как человеческие, так и технические. Методология разработки программных продуктов рассматривает человеческий и технический аспекты в рамках единой системы, где и люди, и технология разработки есть лишь ее компоненты. Существо SSM – в акценте на взаимном и совместном понимании проблем всеми разработчиками, как ориентирующимися на технологию, так и теми, кому важнее человеческая адекватность. Эта методология включает несколько стадий. При этом различают стадии, относящиеся к реальному миру, и стадии, относящиеся к системе.

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

Стадия 2 – это движение от реального мира к миру системы и попытка сформулировать «базовые определения» системы. Таких определений может быть несколько, к примеру отражающих разное понимание системы разработчиками. Базовые определения описываются в терминах CATWOE (Clients, Actors, Trasformations, Weltanschauung, Owner, Environment):

• Clients – те, кто получает продукцию и/или прибыль от работы системы.

• Actors – те, кто работает внутри системы.

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

• Weltanschauung (с нем. – мировоззрение). Как понимается система с позиций конкретного базового определения.

• Owner – собственники, т.е. те, кому принадлежит система, кому она подотчетна и кто вправе санкционировать изменения в ней.

• Environment – внешнее окружение, т.е. мир, в котором функционирует система и который влияет на нее.

Пример. Базовые определения для менеджмента пассажирскими авиаперевозками – системы бронирования билетов.

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

• Clients – пользователи системой.

• Actors – объединенный центр управления туристических агентств.

• Trasformations – предпочтения, запросы и требования клиентов к путешествию, выражаемые в покупке билетов на авиарейсы.

• Weltanschauung – прибыль может быть повышена более эффективной организацией продаж.

• Owner – менеджмент пассажирских авиаперевозок.

• Environment – международные законодательные акты, касающиеся международных авиаперевозок, и национальные законодательства. Общенациональные требования безопасности.

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

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

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

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

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

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

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

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

1) иерархической структурой задач и целей пользователя;

2) лингвистико-грамматическими моделями;

3) физическими моделями (в основном исполнительных действий на уровне «человек – пульт управления»).

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

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

3.4.1. Иерархическая структура задач и целей пользователя

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

• степень детализации:

• где мы начнем;

• где мы закончим;

• обычные приемы при изучении поведенческих аспектов (а не решения проблем):

– задача выделенного блока (модуля) поведения;

• конфликт:

– более одного пути достижения цели;

• ошибки.

Выделяют следующие технологии декомпозиции:

• метод GOMS;

• теорию когнитивной сложности (CCT);

• иерархический анализ задач.

Наиболее распространенным вариантом реализации этих моделей являются модели, объединенные аббревиатурой GOMS (Goals, Operators, Methods, Selections – цели, операторы, методы, правила их выбора), и модели когнитивной сложности, обозначаемые обычно как CCT (Cognitive Complexity Theory).

Составляющие модели GOMS следующие.

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

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

Методы, которыми может быть получен тот или иной результат.

Скажем, вызов файла может производиться из подменю «Документы» меню «Старт», если этот файл недавно использовался, или «кли-каньем» на его иконке, если такая иконка выведена у нас на экран, или вызовом определенного диска, поиском в нем соответствующей папки, пока не найден этот файл, или с помощью поиска меню «Найти» и т.д. В методе GOMS каждый из путей представлен в виде иерархической структуры и в связке с соответствующим методом его выполнения.

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

Из всего этого видно, что анализ в терминах GOMS практически всегда лежит на пути декомпозиции некоей целостной задачи. Типичный GOMS-анализ состоит, следовательно, из какой-либо одной задачи сравнительно высокого уровня, и далее идет ее древовидная декомпозиция до уровня простейших действий. GOMS-анализ может содержать и характеристики деятельности. Глубина цепочки подцелей может использоваться для оценки требований к кратковременной памяти. Кроме того, в GOMS-анализе часто используют значения времени для каждого действия, чтобы прогнозировать временные затраты (см. разд. 4.2). Такие значения предварительно определяют в экспериментальных исследованиях. Методология модели GOMS является, по сути, базовой для большинства когнитивных моделей, используемых в челове-ко-компьютерном взаимодействии. Эта методология хорошо подходит для описания исполнительских действий, а при известных физических устройствах, на которых производятся эти исполнительские действия, она успешно используется и для прогнозирования времени выполнения различных задач. Пример декомпозиции на основе метода GOMS:

ЦЕЛЬ: ЗАКРЫТЬ-ОКНО

• [select GOAL: USE-MENU-METHOD

• MOVE-MOUSE-TO-FILE-MENU

• PULL-DOWN-FILE-MENU

• CLICK-OVER-CLOSE-OPTION GOAL: USE-CTRL-W-METHOD

• PRESS-CONTROL-W-KEYS]

Для конкретного пользователя:

Правило 1: Select USE-MENU-METHOD unless another rule applies Правило 2: If the application is GAME, select CTRL-W-METHOD

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