Программное обеспечение — это общий термин, введенный в 1998 году для обозначения всех аппаратных и программных компонентов технической системы для интерактивного использования. Основное внимание уделяется технологическому проектированию с учетом человеческих способностей и потребностей. Многообещающий метод [1] проектирования технических продуктов состоит в том, чтобы понять человеческие способности и ограничения и нацелить на них технологии.
Сегодня Useware требует собственных потребностей в разработке, которые частично превышают потребности в классических областях разработки. [2] Таким образом, удобство использования все чаще признается фактором, добавляющим ценность. Часто программное обеспечение машин со схожими или равными техническими функциями является единственной характеристикой, которая отличает их от других. [3]
Подобно разработке программного обеспечения , разработка Useware подразумевает стандартизированное производство Useware инженерами и связанные с ним процессы (см. рис. 1). Целью разработки программного обеспечения является разработка интерфейсов, которые просты для понимания и эффективны в использовании. Эти интерфейсы адаптированы к задачам человеческой работы. Кроме того, интерфейсы отражают функциональные возможности машины, не переоценивая их.
Таким образом, цель систематического проектирования использования программного обеспечения гарантирует высокое удобство использования, основанное на реальных задачах пользователей. Однако для этого требуется подход, предполагающий активное и последовательное участие различных групп людей.
Поэтому профессиональные ассоциации GfA (Gesellschaft für Arbeitswissenschaft), GI ( Gesellschaft für Informatik ), VDE-ITG ( Общество информационных технологий в VDE) и VDI/VDE GMA (Общество измерений и автоматического управления в VDI/VDE) согласились в 1998 году об определении Useware как нового термина. Термин Useware был выбран намеренно по лингвистической аналогии с аппаратным и программным обеспечением.
Следовательно, Useware-инжиниринг развивался аналогично разработке инженерных процессов (см. рис. 2). Это усиливает принципиальную потребность в структурированной разработке пользовательских интерфейсов , ориентированных на пользователя , выраженную, например, Беном Шнейдерманом . [4] После многих лет функционально-ориентированного развития человеческие способности и потребности становятся в центре внимания. Единственный многообещающий метод разработки будущих технологических продуктов и систем — это понять способности и ограничения пользователей и направить технологии в этом направлении. [1]
Процесс разработки программного обеспечения включает следующие этапы: анализ, проектирование структуры, проектирование, реализация и оценка. Каждый из этих шагов не следует рассматривать отдельно, а скорее дублировать. Непрерывность процесса, а также использование подходящих инструментов, например, на основе расширяемого языка разметки (XML), позволяют избежать потерь информации и перерывов в работе носителя.
Люди учатся, думают и работают совершенно по-разному. Поэтому первым шагом в разработке пользовательского интерфейса является анализ пользователей, их задач и рабочей среды с целью выявления требований и потребностей этих пользователей. Этот шаг формирует основу для пользовательского интерфейса, ориентированного на пользователя и задачи. И люди, и машины считаются партнерами по взаимодействию. Для анализа пользователей и их поведения используются различные методы, такие как структурированные интервью, наблюдения, сортировка карточек и т. д. Они должны давать желательно полное представление о рабочей задаче, различных группах пользователей и их рабочей среде. Для использования этих методов необходимо привлечь несколько профессиональных экспертов, например, инженеров , специалистов по информатике и психологов . Особенно на этапе анализа создаются модели задач для создания документации и пользовательского интерфейса, которые неявно содержат функциональную модель процесса и/или машины. [5]
Результаты этапа анализа корректируются на этапе структурирования. На основе этой информации разрабатывается абстрактная модель использования [6] , которая не зависит от платформы . Результатом этапа структурирования является базовая структура будущего пользовательского интерфейса. Модель использования — это формальная модель контекстов использования, задач и информации, требующих функциональности машины. Модель использования моделируется с помощью языка разметки Useware , useML [7] в среде разработки на основе модели .
Параллельно с этапом структурирования необходимо выбрать аппаратную платформу для используемого программного обеспечения. Этот выбор основан на требованиях окружающей среды при использовании машины (загрязнение, шум, вибрация и т. д.), с одной стороны, и требованиях пользователя (размер дисплея, оптимальное устройство взаимодействия и т. д.) с другой. Кроме того, необходимо учитывать экономические факторы. Если модель интенсивно сетевая или состоит из огромного количества элементов, необходимо обеспечить достаточный размер дисплея для визуализации информационной структуры. Эти факторы частично зависят от групп пользователей и условий использования. [8]
Во время прототипирования разработчики должны выбрать инструмент разработки . Если выбранная среда разработки предоставляет возможности импорта, разработанную модель использования можно импортировать и обработать создание пользовательского интерфейса. В большинстве случаев обработка влияет на реализацию динамических компонентов, а также на качественное оформление диалогов. Часто между этапом структурирования и этапом (точного) проектирования происходит медиа-пауза. Сегодняшняя область инструментов разработки имеет большое разнообразие обозначений. Разработчикам необходимо представлять используемое программное обеспечение в виде прототипов, например, бумажных прототипов или прототипов Microsoft PowerPoint .
Непрерывная оценка в процессе разработки позволяет на ранней стадии обнаруживать проблемы с продуктом, тем самым снижая затраты на разработку. [9] В оценку важно включать не только аспекты дизайна, но и структурные аспекты, такие как концепции навигации. Некоторые тесты показали, что 60% всех ошибок использования являются результатом не плохого дизайна, а, скорее, структурных недостатков. Фазу оценки следует рассматривать как сквозную задачу всего процесса разработки. Поэтому очень важно интегрировать пользователей в разработку продукта.