В настоящем стандарте приведена структура человеко-ориентированного проектирования. В стандарте не описан какой-либо определенный процесс проектирования, а также не описана вся деятельность по созданию результативного проекта системы. Стандарт дополняет существующие методологии проектирования и вводит человеко-ориентированный принцип, который может быть встроен в различные процессы проектирования и разработки. Все человеко-ориентированные действия по проекту, установленные в разделе 6, применимы (в большей или меньшей степени) к любому этапу разработки системы.
Какие бы процессы проектирования и распределения ответственности и функций ни были приняты, человеко-ориентированный подход должен следовать описанным в 4.2 - 4.7 принципам:
a) проектирование должно быть основано на точном определении предполагаемых пользователей, задач и среды (см. 4.2);
b) пользователи должны быть вовлечены в проектирование и разработку (см. 4.3);
c) для улучшения проекта должна быть выполнена его человеко-ориентированная оценка (см. 4.4);
d) совершенствование проекта должно быть итеративным (см. 4.5);
e) проект должен учитывать опыт пользователя (см. 4.6);
f) в группу проектирования должны быть включены специалисты с навыками и знаниями в различных областях (см. 4.7).
Продукция, системы и услуги должны быть разработаны таким образом, чтобы учитывать влияние (прямое или косвенное), которое они могут оказать на все причастные стороны. Следовательно, все важные группы пользователей и причастных сторон должны быть определены. Построение систем на основе неверного или неполного понимания потребностей пользователей является одним из главных источников отказа системы.
Степень пригодности и доступности зависит от условий использования, т.е. установленных пользователей, имеющих установленные цели, выполняющих установленные задачи в определенных условиях использования (см. ИСО 9241-11). Например, интерфейс, подходящий для молодых людей, загружающих музыку на телефон, может быть полностью неподходящим для доступа к корпоративным данным с помощью карманного компьютера. Характеристики пользователей, задач и вариантов среды называют условиями использования. Руководство по сбору необходимой информации приведено в 6.2. Условия использования - это главный источник информации для установления требований пользователей (см. 6.3) и важный момент в процессе проектирования.
Вовлечение пользователей в проектирование и разработку является важным источником знаний об условиях использования, задачах, и о том, как пользователи будут применять продукцию, систему или услугу. Вовлечение пользователя должно быть активным, он может участвовать в проектировании как источник важных данных или участвовать в оценке тех или иных решений. Характеристики пользователей, вовлеченных в проектирование, должны отражать весь диапазон характеристик пользователей, для которых разрабатывают систему. Способы и частота привлечения к проектированию пользователей изменяются в процессе проектирования и разработки и зависят от особенностей проекта. Результативность вовлечения пользователя возрастает с увеличением активности взаимодействия между разработчиками и пользователями.
Если систему проектируют по заказу, совокупность предполагаемых пользователей и выполняемые задачи должны быть использованы при разработке. Организация, приобретающая систему, имеет возможность непосредственно влиять на разработку проекта, а работники, которые будут работать с системой, могут принимать участие в оценке предлагаемых решений. Такое вовлечение и участие также может увеличить одобрение и заинтересованность пользователя.
При проектировании универсальных или потребительских продуктов совокупность пользователей может представлять собой группы пользователей с определенными характеристиками. В этом случае необходимо, чтобы пользователи или их представители были вовлечены в разработку проекта для учета требований пользователей и задач, важных для предполагаемых групп пользователей, идентификации и включения требований пользователей в спецификацию системы, а также для получения отзывов при испытаниях исследуемых образцов и оценки вариантов проектных решений.
Отзывы пользователей являются важным источником информации при человеко-ориентированном проектировании. Оценка проекта с участием пользователей и его улучшение на основе отзывов пользователей являются эффективными средствами минимизации риска несоответствия системы нуждам пользователей или организации-заказчика (включая трудно выявляемые требования). Такая оценка позволяет проводить проверки предварительных проектных решений на соответствие реальным условиям, что позволяет постепенно совершенствовать проект. Оценка проекта пользователями должна быть частью проверки выполнения требований к проекту при его приемке. Отзывы пользователей при использовании системы выявляют отдаленные проблемы и являются основой для последующих модификаций системы.
Примечание - Оценка пользователем предполагает, что пользователи выполняют проверку проекта на соответствие его требованиям пользователей.
Наиболее подходящий проект интерактивной системы обычно не может быть разработан сразу.
Примечание 1 - Итерация означает повторение последовательности действий до тех пор, пока не будет достигнут желаемый результат.
Примечание 2 - В методах разработки, которые состоят из небольших циклов разработки, итерации в человеко-ориентированном проектировании могут быть выполнены сначала на отдельных частях системы, а затем на макро-уровне для продукции, системы или услуги в целом.
Итеративный подход позволяет постепенно устранять неопределенность интерактивных систем. На каждой итерации описания, спецификации и образцы пересматривают и улучшают при получении новой информации с целью минимизации риска несоответствия разрабатываемой системы требованиям пользователей.
Сложность взаимодействия человека с компьютером означает, что невозможно полно и точно определить каждую деталь каждого аспекта этого взаимодействия в начале разработки. Многие потребности и ожидания пользователей и других причастных сторон, влияющие на разработку взаимодействия человек-компьютер, выявляются только в процессе проектирования, по мере того как у разработчиков углубляется понимание требований пользователей и их задач, а пользователи определяют свои пожелания при анализе представленных проектных решений.
Итерация проектных решений, включающая отзывы пользователей, является средством снижения риска невыполнения требований пользователей.
Пример 1 - Отзывы пользователей являются основой для пересмотра предполагаемых условий использования, пересмотра требований и совершенствования проектных решений.
Пример 2 - Спецификация требований совершенствуется в процессе итерации при применении сценариев, использования макетов и образцов системы с отзывами пользователей о соответствии разрабатываемых систем требованиям пользователей.
Разработка других аспектов проекта также может потребовать применения итеративного подхода, например, для обеспечения технологичности изготовления продукта, его влияния на рабочую среду или изменения на рынке.
Восприятие пользователем системы формируется на основе образа торговой марки, способа представления, функциональности, производительности системы, интерактивных свойств и вспомогательных возможностей системы, в которую может входить как аппаратное обеспечение, так и программное обеспечение. Опыт пользователя охватывает предшествующий опыт, привычки, навыки и индивидуальные особенности пользователя. Существует распространенное заблуждение, что пригодность использования означает только то, что продукцию легко использовать. В соответствии со стандартами серии ИСО 9241 пригодность использования следует понимать более широко, учитывая личные цели пользователя, в том числе его эмоций и ощущения, обычно связанные с восприятием пользователем системы, а также удовлетворенность работой и отсутствие монотонии.
Анализ восприятия пользователем системы включает рассмотрение (где уместно) влияния организации, документации пользователя, оперативной помощи пользователю, сопровождения и обслуживания (включая справочные службы и пункты обслуживания потребителей), обучения, вариантов долгосрочного использования и упаковки продукции (включая "использование из коробки"). Восприятие пользователем предыдущих моделей или других аналогичных систем, а также вопросы образа торговой марки и рекламы также должны быть учтены. Необходимость учитывать различные факторы и их взаимозависимость должна быть учтена в плане проектирования (см. раздел 5).
Возможности, ограничения, предпочтения и ожидания пользователей необходимо учитывать при определении того, какие функции должен выполнять пользователь, а какие - система или продукция.
Примечание 1 - В системах, где обеспечение безопасности или выполнение задачи имеют критическое значение, более важным, чем удовлетворение предпочтений пользователя, может быть обеспечение результативности или эффективности системы.
Проектные решения, связанные с распределением функций системы, определяют степень автоматизации, а также работы и задачи, выполняемые пользователем, его функции и ответственность. Решения основаны на многих факторах. Они включают возможности и ограничения людей в сравнении с техническими средствами с точки зрения надежности, скорости, точности, силы, гибкости отклика, финансовых расходов, важности выполнения задач успешно и в срок, безопасности и удовлетворенности пользователя (как краткосрочной, например комфорта и удовольствия, так и долгосрочной, например здоровья, благополучия и удовлетворенности работой). Решение передать техническим средствам выполнение всех функций, которые они могут выполнить, а оставшиеся функции отдать пользователю, скорее всего, приведет к разработке неэффективного проекта. Распределение функций описано в 6.4.2.2.
К принятию таких решений следует привлекать представительных пользователей.
Примечание 2 - "Представительный" в данном контексте означает соответствующий целевой совокупности конечных пользователей.
Определенные таким образом действия пользователя должны охватывать набор задач, который должен восприниматься пользователем как единое целое. Это особенно важно для изготавливаемых на заказ систем, когда использование системы обеспечивает выполнение главных элементов работы пользователя (см. также ИСО 9241-2 и ИСО 10075).
Группы человеко-ориентированного проектирования не должны быть большими, но они должны быть способны совместно вырабатывать проектные решения. В состав группы проектирования могут входить специалисты с различными точками зрения и обладающие знаниями в разных научных областях:
a) специалисты в области антропометрии и эргономики, пригодности использования, взаимодействия человек-компьютер, анализа предполагаемой совокупности пользователей;
b) пользователи и другие причастные стороны (люди, способные представить свою точку зрения);
c) эксперты в определенной области;
d) специалисты по маркетингу, брендингу, продажам, технической поддержке и обслуживанию, здоровью и безопасности;
e) разработчики пользовательского интерфейса, визуального проектирования и проектирования продукции;
f) специалисты по составлению технического описания, обучению, поддержке пользователей;
g) специалисты по управлению, организации обслуживания и корпоративному управлению;
h) специалисты по анализу экономической деятельности, системному анализу;
i) специалисты по системному проектированию, проектированию программного и аппаратного обеспечения, программированию, изготовлению и обслуживанию;
j) специалисты в области человеческих ресурсов, устойчивого развития и др.
Креативность и идеи участников группы, их взаимодействие и сотрудничество благотворно сказывается на разработке проекта. Дополнительным преимуществом междисциплинарного подхода и учета разных точек зрения является повышение осведомленности участников группы об ограничениях и положении дел в других дисциплинах; например, технические эксперты получают возможность лучше узнать проблемы пользователей, а пользователи становятся более осведомленными о технических ограничениях.
Человеко-ориентированное проектирование должно быть спланировано и интегрировано во все этапы жизненного цикла продукта, т.е. в разработку концепции, анализ, проектирование, изготовление, испытания и техническое обслуживание.
Специалисты, ответственные за планирование проекта, должны учитывать значимость выполнения эргономических требований в проекте, оценивая:
a) связь пригодности использования с целью и использованием продукта, системы или услуги (например, с размером системы, количеством пользователей, наличием связи с другими системами, безопасностью, охраной здоровья, доступностью, экстремальными условиями);
b) уровни различных видов риска, которые могут возникнуть в результате низкой пригодности использования (например, финансовых опасностей; опасностей, связанных с плохой дифференциацией продукции, низкой безопасностью, низким обеспечением пригодности использования и т.п.);
c) свойства среды разработки (например, размер проекта, время выхода на рынок, диапазон технологий, внешний или внутренний проект, тип контракта).
Примечание 1 - Недооценка степени взаимодействия с пользователем распространена в проектах полностью автоматизированных систем. Часто это приводит к тому, что таким системам впоследствии требуется значительное взаимодействие с пользователем.
В общих чертах целью является выбор наиболее подходящих методов и процедур идентификации и уменьшения риска взаимодействия человек-система.
Примечание 2 - Описание методов разработки человеко-ориентированного проекта приведено в ИСО/ТО 16982. Информация о процессах человеко-ориентированного проектирования, которые могут быть использованы для выполнения требований настоящего стандарта приведена в ИСО/ТО 18529. В ИСО/ТО 18529 в стандартной форме приведены модели и процессы для включения человеко-ориентированного проектирования в системную стратегию, а также для внедрения и работы интерактивных систем. Детали процессов, используемых организацией для определения и решения широкого диапазона проблем продукции и процессов, связанных с применением человеко-ориентированного проектирования приведены в ИСО/PAS 18152. Руководство по человеко-ориентированному проектированию систем, в которых надежность является критичной, приведено в МЭК 62508.
Планирование человеко-ориентированного проектирования должно включать:
a) определение методов и ресурсов для выполнения деятельности, описанной в разделе 6;
b) определение процедур для интегрирования этой деятельности и ее результатов с другой деятельностью по разработке системы;
c) определение лиц и организаций, ответственных за разработку человеко-ориентированного проекта, а также необходимых навыков и точек зрения, которые они обеспечивают;
d) разработку эффективных процедур обратной связи и обмена информацией по человеко-ориентированному проекту, так как они влияют на другую проектную деятельность, принятие компромиссных решений и разработку методов документирования результатов проектной деятельности;
e) соглашение по подходящим контрольным точкам в общем процессе проектирования и разработки, в которых привлекают к работе пользователей;
f) соглашение по интервалам времени для итеративного изучения обратной связи и разработки изменений проекта, которые необходимо включить в график выполнения проекта.
План человеко-ориентированного проектирования должен быть частью общего плана проекта. Для обеспечения результативного применения план человеко-ориентированного проектирования следует рассматривать таким же образом, как и другую ключевую деятельность (например, с точки зрения распределения ответственности, организации управления). Аспекты человеко-ориентированного проектирования в общем плане проекта должны подвергаться проверке и пересмотру в случае изменения требований на определенном этапе проектирования.
В общем плане проекта для человеко-ориентированного проектирования должны быть выделены время и ресурсы. Это должно быть время для выполнения итерации и сбора отзывов пользователей, а также для оценки соответствия проектного решения требованиям пользователей.
Для общения участников проектной группы, улаживания возможных споров и нахождения компромиссов по проблемам взаимодействия человек-система также должно быть выделено время. Дополнительное общение и обсуждение вопросов пригодности использования на ранних этапах выполнения проекта позволяет существенно сэкономить время на поздних этапах, когда изменения проекта являются более затратными.
Разработка человеко-ориентированного проекта должна начинаться на самом раннем этапе проектирования (например, как часть разработки концепции продукта или системы). Аспекты человеко-ориентированного проектирования необходимо пересматривать на протяжении выполнения всего проекта.
После определения необходимости разработки системы, продукта или услуги и принятия решения об использовании человеко-ориентированного проектирования для его осуществления применяют четыре вида человеко-ориентированной проектной деятельности, выполняемых в процессе проектирования любой интерактивной системы:
a) понимание и определение условий использования (см. 6.2);
b) определение требований пользователей (см. 6.3);
c) разработка проектных решений (см. 6.4);
d) анализ проекта (см. 6.5).
Эти виды деятельности позволяют учесть следующие проблемы:
- обычно существует определенное количество различных групп пользователей и других причастных сторон, чьи потребности необходимо учитывать;
- условия использования могут быть различны для разных групп пользователей и при выполнении различных задач;
- в начале проектирования требования, которые можно определить, обычно не являются исчерпывающими;
- некоторые требования выявляются только после представления готового решения;
- требования пользователей могут быть различными и несовместимыми друг с другом и с требованиями различных причастных сторон;
- первые проектные решения редко удовлетворяют всем нуждам пользователей;
- трудно комплексно рассмотреть все части системы.
На высоком уровне действия по человеко-ориентированному проектированию соответствуют всем этапам проектирования и разработки - от требований, возникающих в процессе проектирования, до верификации и валидации проекта. На более детальном уровне эта деятельность может быть применена для получения данных обратной связи на стадиях разработки проекта от концепции до окончательного утверждения требований. Анализ первых (грубых) образцов и макетов системы способствует более глубокому пониманию потребностей пользователей и получению отзывов о концепции проекта. Эти действия могут быть применены при пересмотре интерактивной системы и могут быть полезны для анализа системы в обычной работе.
Примечание - Действия человеко-ориентированного проектирования могут быть использованы при применении различных принципов проектирования, например, объектно-ориентированного, каскадного, гибкого, интегрирования человеческих факторов, быстрой разработки приложений.
На рисунке 1 схематично представлена взаимосвязь действий человеко-ориентированного проектирования. Она не предполагает строго линейного процесса; напротив, она показывает, что в каждом действии человеко-ориентированного проектирования используют результаты других проектных действий.
![]() человеко-ориентированного проектирования
6.2.1 Общая информация
Характеристики пользователей и задач, а также организационная, техническая и физическая среда определяют условия использования будущей системы. Полезно собирать и анализировать информацию о текущих условиях, чтобы понять, а затем и определить условия, в которых будет использована будущая система. Анализ существующих или аналогичных систем (включая системы с ручным управлением) может дать информацию обо всем диапазоне условий использования, включая нехватку и базовые уровни производительности и удовлетворенности пользователя.
Анализ условий использования может выявить нужды, проблемы и ограничения, которые должны быть учтены в будущей системе. Некоторые аспекты условий использования при разработке новой системы сохраняют, даже если конструкция системы является новаторской. Если существующая система должна быть модернизирована, определенная информация о системе известна. Если существуют отзывы пользователей, отчеты службы технического обслуживания и другая информация, то она может составить основу для определения необходимости изменений и улучшений системы.
Примечание 1 - Для описания условий использования может быть использовано описание существующих или планируемых условий использования.
Примечание 2 - В ИСО/ТО 16982 приведена информация о методах сбора и передачи информации об условиях использования.
Условия использования должны включать в себя:
a) Описание пользователей и других причастных сторон. Может существовать несколько различных групп пользователей, а также других причастных сторон, чьи нужды должны быть учтены. Такие группы и причастные стороны должны быть определены, а их связь с процессом проектирования описана с позиции ключевых целей и ограничений.
b) Характеристики пользователей или групп пользователей. Важные характеристики пользователей должны быть определены. Они могут включать знания, навыки, опыт, образование, подготовку, физические характеристики, привычки, предпочтения и возможности пользователей. При необходимости должны быть определены характеристики различных групп пользователей, например, пользователей с разными уровнями опыта или физических возможностей. В целях обеспечения доступности продукции системы или услуги должны быть разработаны таким образом, чтобы их могли использовать люди из предполагаемой совокупности пользователей с самым широким диапазоном возможностей. Во многих странах этого требует действующее законодательство.
Примечание - В ИСО/МЭК/ТО 29138-1 установлен диапазон потребностей пользователей, который необходимо учитывать для обеспечения доступности изделий для людей с ограниченными возможностями.
c) Цели и задачи пользователей. Цели пользователей и общие цели системы должны быть определены. Характеристики задач, которые могут повлиять на пригодность использования и доступность системы, должны быть описаны (например, наиболее распространенный способ выполнения пользователями задачи, частота и продолжительность работы, взаимосвязь параллельно выполняемых действий). Если существуют неблагоприятные последствия для здоровья и безопасности (например, чрезмерная рабочая нагрузка), или риск неверного выполнения задачи (например, совершена ошибка при покупке), это также должно быть определено. Описание задач не должно ограничиваться описанием функций или свойств продукта или системы.
d) Описание среды системы. Техническая среда, включая аппаратное обеспечение, программное обеспечение и материалы, должна быть определена. Кроме того должны быть описаны важные характеристики физической, социальной и культурной среды. Физические факторы включают температурные условия, освещение, пространственное размещение и меблировку и т.п. Социальные и культурные аспекты среды включают организационную структуру, принятые подходы и порядок выполнения работы.
Для обеспечения выполнения требований, а также анализа проекта, условия использования системы должны быть описаны достаточно подробно.
Примечание - Описание условий использования - это рабочий документ, который создают как черновик, а затем пересматривают, дополняют и актуализируют в процессе проектирования и разработки. Например, на ранних этапах проектирования могут быть определены только основные цели, а действия для их достижения не определены. Такой документ также может быть полезен для определения необходимых изменений при выполнении анализа условий использования.
Условия использования системы, определенные для разработки проекта (т.е. условия, в которых система будет использоваться) должны быть установлены в спецификации требований пользователей. Дополнительная информация об условиях использования приведена в ИСО 9241-11, а информация об условиях использования изделий повседневного использования приведена в ИСО 20282-1.
Для большей части проектов ключевым моментом является определение требований пользователей, а также функциональных и других требований к продукту или системе. В случае человеко-ориентированного проектирования составляют подробное описание требований пользователей по отношению к предполагаемым условиям использования и рабочим целям системы.
В зависимости от области применения системы требования пользователей могут включать организационные изменения, изменение стиля работы, а также предложения по компоновке продуктов и услуг. Если известно, что разрабатываемая интерактивная система повлияет на установленный порядок деятельности организации, то в процесс разработки должны быть вовлечены причастные стороны с целью оптимизации работы системы с организационной и технической сторон.
Потребности пользователей и других причастных сторон должны быть определены с учетом условий использования. Следует определить потребности, которые должны быть удовлетворены, (а не способы, с помощью которых данные потребности должны быть удовлетворены) с учетом всех ограничений, налагаемых условиями использования.
Описание требований пользователей должно включать:
b) требования, полученные на основе потребностей пользователей и условий использования (например, может существовать требование к уличному использованию продукта);
c) требования, установленные с учетом эргономических требований, требований пользовательских интерфейсов, стандартов и т.п. (например, требования к доступности, приведенные в ИСО 9241-20 и ИСО 9241-171);
d) требования и цели пригодности использования, включающие критерии производительности и удовлетворенности пользователя в определенных условиях использования - например, целью может быть успешное переключение входящего звонка на голосовую почту 90% пользователей, или эстетичный дизайн интернет-страницы для получения необходимой оценки удовлетворенности пользователя;
e) требования, установленные на основе организационных требований, влияющих на пользователя - например, система центра обработки звонков может требовать, чтобы ответ на звонки производился в пределах определенного периода времени.
Требования пользователей являются основой для разработки и оценки соответствия интерактивных систем пожеланиям пользователей.
Требования пользователей разрабатывают вместе с общими требованиями к интерактивной системе.
Возможные противоречия в требованиях пользователей, например между точностью и скоростью должны быть устранены.
Значение различных аспектов взаимодействия человек-система, выбранные показатели и обоснование принятых оптимальных решений должны быть документированы.
Примечание - Принятые компромиссы могут потребовать пересмотра начальных предложений и вовлечения причастных сторон.
Спецификация требований пользователей должна быть:
Проектные решения существенно зависят от восприятия пользователем системы. Человеко-ориентированное проектирование позволяет учесть восприятие пользователем системы в процессе проектирования (см. 4.6).
Проектные решения создают на основе описания условий использования, результатов исходных оценок, современных достижений в предметной области, требований стандартов и руководств по проектированию и пригодности использования, а также опыта и знаний междисциплинной группы проектирования. По мере детализации и оценки проектных решений могут возникать новые требования пользователей.
Создание проектных решений может включать следующую деятельность:
a) разработку задач пользователя, взаимодействия пользователя и системы и пользовательского интерфейса с учетом требований и восприятие пользователем системы;
b) детализацию проектных решений (например, с помощью использования сценариев, моделирования, образцов или макетов);
c) внесение изменений в проектные решения на основе анализа и отзывов (информация об анализе проекта приведена в 6.5);
6.4.2 Разработка пользовательских задач взаимодействия человек-система и пользовательского интерфейса в соответствии с требованиями пользователей с учетом восприятия пользователем системы
Проектирование с учетом восприятия пользователем системы - это процесс инноваций, который позволяет учитывать удовлетворенность пользователя (включая эмоциональные и эстетические аспекты), а также результативность и эффективность выполнения задач. При проектировании могут быть использованы различные творческие подходы для разработки проекта, соответствующего восприятию пользователем системы.
При разработке интерактивных систем необходимо учитывать следующие принципы (по ИСО 9241-110):
Примечание 1 - "Информативность" [b)] означает, что пользователь понимает, на каком этапе диалога он находится, какие действия и каким образом он может предпринять.
Примечание 2 - Существуют другие стандарты по принципам проектирования, которые могут быть использованы вместе с настоящим стандартом. Они приведены в библиографии.
Проект взаимодействия человек-система должен быть основан на четком понимании условий использования, включая действия пользователей, задачи и результат их выполнения. Это понимание позволяет достичь распределения функций и задач между человеком и техникой.
Если систему разрабатывают для использования в пределах определенной организации, например филиала банка, то проектирование системы также может включать проектирование работы и организационное проектирование. (В ИСО 9241-2 приведено руководство по проектированию работ и задач.)
Проект взаимодействия человек-система должен включать описание того, как пользователи будут выполнять производственные задачи с использованием системы, а не только того, что представляет собой система. Решения на этом уровне могут быть связаны с такими вопросами, как выбор модальности (например, звуковой, зрительной и тактильной) и выбор форм представления информации (например, в виде текста или графики, диалоговых окон или других программных инструментов, механических или электронных элементов управления).
Проектирование взаимодействия должно включать:
e) определение и выбор способов организации диалога (см. ИСО 9241-12, ИСО 9241-13, ИСО 9241-14, ИСО 9241-15, ИСО 9241-16 и ИСО 9241-17);
g) разработку информационной архитектуры пользовательского интерфейса интерактивной системы для обеспечения эффективного доступа к объектам взаимодействия.
Примечание - Порядок, в котором выполняют эти действия, зависит от типа разрабатываемого взаимодействия.
В области проектирования пользовательского интерфейса существует большое количество информации, стандартов и руководств, которые должны быть использованы при разработке аппаратных и программных элементов пользовательского интерфейса. В стандартах серии 9241 установлены требования, относящиеся к дисплеям, устройствам ввода, принципам диалога, меню, представлению информации, руководству пользователя. Могут быть использованы и другие руководства по разработке пользовательского интерфейса и обеспечению доступности системы. У многих организаций существуют внутренние руководства по стилю оформления пользовательского интерфейса, необходимой информации о продукции, предполагаемых пользователях и других аспектах условий использования, таких как ожидания пользователей (см. ИСО 1503) и стереотипы их поведения. Стандарты серии ИСО 9241 приведены в приложении A.
Использование сценариев, моделирования, макетов, экспериментальных образцов позволяет разработчикам представить проект системы пользователям и другим причастным сторонам для получения отзывов.
В результате:
a) проектные решения становятся более понятными и продуманными благодаря общению участников группы проектирования между собой и с пользователями на ранних этапах разработки проекта;
b) разработчики могут изучить несколько концепций проекта перед выбором одной из них для использования;
c) появляется возможность учесть отзывы пользователей на ранних этапах разработки проекта;
d) появляется возможность оценить несколько итераций проекта и альтернативные проекты;
e) улучшается качество и полнота функциональной спецификации проекта.
Простые образцы системы используют на ранних этапах проектирования для изучения альтернативных проектных решений. Создание проработанных образцов может быть полезным, однако уровень их проработки и детализации должен соответствовать проблемам и вопросам, исследуемым с их помощью.
Большие затраты времени или средств на создание проработанного образца могут быть неоправданными и привести к нежеланию вносить изменения в проект.
Данные анализа и обратной связи должны быть использованы для изменения и совершенствования системы (см. 6.5).
Примечание 1 - Данные обратной связи позволяют выявить сильные и слабые стороны проектного решения и могут предоставить новую информацию о потребностях пользователей и подсказать направления улучшения проекта.
Затраты и положительные стороны предлагаемых изменений следует проанализировать и учесть при принятии и обосновании решений об изменениях.
Примечание 2 - Усилия по изменению зависят от особенностей проблемы; они могут быть небольшими или потребовать значительных ресурсов, а решение о необходимости изменения проекта принимают, исходя из критичности проблемы.
Изменения, предлагаемые на основе анализа на ранних этапах разработки проекта обычно наиболее эффективны по затратам.
План проекта должен выделять достаточно времени для внесения изменений на основе данных обратной связи.
Существует множество путей передачи проектного решения ответственным за его осуществление и изготовление системы. Эффективные средства передачи могут быть различны (от предоставления документации до создания образцов и включения экспертов по человеко-ориентированному проектированию в группу разработки проекта).
Для обсуждения всех особенностей проекта должен быть создан канал обмена информацией между ответственными за человеко-ориентированное проектирование и другими участниками группы проектирования. При передаче проектного решения к нему должно быть приложено подробное обоснование, особенно в случае принятия компромиссных решений.
При передаче необходимо учитывать ограничения, накладываемые проектом, а также требованиями эргономики и требованиями проектирования пользовательского интерфейса.
Ориентированный на пользователя анализ проектного решения является необходимым элементом человеко-ориентированного проектирования.
Даже на самых ранних этапах проектирования при разработке концепции проекта следует анализировать концепцию, исходя из представлений о потребностях пользователей. Использование продукта, системы или услуги в реальной жизни является сложным процессом, анализ проекта, ориентированный на пользователя, является важным элементом человеко-ориентированного проектирования. Однако оценка проекта пользователями (испытания при участии пользователей см. 6.5.4) не всегда эффективна с точки зрения затрат на ее проведение на каждом этапе проектирования. В этом случае проектные решения должны быть исследованы другим способом - например, при помощи моделирования задач. Эти методы также ориентированы на выяснение восприятия пользователем системы, хотя пользователи и не участвуют в них напрямую.
Ориентированный на пользователя анализ проекта также может быть использован:
a) для сбора новой информации о потребностях пользователей;
b) для предоставления информации о сильных и слабых сторонах проектного решения с позиции пользователя (в целях улучшения проекта);
c) для определения степени выполнения требований пользователей (что может включать проверку соответствия международным, национальным, местным, корпоративным и обязательным стандартам);
d) для сравнения проектов.
Для выполнения анализа проекта пользователями должны быть предусмотрены:
a) выделение ресурсов для получения обратной связи на начальных этапах разработки проекта с целью улучшения проекта, а на более поздних этапах - для проверки выполнения требований;
b) планирование человеко-ориентированного анализа оценки в соответствии с графиком разработки проекта;
Существует большое количество ориентированных на пользователя методов, которые могут быть использованы для оценки проекта. Руководство по методам оценки пригодности использования и выбору наиболее подходящего метода или набора методов приведено в ИСО/ТО 16982.
Примечание - Дальнейшая информация, рекомендации по испытаниям, контрольные перечни и другие средства проверки соответствия эргономическим критериям приведены в стандартах, приведенных в приложении A и библиографии.
Для получения достоверных результатов оценка должна быть выполнена опытными специалистами с использованием подходящих методов.
Ориентированный на пользователя анализ проекта полезен на всех этапах разработки проекта от создания концепции до использования, так как он позволяет получить данные обратной связи, полезные для улучшения и модификации продукта, системы или услуги (см. 6.5.6). На начальных этапах проектирования и разработки внесение изменений не является затратным. По мере разработки проекта вместе с более полным определением параметров системы стоимость внесения изменений возрастает.
Для получения данных обратной связи как на начальных этапах проектирования, так и для валидации требований на более поздних этапах, должны быть выделены необходимые ресурсы. Область применения анализа проекта на последних этапах связана с проверкой выполнения требований.
Двумя распространенными способами анализа проекта, ориентированного на пользователя являются:
- испытания при участии пользователя;
- анализ на основе проверки выполнения требований к пригодности использования и доступности и соответствующих руководств.
Примечание - Выполнение требований некоторых стандартов и соответствующих руководств может проверяться автоматически, что может быть полезно для выявления основных проблем. Например, некоторые аспекты доступности программного обеспечения могут быть проверены с использованием автоматизированных методов тестирования.
Ориентированные на пользователя испытания могут быть проведены на любом этапе проектирования.
На начальном этапе проектирования пользователям могут быть представлены модели, сценарии или наброски концепции проекта, которые пользователи должны оценить относительно реальных условий использования. Например, концепция контрольно-кассового пункта может быть рассмотрена с использованием трехмерной модели, а простые рисунки экранов могут быть использованы для анализа графического оформления новой навигационной программы для мобильного телефона.
Такие ранние испытания помогают получить ценные данные о приемлемости предлагаемых проектных решений. Аспекты проекта зачастую могут быть проанализированы быстро и экономично, например, с использованием бумажных версий предлагаемых диалогов. На этапе моделируемых или реальных задач в подходящих условиях всегда необходимы макеты взаимодействия.
При испытаниях образцов пользователи должны выполнять задачи с использованием образца, а не просто просматривать демонстрацию проекта. Собранная информация должна быть использована для совершенствования проекта.
На более поздних этапах проектирования испытания при участии пользователя выполняют для оценки достижения целей пригодности использования в предполагаемых условиях использования, включая критерии производительности и удовлетворенности пользователя.
Одной из форм испытаний при участии пользователя является валидация проекта в реальных условиях, т.е. проверка концепции или испытания исследуемого образца в реальных условиях. В области программного обеспечения продуктов такое испытание обычно называют бета-тестированием, когда раннюю версию программы делают доступной для использования пользователем, осведомленным, что разработка программы еще не завершена. Для испытаний в реальных условиях могут быть изготовлены в небольшом количестве опытные образцы. Изготовленные продукты, системы, выполненные услуги также могут быть исследованы в условиях эксплуатации, что позволяет получить информацию для будущих разработок и модернизаций проекта.
Данные эксплуатации могут быть получены, например, из отчетов службы технического обслуживания и ремонта, отчетов об эксплуатации, данных анализа инцидентов, журналов регистрации, отчетов об отказах, из отзывов пользователей, данных о производительности системы, опросов об удовлетворенности потребителей, отчетов о воздействии на здоровье, журналов наблюдений и запросов о внесении изменений пользователей.
6.5.5 Проверка выполнения требований к пригодности использования
Анализ проекта на основе проверки выполнения требований к пригодности использования может быть эффективным по затратам и дополнять испытания при участии пользователей. Такая проверка может быть использована для устранения основных проблем до проведения испытаний при участии пользователей, тем самым повышая эффективность испытаний.
Проверку выполнения требований к пригодности использования и доступности должны проводить эксперты по пригодности использования, которые выносят суждения на основании предыдущего опыта решения проблем пользователей и знаний в области эргономики соответствующих стандартов и руководств. Для устранения субъективности оценки нескольких экспертов можно усреднить. Во время проверки эксперт должен поставить себя на место пользователя, взаимодействующего с системой, продуктом или услугой. Для проверки выполнения требований к пригодности использования и доступности могут быть использованы контрольные перечни, перечни требований пользователей, общее руководство по пригодности использования, передовой опыт в области пригодности использования, соответствующие руководства или стандарты. Однако эффективность проверки зависит от навыков, опыта и знаний экспертов.
Проверка выполнения требований к пригодности использования и доступности требует меньше усилий и времени, чем испытания при участии пользователей. Такая проверка может учесть более широкий диапазон возможных пользователей и задач (например, при проверке выполнения требований пользователей в условиях, не проверявшихся на испытаниях при участии пользователей). В процессе проверки выполнения требований не всегда выявляют те же проблемы, что и в процессе испытаний при участии пользователей. В процессе проверки выполнения требований могут быть выявлены очевидные проблемы, но она не вполне подходит для сложных или новаторских проектов. Чем больше разница между знаниями и опытом экспертов и реальных пользователей, тем менее достоверным являются результаты проверки. В случаях, когда это возможно, проверка выполнения требований может быть выполнена совместно с экспертами в предметной области.
Руководства и стандарты важны для проектирования (см. 6.4.2), а соответствие установленным в них требованиям может быть оценено с помощью проверки. Несмотря на то, что такая проверка может потребовать много времени и ресурсов, проверка выполнения требований может быть необходима, например, для проверки доступности интернета.
Человеко-ориентированный процесс проектирования должен включать мониторинг продукта, системы или услуги в условиях эксплуатации. Он предполагает сбор вводимой пользователем информации за определенный период времени.
Часто мониторинг в процессе эксплуатации является формальной частью проверки системы и выполняется за определенный период времени, например от шести месяцев до одного года после установки/монтажа системы и ввода ее в эксплуатацию. Мониторинг в процессе эксплуатации часто направлен на проверку производительности системы и сбора данных о правильности определения и выполнения требований и пожеланий пользователей.
Краткосрочный анализ и мониторинг в процессе эксплуатации имеют существенные различия. Некоторые показатели работы интерактивной системы, продукта или услуги можно выявить только при их использовании в течение продолжительного периода времени. Возможно влияние внешних факторов, например, непредвиденных изменений в законодательстве. Такие проблемы необязательно решать незамедлительно, полученную информацию можно использовать для модернизации или разработки новых видов продукции, системы или услуги.
Данные о производительности и отчеты о влиянии на здоровье за продолжительный период времени, представляют собой очень ценную информацию. Необходимо установить достаточно чувствительные критерии и необходимые измерения для выявления отказов или проблем системы как можно раньше.
Примечание - Выявление опасных режимов работы более предпочтительно, чем регистрация инцидентов, а выявление режимов, вызывающих умственную или физическую перегрузку персонала более предпочтительно, чем регистрация заболеваний.
Современному обществу необходимы проекты, учитывающие устойчивое развитие, обеспечивающие баланс между экономическими, социальными и экологическими проблемами.
Примечание - ИСО приняла на себя обязательства по разработке "стандартов для устойчивого мира", определив устойчивое развитие как "удовлетворение потребностей нынешнего поколения, без ущерба для возможности будущих поколений удовлетворять свои собственные потребности".
Человеко-ориентированное проектирование напрямую обеспечивает две основные составляющие устойчивого развития:
a) экономическую - соответствие проекта потребностям и возможностям пользователей и улучшение пригодности использования, качества и эффективности системы, продукции или услуги и, таким образом, обеспечение предоставления эффективных по затратам решений и снижения вероятности того, что системы, продукция или услуги будут неэкономичны или отвергнуты пользователями;
b) социальную - улучшение системы, продукции и услуги в отношении обеспечения здоровья, благополучия и удобства работы пользователей, включая пользователей с ограниченными возможностями.
Человеко-ориентированное проектирование также обеспечивает выполнение экологических требований на протяжении всего жизненного цикла проекта. Оно указывает на необходимость учитывать последствия использования системы для пользователей и для окружающей среды. Такой подход обеспечивает создание пригодных в использовании продуктов.
Соответствие требованиям настоящего стандарта может быть достигнуто с помощью:
a) выполнения всех требований;
b) определения применимых рекомендаций;
c) обоснования причин неприменимости конкретных рекомендаций;
d) заявления о том, какие из применимых рекомендаций были выполнены.
Если делают заявление, что для продукта или системы выполнены требования и учтены применимые рекомендации, то должна быть установлена процедура определения того, каким образом они были выполнены. Причастные стороны должны договариваться о степени детализации этой процедуры.
В приложении B представлена форма записей о применимости рекомендаций и о выполнении требований и применимых рекомендаций.
Пользователи настоящего стандарта могут также разработать другую процедуру и форму.
Примечание - ИСО/ТО 18529 предоставляет модель, демонстрирующую возможности человеко-ориентированного проектирования в проекте или организации.
(справочное)
В настоящем приложении приведена структура комплекса стандартов серии ИСО 9241. Последняя версия этой структуры, предметные области стандартов и их текущее состояние представлены на сайте: /template/go.php?url=https://www.iso.org/iso/search.htm?qt=iso+9241&sort=rel&type=simple&published=on
Таблица A.1
Структура стандартов серии ИСО 9241: Эргономика
взаимодействия человек-система
(справочное)
И ПРИМЕНЕНИЯ РЕКОМЕНДАЦИЙ НАСТОЯЩЕГО СТАНДАРТА
B.1 Общие положения
В данном приложении приведен пример контрольного перечня требований (см. таблицу B.1), который может быть использован для проверки выполнения требований и применения рекомендаций настоящего стандарта.
Контрольный перечень содержит все требования и рекомендации настоящего стандарта, но не может быть использован в отрыве от его полного содержания.
Необходимо отметить, что перечень не является исчерпывающим и его нельзя использовать вместо стандарта.
Использование контрольного перечня является основой для:
- определения применимых рекомендаций;
- проверки выполнения требований и применимых рекомендаций;
- обеспечения подтверждения заявления о соответствии.
Несколько требований и рекомендаций настоящего стандарта имеют более одного промежуточного требования. Выполнение требования или рекомендации зависит от выполнения каждого промежуточного требования. Поэтому каждый пункт настоящего стандарта представлен в отдельной строке, а строка, содержащая требование, выделена серой заливкой. Заполненный контрольный перечень может быть использован для обеспечения заявления о соответствии проекта настоящему стандарту. В нем показаны требования и рекомендации, по которым достигнуто соответствие.
Таблица B.1
и применимости рекомендаций настоящего стандарта
B.2 Использование контрольного перечня
Номера разделов и подразделов приведены в первом столбце таблицы, соответствующие наименования или требования/рекомендации - во втором столбце. В третьем столбце указывают отметки о выполнении (или невыполнении) требования или рекомендации. Для всех требований в третьей колонке уже проставлена отметка Д ("да"). В отношении содержания других разделов или подразделов необходимо указать их выполнение и соответствие условиям проекта, и для них должны быть проставлены отметки Д или Н ("нет").
Для каждой рекомендации настоящего стандарта приведена информация об условиях, в которых они могут быть применены. Если рекомендация не применима, это необходимо указать в столбце 3 таблицы "Применение", а в столбце 4 "Причина невозможности применения" должно быть дано краткое обоснование этого.
Проверка выполнения требований и рекомендаций включает анализ всех пунктов, отмеченных как применимые в столбце 3 и принятие решения относительно соответствия проекта этим требованиям и рекомендациям. Конкретные методы проверки могут отличаться в разных случаях.
В столбце "соответствие" контрольного перечня следует поставить отметки ("Д" или "Н") о выполнении (или невыполнении) каждого применимого требования или рекомендации. Для всех разделов или подразделов, требование или рекомендация которых не выполнены, в колонке 7 "Комментарий" следует указать причины несоответствия. В этой колонке может быть приведена информация об использованном методе.
B.3 Копирование контрольного перечня
Пользователи настоящего стандарта могут свободно воспроизводить таблицу, содержащуюся в данном приложении для проверки соответствия требованиям настоящего стандарта.
Редактируемые электронные версии контрольного перечня приведены (на английском языке) в подкаталоге общедоступного каталога "Таблицы ИСО 9241-210" по ссылке: /template/go.php?url=https://isotc.iso.org/livelink/livelink?func=ll&objld=8265864&objAction=browse&sort=name.
(справочное)
УКАЗАННЫХ В БИБЛИОГРАФИИ НАСТОЯЩЕГО СТАНДАРТА,
НАЦИОНАЛЬНЫМ СТАНДАРТАМ РОССИЙСКОЙ ФЕДЕРАЦИИ
И МЕЖГОСУДАРСТВЕННЫМ СТАНДАРТАМ
Таблица ДА.1
(справочное)
В настоящем стандарте установлены принципы человеко-ориентированного проектирования и необходимые для этого действия. Эти принципы и действия могут быть преобразованы в структурированные процессы. Преимущества человеко-ориентированного проектирования заключаются в обеспечении более высокой пригодности использования, доступности и удовлетворенности пользователя, а также снижении риска поставки продукции, не отвечающей требованиям заинтересованных сторон. В настоящее время часто используют термин человеко-ориентированное качество для обозначения всей совокупности упомянутых преимуществ. Целью человеко-ориентированного проектирования является создание приемлемого уровня человеко-ориентированного качества.
Процессы человеко-ориентированного проектирования, как и другие процессы в организации, устанавливают, анализируют, улучшают и моделируют (см. ИСО 9241-220).
Моделирование процессов и их использование для анализа получили широкое распространение для обеспечения, своевременной и результативной разработки и поставки системы. Процессы определяют на уровне необходимых действий для разработки и функционирования системы или организации.
Модели процессов обеспечивают:
a) анализ возможностей организации по разработке, поставке и/или поддержанию системы, которая соответствует требуемому уровню функционирования и качества;
b) описание факторов, которые ограничивают эти возможности;
c) способы снижения влияния таких факторов и снижения соответствующего риска.
Процессы человеко-ориентированного проектирования интерактивных систем направлены на выполнение требований эргономики в области взаимодействия человек-система, пригодности использования и восприятия пользователем системы.
Вернуться в "Каталог нормативных документов"
Источник информации: https://internet-law.ru/documents/prod/gost-r_gosudarstvennyj-standart/32/gost_33771.html
На правах рекламы:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||