ПО - Useware

ПО - общий термин, введенный в 1998 году, который обозначает все жесткие и программные компоненты технической системы, которые служат для ее интерактивного использования. Основная идея термина Useware - ориентированность технического проектирования в соответствии с человеческими способностями и потребностями. Единственный многообещающий метод (Zuehlke, 2007) для разработки будущих технических продуктов и систем - это понимание человеческих способностей и ограничений и фокусирование технологии на этих способностях и ограничениях.

Сегодня Useware требует собственной разработки, которая отчасти выше, чем в классических областях разработки (Zuehlke, 2004). Таким образом, удобство использования все чаще рассматривается как фактор, увеличивающий добавленную стоимость. Часто Useware машин с аналогичными или равными техническими функциями является единственной характеристикой, которая отличает их (Zuehlke, 2002).

Рисунок 1: Процесс разработки ПО

Useware-Engineering

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

Таким образом, цель систематической разработки программного обеспечения Useware гарантирует высокое удобство использования, основанное на реальных задачах пользователей. Однако это требует подхода, который включает активное и многократное участие различных групп людей.

Поэтому профессиональные ассоциации GfA (Gesellschaft für Arbeitswissenschaft), GI (Gesellschaft für Informatik ), VDE-ITG (The Информационные технологии Society in VDE) и VDI / VDE GMA (Общество измерения и Автоматический контроль в VDI / VDE) в 1998 году договорились об определении Useware как нового термина. Термин Useware был намеренно выбран по лингвистической аналогии с аппаратным и программным обеспечением.

Следовательно, Useware Engineering развивалась аналогично разработке инженерных процессов (см. Рисунок 2). Это усиливает основной спрос на структурированную разработку ориентированных на пользователя пользовательские интерфейсы выражено например к Бен Шнейдерман (Шнейдерман, 1998). После многих лет функционально-ориентированного развития в центре внимания оказались человеческие способности и потребности. Единственный многообещающий метод разработки будущих технических продуктов и систем - это понять возможности и ограничения пользователей и направить технологию в этом направлении (Zuehlke, 2007).

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

Процесс разработки Useware (см. Рисунок 1) различает следующие этапы: анализ, проектирование структуры, проектирование, реализация и оценка. Каждый из этих этапов не следует рассматривать отдельно, а скорее частично. Непрерывность процесса, а также использование подходящих инструментов, например на основе расширяемый язык разметки (XML) позволяют избежать потерь информации и разрывов СМИ.

Анализ

Люди учатся, думают и работают совершенно по-разному. Поэтому первым шагом в разработке пользовательского интерфейса является анализ пользователей, их задач и их рабочей среды, чтобы определить требования и потребности этих пользователей. Этот шаг формирует основу пользовательского интерфейса, ориентированного на пользователя и задачи. И люди, и машины считаются партнерами по взаимодействию. Для анализа пользователей и их поведения используются разные методы, например: структурированные интервью, наблюдения, сортировка карточек и т. д. Они должны давать желательно полное представление о рабочей задаче, различных группах пользователей и их рабочей среде. Для использования этих методов несколько профессиональных экспертов, например инженеры, компьютерные ученые и психологи должны быть задействованы. В частности, на этапе анализа создаются модели задач для создания документации и пользовательского интерфейса, которые неявно содержат функциональную модель процесса и / или машины (Meixner and Goerlich, 2008).

Конструкция конструкции

Результаты этапа анализа корректируются на этапе структурирования. Абстрактная модель использования (Zuehlke and Thiels, 2008) разрабатывается на основе этой информации, которая независимая платформа. Результатом этапа структурирования является Базовая структура будущего пользовательского интерфейса. Модель использования - это формальная модель контекстов использования, задач и информации, требующая функциональности машины. Модель использования моделируется с помощью Useware Язык разметки, useML (Reuther, 2003) в рамках модели, основанной среда разработки.

Дизайн

Параллельно с этапом структурирования необходимо выбрать аппаратную платформу для Useware. Этот выбор основан на экологических требованиях использования машины (загрязнение, шум, вибрация и т. Д.), С одной стороны, и требованиях пользователя (размер дисплея, оптимальное устройство взаимодействия и т. Д.), С другой. Кроме того, необходимо учитывать экономические факторы. Если модель сильно связана с сетью или состоит из огромного количества элементов, необходимо обеспечить достаточный размер отображения для визуализации структуры информации. Эти факторы частично зависят от групп пользователей и условий использования (Goerlich et al., 2008).

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

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

Оценка

Непрерывная оценка во время процесса разработки позволяет раннее обнаруживать проблемы продукта и, таким образом, снижает затраты на разработку (Bias and Mayhew, 1994). Уместно включить структурные аспекты, например: навигационные концепции и т. д. в оценке, и не только в аспектах дизайна. Некоторые тесты показали, что 60% всех ошибок использования являются результатом не плохого дизайна, а структурных недостатков. Фаза оценки должна рассматриваться как сквозная задача всего процесса разработки. Таким образом, очень важно вовлечь пользователей в разработку продукта.

Дополнительная литература

Оберкель, Х. (2002): Разработка и развитие программного обеспечения: объединение социального мышления и создания программного обеспечения. В: Y. Dittrich, C. Floyd, R. Klischewski (Hrsg.): Social Thinking – Software Practice, S. 391-408, Cambridge, London: MIT-Press
Для получения дополнительной информации см. Useware-Forum 17 марта 2009 г.