Программное обеспечение
![]() | Тон или стиль этой статьи могут не отражать энциклопедический тон , используемый в Википедии . Причина такова: статья читается как руководство. ( Апрель 2024 г. ) |
Программное обеспечение — это термин, введенный в 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% всех ошибок при использовании происходят из-за структурных недостатков, а не плохого дизайна. Следовательно, этап оценки следует рассматривать как сквозную задачу на протяжении всего процесса разработки. Поэтому интеграция пользователей в разработку продукта имеет первостепенное значение.
Ссылки
[ редактировать ]- ^ Jump up to: а б Альбах, Хорст (2007). «Герц, Дитмар; Вайнбергер, Вероника (ред.): Лексикон экономических трудов. 650 новаторских сочинений от древности до 20 века» . Журнал экономики бизнеса . 77 (6): 697–698. дои : 10.1007/s11573-007-0049-9 . ISSN 0044-2372 .
- ^ «Системы программного обеспечения для международных рынков». Использование программного обеспечения для технических систем . Берлин, Гейдельберг: Springer Berlin Heidelberg. 2004. стр. 142–164. дои : 10.1007/3-540-35034-9_4 . ISBN 978-3-540-20647-7 . Проверено 23 сентября 2023 г.
- ^ Мейкснер, Геррит (2011). «Техники мобильного взаимодействия на фабрике будущего» . Редакция АТП – практика технологии автоматизации . 53 (12): 48. дои : 10.17560/atp.v53i12.359 . ISSN 2364-3137 .
- ^ Нильсен, Якоб (1987). «Рецензия на книгу: Проектирование пользовательского интерфейса: стратегии эффективного взаимодействия человека и компьютера, Бен Шнейдерман (Аддисон-Уэсли, 1987)» . Бюллетень ACM SIGCHI . 18 (3): 85–86. дои : 10.1145/25281.1044310 . ISSN 0736-6906 .
- ^ Хофмайстер, Вернфрид (2007). «Многослойное редактирование как новая возможность лингвистики». История издания и языка . ДЕ ГРЮТЕР. стр. 73–88. дои : 10.1515/9783110938869.73 . ISBN 978-3-484-29526-1 . Проверено 23 сентября 2023 г.
- ^ Зюльке, Детлеф; Тилс, Нэнси (2008). «Useware Engineering: методология разработки удобных интерфейсов» . Библиотека высоких технологий . 26 (1): 126–140. дои : 10.1108/07378830810857852 . ISSN 0737-8831 .
- ^ Юнг, Кристиан; Мюзебек, Франциска; Барисин, Олово; Шладиц, Катя; Реденбах, Клаудия; Кише, Мартин; Пан, Матиас (2022). «На пути к автоматической сегментации трещин на трехмерных изображениях бетона» . Электронный журнал неразрушающего контроля . 27 (3). дои : 10.58286/26620 . ISSN 1435-4934 .
- ^ Гёрлих, Даниэль; Тилс, Нэнси; Мейкснер, Геррит (2008). «Модели персонализированного использования в средах окружающего интеллекта» . Тома трудов МФБ . 41 (2): 13785–13790. дои : 10.3182/20080706-5-kr-1001.02334 . ISSN 1474-6670 .
- ^ Предвзятость, Рэндольф Г. (2005). «Взгляд с другой стороны стола» . Экономически оправданное удобство использования (2-е изд.). Эльзевир. стр. 613–621. дои : 10.1016/b978-012095811-5/50022-5 . ISBN 978-0-12-095811-5 . Проверено 23 сентября 2023 г.
Дальнейшее чтение
[ редактировать ]- Оберкуэль, Х. (2002): Проектирование и эволюция программного обеспечения: соединение социального мышления и создания программного обеспечения . В: Ю. Диттрих, К. Флойд, Р. Клишевски (Hrsg): Социальное мышление – практика программного обеспечения, S. 391–408, Кембридж, Лондон: MIT-Press.
- Дополнительную информацию см. на форуме Useware от 17 марта 2009 г.