stringtranslate.com

Анализ задачи

Анализ задач является фундаментальным инструментом инженерии человеческого фактора . Он включает в себя анализ того, как выполняется задача, включая подробное описание как ручной, так и умственной деятельности, продолжительности задач и элементов, частоты задач, распределения задач, сложности задач, условий окружающей среды, необходимой одежды и оборудования, а также любых других уникальных факторов, участвующих в или требуется одному или нескольким людям для выполнения определенной задачи. [1]

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

Анализ критических задач безопасности

Анализ критических задач безопасности (SCTA) фокусируется на том, как выполняются задачи, имеющие решающее значение для риска крупных аварий. SCTA — это важнейшая оценка, предназначенная для прогнозирования и понимания роли человеческой ошибки в крупных авариях. [3] Это тип семинара, проводимый для поддержки отраслей, подверженных риску крупных аварий (MAH), таких как нефтегазовая и химическая промышленность. Те действия или задачи, которые определены как критичные для безопасности (т. е. могут привести к значительному воздействию на окружающую среду или вреду людям в случае неправильного выполнения), проходят через SCTA, который разбивает задачу на поэтапный процесс и просмотрите места, где наиболее вероятны ошибки. Целью этого является определение того, где можно ввести дополнительные меры контроля, которые снизили бы вероятность человеческой ошибки при выполнении столь важной задачи.

Институт энергетики Великобритании выпустил руководящий документ под названием «Руководство по критическому анализу безопасности человеческого фактора» [4].


Приложения

Термин «задача» часто используется как синоним деятельности или процесса. Анализ задачи часто приводит к иерархическому представлению того, какие шаги необходимы для выполнения задачи, для которой есть цель и для которой существует некое «действие» или взаимодействие на самом низком уровне между людьми и/или машинами: это известно как иерархическая задача. анализ . Задачи могут быть идентифицированы и определены на нескольких уровнях абстракции, необходимых для достижения цели анализа. Анализ критических задач , например, представляет собой анализ требований к производительности человека, который, если не будет выполнен в соответствии с системными требованиями, вероятно, окажет неблагоприятное воздействие на стоимость, надежность системы, эффективность, результативность или безопасность. [5] Анализ задач часто выполняется специалистами по человеческому фактору и эргономике .

Анализ задач может относиться к ручным задачам, таким как кладка кирпича, и анализироваться как исследования времени и движения с использованием концепций промышленного проектирования . Когнитивный анализ задач применяется в современных рабочих средах, таких как надзорный контроль , где физическая работа выполняется мало, но задачи больше связаны с оценкой ситуации , принятием решений , а также планированием и исполнением ответных мер. [6]

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

Результаты анализа задач часто представляются в моделях задач, которые четко указывают на отношения между различными задачами. Примером обозначения, используемого для определения моделей задач, является ConcurTaskTrees (автор Фабио Патерно ), который также поддерживается инструментами, которые находятся в свободном доступе. [7]

Для включения

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

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

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

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

Анализ рабочей области по сравнению с анализом рабочей области

Если анализ задачи сравнивают с набором инструкций о том, как перемещаться из точки А в точку Б, то анализ рабочей области (WDA) подобен карте местности, включающей точки A и точки B. WDA шире и фокусируется на экологические ограничения и возможности поведения, как в экологической психологии Гибсона и дизайне экологических интерфейсов (Висенте, 1999; Беннетт и Флах, 2011, стр. 61).

Документация

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

Такая ориентация на задачи в технической документации началась с публикации руководств, выпущенных IBM в конце 1980-х годов. Более поздние исследования IBM привели к созданию теории минимализма Джона Кэрролла в 1990-х годах. [10]

С развитием XML как языка разметки, подходящего как для печати, так и для онлайн-документации (заменив SGML акцентом на печать), IBM в 2000 году разработала XML-стандарт Darwin Information Typing Architecture . Теперь это стандарт OASIS , DITA уделяет большое внимание решению задач. анализ. Его три основных типа информации — это задача, концепция и ссылка. Задачи анализируются на этапы, основная цель которых — определить шаги, которые можно повторно использовать в нескольких задачах.

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

Иерархический анализ задач (HTA) — метод описания задач и вариант анализа задач. Описание задачи является необходимым предшественником других методов анализа, включая анализ критического пути (CPA). ОМТ используется для получения исчерпывающего описания задач в иерархической структуре целей, подцелей, операций и планов. [11] В HTA задачи разбиваются на все более мелкие блоки. [12]

Операции и планы

Операции — это действия, выполняемые людьми, взаимодействующими с системой, или самой системой [13] , а планы объясняют условия, необходимые для этих операций. [1] Операции описывают мельчайшие отдельные этапы задачи в ОМТ, т.е. те, которые невозможно разбить на планы и дальнейшие операции. Это отдельные действия, такие как «визуальное обнаружение элемента управления» или «перемещение руки к элементу управления», которые пользователь должен выполнить в определенной комбинации для достижения цели выполнения задачи.

Применение

При проведении ОМТ необходимо выполнить следующие шаги:

  1. Определите исследуемую задачу и определите цель анализа задачи. Аналитик должен иметь в виду некоторые дополнительные методы оценки, для которых будет полезен ОМТ, и иметь основания для необходимости проведения такого типа анализа.
  2. Сбор данных. Для проведения ОМТ необходимо получить данные о том, как выполняется задача. Эту информацию можно получить путем наблюдения за рассматриваемой задачей или из подробной спецификации анализируемого устройства. Альтернативно, для сбора необходимой информации можно провести интервью или анкетирование с людьми, имеющими непосредственный опыт выполнения этой задачи.
  3. Определите общую цель задачи, которая будет представлена ​​как верхний уровень в HTA. Примером может быть «увеличить скорость вентилятора на два шага». Это описывает то, что достигается выполнением задачи; однако на данном этапе нет никаких указаний на то, как будет выполняться задача.
  4. Определите следующий уровень подцелей, разбив общую цель. Подцелью приведенного выше примера может быть «открыть климатическое меню». Это предоставляет дополнительную информацию о том, как выполнить задачу; однако его все равно можно разбить на более мелкие блоки, которые будут описывать отдельные операции (выполняемые с помощью визуального, ручного или когнитивного режимов), которые необходимо выполнить.
  5. Продолжайте разбивать подцели, пока не будут определены все операции. Операции в «задаче снижения скорости вентилятора» будут включать в себя «переместить палец на кнопку меню климата» и «коснуться кнопки меню климата».
  6. Определите планы, описывающие, как выполнять операции на каждом уровне подцелей иерархии. В примере со скоростью вентилятора две операции необходимо выполнить последовательно, одну за другой. План предложит пользователю «выполнить 1, затем 2». Операции также могут выполняться параллельно, и в этом случае план будет содержать указание пользователю «выполнить 1 и 2 вместе». Числа должны быть присвоены различным уровням иерархии.

Организация иерархии

Каждый уровень в HTA должен быть пронумерован в соответствии с его иерархическим уровнем: общая цель — это самый высокий уровень иерархии, и ей должен быть присвоен номер 0. Первой подцелью в иерархии будет номер 1, также с планом 1. Дальнейшие уровни просто расширяют этот уровень. система – третий уровень иерархии: 1.1, четвертый уровень иерархии: 1.1.1 и так далее. HTA может быть представлен в виде списка или диаграммы. В форме списка строки должны иметь отступы для обозначения различных уровней иерархии. В виде диаграммы каждая операция должна быть помещена в блок и между ними должны быть установлены связи: более низкий иерархический уровень должен ответвляться из-под операции более высокого уровня. Планы должны быть написаны рядом с ветвями, чтобы описать способ выполнения разветвленных операций. Следовательно, планы должны быть ориентированы на достижение успеха в любой области.

Приложения и ограничения

HTA — это метод описания задач, который чаще всего используется в качестве отправной точки для дальнейшего анализа, такого как мультимодальный CPA и SHERPA. [13] Сама по себе HTA не предоставляет результатов для оценки юзабилити; однако вы должны быть в состоянии изучить HTA, чтобы узнать структуру различных задач. Это также может позволить вам выделить ненужные шаги задачи или потенциальные ошибки, которые могут возникнуть при выполнении задачи. HTA — довольно трудоемкий метод, поскольку необходимо анализировать каждую отдельную операцию в задаче; однако создание комплексной ОМТ может значительно сократить время, необходимое для других методов моделирования.

Смотрите также

Примечания

  1. ^ аб Кирван, Б. и Эйнсворт, Л. (ред.) (1992). Руководство по анализу задач . Тейлор и Фрэнсис.{{cite book}}: CS1 maint: несколько имен: список авторов ( ссылка )
  2. ^ Хакос, Джоанн Т. и Редиш, Дженис К. (1998). Анализ пользователей и задач для проектирования интерфейсов . Уайли.
  3. ↑ Технический, Салус (27 октября 2022 г.). «Первое в своем роде программное обеспечение для анализа задач предназначено для уменьшения человеческих ошибок в отраслях с высокой степенью опасности». Анализ задач — новое программное обеспечение .
  4. ^ Институт энергетики. «Руководство по программному обеспечению для критического анализа безопасности человеческого фактора» (PDF) . ЭИ СКТА .
  5. ^ Описание элемента данных Министерства обороны США (DID) DI-HFAC-81399B: Отчет об анализе критических задач . 2013.
  6. ^ Крэндалл Б., Кляйн Г. и Хоффман Р. (2006). Рабочие умы: Руководство для практикующего специалиста по когнитивному анализу задач . МТИ Пресс.{{cite book}}: CS1 maint: несколько имен: список авторов ( ссылка )
  7. ^ Фабио Патерно (2002). CTTE: Поддержка разработки и анализа моделей задач для проектирования интерактивных систем . IEEE.
  8. ^ Хакос и Редиш, 1998.
  9. ^ Брокманн, Р. Джон (1986). Написание более качественной пользовательской документации для компьютера – от бумаги к Интернету . Уайли-Интерсайенс. ISBN 978-0-471-88472-9.
  10. ^ Кэрролл, Джон М. (1990). Нюрнбергская воронка – разработка минималистских инструкций для практических навыков работы с компьютером . Массачусетский технологический институт.
  11. ^ Стэнтон, Северная Каролина; Лосось, ПМ; Уокер, Г.Х.; Бабер, К.; Дженкинс, Д.П. (2005). Методы человеческого фактора: практическое руководство для инженеров и проектировщиков . Олдершот, Великобритания: Эшгейт.
  12. ^ Лайонс, М (2010). «На пути к выбору методов прогнозирования ошибок: поддержка начинающих пользователей в секторе здравоохранения». Прикладная эргономика . 40 (3): 379–395. дои : 10.1016/j.apergo.2008.11.004. ПМИД  19091307.
  13. ^ аб Стэнтон, Северная Каролина (2006). «Иерархический анализ задач: разработки, приложения и расширения». Прикладная эргономика . 37 (1): 55–79. CiteSeerX 10.1.1.568.7814 . дои : 10.1016/j.apergo.2005.06.003. ПМИД  16139236. 

Висенте, К.Дж. (1999). Когнитивный анализ работы: на пути к безопасной, продуктивной и здоровой работе на компьютере. ЛЕА.

Беннетт, К.Б., и Флах, Дж.М. (2011). Дизайн дисплея и интерфейса: Тонкая наука, точное искусство. ЦРК Пресс.

Внешние ссылки