Useware

Useware — термин, введенный в 1998 году для обозначения всех аппаратных и программных компонентов технической системы, предназначенной для интерактивного использования. Он фокусируется на технологическом проектировании в отношении человеческих возможностей и потребностей. Перспективным методом [1] проектирования технических продуктов является понимание человеческих возможностей и ограничений и адаптация технологии к ним.

Сегодня useware требует собственных потребностей в разработке, которые иногда больше, чем в классических областях разработки. [2] Поэтому удобство использования все чаще признается фактором, добавляющим ценность. Часто useware машин с похожими или равными техническими функциями является единственной характеристикой, которая отличает их. [3]

Процесс разработки пользовательского ПО (рисунок 1)

Инженерное обеспечение Useware

Подобно программной инженерии , инжиниринг 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]

Развитие различных инженерных дисциплин (рисунок 2)

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

Анализ

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

Проектирование структуры

Результаты фазы анализа информируют фазу структурирования, где на основе этой информации разрабатывается абстрактная модель использования [6] , которая не зависит от платформы . Эта модель использования служит основой для будущего пользовательского интерфейса, предоставляя формальное представление контекстов использования, задач и информации, необходимых для функциональности машины. Смоделированная с использованием Useware Markup Language (useML) в среде разработки на основе моделей , модель использования определяет базовую структуру интерфейса. [7]

Дизайн

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

Реализация/прототипирование

Во время создания прототипа разработчикам необходимо выбрать инструмент разработки . Если выбранная среда допускает импорт, можно ввести разработанную модель использования, что облегчит создание пользовательского интерфейса. Обычно это включает в себя доработку динамических компонентов и дизайн диалогов. Часто существует разрыв между фазами структурирования и точного проектирования. Текущий набор инструментов разработки предлагает широкий спектр обозначений. Разработчики должны представлять используемое программное обеспечение с помощью прототипов, таких как бумажные прототипы или прототипы Microsoft PowerPoint .

Оценка

Непрерывная оценка в течение всего процесса разработки позволяет на ранней стадии выявлять проблемы продукта, тем самым снижая затраты на разработку. [9] Крайне важно оценивать не только аспекты дизайна, но и структурные элементы, такие как навигационные концепции, во время оценки. Исследования показывают, что 60% всех ошибок использования возникают из-за структурных недостатков, а не из-за плохого дизайна. Следовательно, этап оценки должен рассматриваться как сквозная задача на протяжении всего процесса разработки. Поэтому интеграция пользователей в разработку продукта имеет первостепенное значение.

Ссылки

  1. ^ аб Альбах, Хорст (2007). «Герц, Дитмар; Вайнбергер, Вероника (Hrsg.): Lexikon ökonomischer Werke. 650 wegweisende Schriften von der Antike bis ins 20. Jahrhundert». Журнал экономики бизнеса . 77 (6): 697–698 . doi : 10.1007/s11573-007-0049-9. ISSN  0044-2372.
  2. ^ "Система использования программного обеспечения для международной торговли" . Использование программного обеспечения для технических систем. Берлин, Гейдельберг: Springer Berlin Heidelberg. 2004. С.  142–164 . doi :10.1007/3-540-35034-9_4. ISBN 978-3-540-20647-7. Получено 2023-09-23 .
  3. ^ Мейкснер, Геррит (2011). «Техника мобильного взаимодействия в Fabrik der Zukunft». Издание Atp — Automatisierungstechnische Praxis . 53 (12): 48. дои :10.17560/atp.v53i12.359. ISSN  2364-3137.
  4. ^ Нильсен, Якоб (1987). «Обзор книги: Проектирование пользовательского интерфейса: стратегии эффективного взаимодействия человека и компьютера Бена Шнейдермана (Addison-Wesley, 1987)». ACM SIGCHI Bulletin . 18 (3): 85– 86. doi :10.1145/25281.1044310. ISSN  0736-6906.
  5. ^ Хофмайстер, Вернфрид (2007). «Mehrschichtiges Edieren als neue Chance für die Sprachwissenschaft». Издание и Sprachgeschichte. ДЕ ГРЮТЕР. стр.  73–88 . doi : 10.1515/9783110938869.73. ISBN 978-3-484-29526-1. Получено 2023-09-23 .
  6. ^ Zuehlke, Detlef; Thiels, Nancy (2008). «Инженерия Useware: методология разработки удобных для пользователя интерфейсов». Library Hi Tech . 26 (1): 126– 140. doi :10.1108/07378830810857852. ISSN  0737-8831.
  7. ^ Юнг, Кристиан; Мюзебек, Франциска; Баризин, Тин; Шладиц, Катя; Реденбах, Клаудия; Кише, Мартин; Пан, Маттиас (2022). «На пути к автоматической сегментации трещин в 3D-изображениях бетона». Электронный журнал неразрушающего контроля . 27 (3). doi : 10.58286/26620 . ISSN  1435-4934.
  8. ^ Гёрлих, Даниэль; Тилс, Нэнси; Мейкснер, Геррит (2008). «Модели персонализированного использования в средах окружающего интеллекта». Тома трудов МФБ . 41 (2): 13785–13790 . doi :10.3182/20080706-5-kr-1001.02334. ISSN  1474-6670.
  9. ^ Bias, Randolph G. (2005). «Взгляд с другой стороны стола». Cost-Justifying Usability (2-е изд.). Elsevier. стр.  613– 621. doi :10.1016/b978-012095811-5/50022-5. ISBN 978-0-12-095811-5. Получено 2023-09-23 .

Дальнейшее чтение

  • Oberquelle, H. (2002): Useware Design and Evolution: Bridging Social Thinking and Software Construction . В: Y. Dittrich, C. Floyd, R. Klischewski (Hrsg.): Social Thinking–Software Practice, S. 391–408, Cambridge, London: MIT-Press
  • Для получения дополнительной информации посетите Useware-Forum 17 марта 2009 г.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Useware&oldid=1239281056"