This article's tone or style may not reflect the encyclopedic tone used on Wikipedia. The reason given is: the article reads like a manual. (April 2024) |
Useware — термин, введенный в 1998 году для обозначения всех аппаратных и программных компонентов технической системы, предназначенной для интерактивного использования. Он фокусируется на технологическом проектировании в отношении человеческих возможностей и потребностей. Перспективным методом [1] проектирования технических продуктов является понимание человеческих возможностей и ограничений и адаптация технологии к ним.
Сегодня useware требует собственных потребностей в разработке, которые иногда больше, чем в классических областях разработки. [2] Поэтому удобство использования все чаще признается фактором, добавляющим ценность. Часто useware машин с похожими или равными техническими функциями является единственной характеристикой, которая отличает их. [3]
Подобно программной инженерии , инжиниринг useware подразумевает стандартизированное производство useware инженерами и связанные с ними процессы (см. рис. 1). Целью инжиниринга useware является разработка интерфейсов, которые легко понять и эффективно использовать, адаптированных к задачам работы человека. Кроме того, интерфейсы представляют функциональность машины, не переоценивая ее.
Таким образом, цель систематической разработки программного обеспечения гарантирует высокую юзабилити на основе реальных задач пользователей. Однако, это требует подхода, который включает активное и итеративное участие различных групп людей.
Профессиональные ассоциации GfA (Gesellschaft für Arbeitswissenschaft), GI ( Gesellschaft für Informatik ) , VDE-ITG (The Information Technology Society in VDE) и VDI/VDE GMA (The Society for Measurement and Automatic Control in VDI/VDE) договорились в 1998 году об определении useware как нового термина. Термин «useware» был намеренно выбран по лингвистической аналогии с аппаратным и программным обеспечением.
Следовательно, разработка программного обеспечения развивалась аналогично разработке инженерных процессов (см. рис. 2). Это усиливает принципиальную потребность в структурированной разработке пользовательских интерфейсов , ориентированных на пользователя, как это отстаивает Бен Шнейдерман . [4] После многих лет разработки, ориентированной на функции, человеческие способности и потребности были поставлены в центр внимания. Единственный многообещающий метод разработки будущих технологических продуктов и систем — это понимание способностей и ограничений пользователей и направление технологии в этом направлении. [1]
Процесс разработки useware включает следующие этапы: анализ, структурное проектирование, проектирование, реализация и оценка. Эти этапы не следует рассматривать изолированно, а как перекрывающиеся этапы. Поддержание непрерывности на протяжении всего процесса и использование соответствующих инструментов, например, основанных на расширяемом языке разметки (XML), помогает предотвратить потерю информации и разрывы в медиа.
Понимание того, что люди имеют различные стили обучения, мышления и работы, имеет решающее значение при создании пользовательского интерфейса. Первым шагом является анализ пользователей, их задач и рабочих настроек, чтобы выяснить, что им действительно нужно. Этот анализ является ключом к проектированию интерфейса, который ориентирован как на пользователя, так и на задачу, рассматривая людей и машины как партнеров во взаимодействии. Такие методы, как структурированные интервью, наблюдения и сортировка карточек, помогают получить полную картину пользователей и их поведения, что необходимо для полного понимания их задач, групп пользователей и рабочей среды. Привлечение нескольких экспертов, таких как инженеры , компьютерные специалисты и психологи, имеет решающее значение, особенно на этапе анализа, для создания моделей задач для документации и проектирования интерфейса, которые по своей сути включают функциональную модель процесса и/или машины. [5]
Результаты фазы анализа информируют фазу структурирования, где на основе этой информации разрабатывается абстрактная модель использования [6] , которая не зависит от платформы . Эта модель использования служит основой для будущего пользовательского интерфейса, предоставляя формальное представление контекстов использования, задач и информации, необходимых для функциональности машины. Смоделированная с использованием Useware Markup Language (useML) в среде разработки на основе моделей , модель использования определяет базовую структуру интерфейса. [7]
На этапе структурирования параллельно должна быть выбрана аппаратная платформа для используемого программного обеспечения. Этот выбор учитывает как экологические требования использования машины, такие как загрязнение, шум и вибрация, так и требования пользователей, включая размер дисплея и оптимальные устройства взаимодействия. Кроме того, экономические факторы играют роль. Для широко сетевых моделей или тех, которые включают в себя множество элементов, адекватный размер дисплея имеет важное значение для визуализации информационных структур. Эти соображения зависят от групп пользователей и контекстов использования. [8]
Во время создания прототипа разработчикам необходимо выбрать инструмент разработки . Если выбранная среда допускает импорт, можно ввести разработанную модель использования, что облегчит создание пользовательского интерфейса. Обычно это включает в себя доработку динамических компонентов и дизайн диалогов. Часто существует разрыв между фазами структурирования и точного проектирования. Текущий набор инструментов разработки предлагает широкий спектр обозначений. Разработчики должны представлять используемое программное обеспечение с помощью прототипов, таких как бумажные прототипы или прототипы Microsoft PowerPoint .
Непрерывная оценка в течение всего процесса разработки позволяет на ранней стадии выявлять проблемы продукта, тем самым снижая затраты на разработку. [9] Крайне важно оценивать не только аспекты дизайна, но и структурные элементы, такие как навигационные концепции, во время оценки. Исследования показывают, что 60% всех ошибок использования возникают из-за структурных недостатков, а не из-за плохого дизайна. Следовательно, этап оценки должен рассматриваться как сквозная задача на протяжении всего процесса разработки. Поэтому интеграция пользователей в разработку продукта имеет первостепенное значение.