Лекции по ЧМВ-дополнительные (1022759), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

К ним относятся реально несуществующие устройства, поддерживаемые программно моделями. Примеры таких устройств:

• тренажеры,

• виртуальные измерительные устройства в системах имитационного моделирования.

2.3. Проектирование ПИ

Все известные стандарты проектирования программного обеспечения в качестве исходного положения используют понятие жизненного цикла программного продукта, под которым понимается последовательность процессов, действий и задач, осуществляемых в ходе разработки, эксплуатации и сопровождения программного продукта. Например, на этапе формирования требований к системе должны учитываться:

• область применения системы,

• требования пользователя (заказчика)к функциональным возможностям системы, к уровню ее безопасности и защищенности,

• эргономические требования,

• требования к квалификации пользователя,

• степень документированности,

• организация сопровождения.

Все проектирование ПИ основано на USD-технологии (интересы пользователя превыше всего) и включает в себя следующие основные этапы:

• Постановка задачи.

• Прототипирование.

• Испытание программного продукта.

• Повторное выполнение этапов разработки.

• Оценка потребительских свойств в процессе разработки.

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

• Определить цели и задачи продукта.

• Установить потенциальных пользователей продукта, их задачи, намерения, цели. Необходимо учитывать возраст и пол пользователей, их знания и опыт, возможные физические ограничения, специальные потребности.

• Продумать структуру приложения и метафоры, которые могут быть в нем использованы.

• Представить проект разработки в письменной форме.

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

Испытание программного продукта.USD-технология предполагает активное привлечение пользователя к процессу разработки. За счет этого можно получить дополнительную информацию по качеству применяемых решений с целью их изменения и улучшения. Испытание не есть отладка, последняя осуществляется разработчиком.

Повторное выполнение этапов разработки. Испытания часто обнаруживают недостатки в проекте и почти всегда необходим возврат к одному из выполненных этапов для создания улучшенной версии фрагмента проекта.

Оценка потребительских свойств в процессе разработки. Основным направлением испытаний проекта является оценка его потребительских свойств. Главным является удобство пользователя (Usability). Это свойство должно контролироваться на всех этапах разработки проекта. Чем чаще и корректнее проводится такая оценка, тем лучше будет качество разработки. При испытаниях можно контролировать:

• время реакции пользователя на команды,

• желание пользователя реагировать на предложения системы,

• использование альтернативных решений.

В процессе оценки полезно учитывать следующее:

• После выход в свет официальной версии программного продукта устранить недостатки труднее, чем при разработке.

• Простота ПИ не означает его упрощения. Простат в использовании может достигаться сложными программными решениями.

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

При проектировании ПИ необходимо определить:

• структуру диалога,

• возможный сценарий развития диалога,

• содержание управляющих сообщений и данных, которыми могут обмениваться пользователь и приложение (семантика сообщений),

• визуальные атрибуты отображаемой информации (синтаксис сообщений).

Структура диалога. Возможны 4 варианта структуры диалога:

• Диалог типа "вопрос-ответ". Структура аналогична интервью. Система задает пользователю вопросы и получает информацию из ответа. Форма задания вопроса и ввода ответа может быть разной (списки, поля ввода значений и др.).

• Диалог на основе меню. Система предъявляет пользователю перечень возможных решений в виде иерархически организованных меню, в которых пользователь выбирает нужное. В меню могут быть блоки данных, строки данных и пиктограммы.

• Диалог на основе экранных форм. Позволяет на одном шаге получить от пользователя много данных, указываемых в форме. Там могут присутствовать списки выбора, поля ввода и др.

• Диалог на основе командного языка. Часто используется в операционных системах для прямого ввода команды в командной строке.

Возможный сценарий развития диалога. Развитие диалога во времени можно рассматривать как последовательность переходов системы из одного состояния в другое. Ни одно из них не должно быть "тупиковым", пользователь должен иметь возможность за один или несколько шагов перейти из любого текущего состояния в требуемое. При разработке интерфейса необходимо определить все возможные состояния диалога и пути перехода из одного состояния в другие. Необходимо:

• Выявить и устранить возможные тупиковые ситуации.

• Выбрать рациональные пути перехода из текущего состояния в требуемое.

• Выявить неоднозначные ситуации, в которых действия пользователя не определены, ему нужна подсказка. Сценарий диалога можно упростить, снизив неопределенность действий пользователя.

• Определить темп ведения диалога. Время ответа системы должно соответствовать удобному для пользователя (0,1..0,2 секунды для нажатия клавиши, 0,5..1,0 секунды для ответа на простые команды, 1..2 секунды при ведении связанного диалога, 2..4 секунды для ответа на сложный вопрос, связанный с заполнением формы)..

Визуальные атрибуты отображаемой информации (синтаксис сообщений). К ним относятся:

• Взаимное расположение и размеры отображаемых объектов. Должна предусматриваться возможность просмотра экрана в логической последовательности, выбор объекта, различимость исключительных ситуаций(сообщения об ошибках или предупреждениях),

• Цветовая палитра.

• Средства привлечения внимания пользователей. Например, указание пользователю выполнить какие-либо действия.

3. ГПИ - графический ПИ

3.1. Граф диалога и метафоры ПИ
3.2. Объектный подход к проектированию ГПИ
3.3. Компоненты ГПИ
3.4. Взаимодействие пользователя с приложением
3.5. Правила взаимодействия с объектом
3.6. О вежливых программах

3.1. Граф диалога и метафоры ПИ

Диалог пользователя с машиной может быть охарактеризован структурой диалога. Различают следующие структуры диалога:

1. Диалог типа вопрос - ответ (Q&A). Структура основана на аналогии с интервью. Система спрашивает, пользователь отвечает. На один вопрос дается один ответ, в зависимости от которого система принимает решение о дальнейшем развитии событий. Структура Q&A широко применялась при использовании операционных систем с символьным интерфейсом. Появление средств графического интерфейса структура Q&A устарела.

2. Диалог на основе меню. Меню - наиболее популярный вариант организации запросов пользователю во время диалога, управляемого компьютером. Меню может представляться в нескольких форматах: со списком объектов, в виде блока данных, с набором пикограмм. Как и в структуре Q&A в этом диалоге система получает от пользователя на каждом шаге один ответ для принятия решения.

3. Диалог на основе экранных форм позволяет системе на каждом шаге принимать и обрабатывать набор ответов пользователя. Обычно форма используется там, где от пользователя требуется получить набор стандартных данных.

4. Диалог на основе командного языка используется для взаимодействия с операционной системой. В ходе диалога система предлагает пользователю ввести в командной строке команду на поддерживаемом языке программирования, которую она затем выполняет. Поддержка диалога системой состоит только в приглашении ввести команду. Ответственность за правильность ввода команды лежит на пользователе, он должен знать синтаксис команд.

Проектировщик интерфейса при выборе структуры диалога может руководствоваться таблицей выбора, в которой знаками + показаны возможные структуры для различных задач. Графы "Тип диалога" определены опытом работ при создании ПИ. Колонку "Выбор пользователя" должен заполнить создатель ПИ. Порядок работы с такой таблицей:

• Закрыть графы "Тип диалога", чтобы не видеть их.

• В колонке "Выбор пользователя" пометить подходящие критерии.

• Для каждого диалога подсчитать количество совпадений выбора пользователя и пунктов.

• Выбрать тип диалога с наибольшей оценкой.

В таблице показаны возможные результаты действий создателя ПИ.

Граф диалога - это графическое представление сценария диалога. Граф представляет собой набор состояний системы, между которыми в ходе диалога при определенных условиях осуществляются переходы. Цели разработки сценария диалога:

• Выявление и устранение возможных тупиковых ситуаций.

• Выбор рациональных путей перехода из текущего состояния системы в требуемое.

• Выявление неодназначных ситуаций, когда для пользователя требуется дополнительная помощь.

Сценарий диалога можно упростить, снизив степень неопределенности действий пользователя. Для этого можно:

• Применить смешанную структуру диалога, ограничив при необходимости свободу выбора пользователя (например, используя меню).

• Контролировать вводимую пользователем информацию и принимать только допустимые данные.

Для описания диалога можно использовать две группы методов:

• Формальные методы. Они позволяют автоматизировать проектирование и модификацию диалога в соответствии с характеристиками пользователя.

• Неформальные методы. Позволяют строить эффективные, но уникальные структуры диалога.

Процесс ЧМВ связан с существенными объективными и субъективными ограничениями и должен соответствовать психофизиологическим возможностям человека: способности приема и переработки информации, объемам сенсорной и кратковременной памяти, уменью концентрировать внимание на наиболее важной информации, способности воспроизводить информацию из долговременной памяти. В связи с этим при разработке диалога нужно учитывать такие психофизиологические особенности потенциальных пользователей, как:

• моторные навыки,

• время реакции,

• восприимчивость цветовой гаммы.

Одной из важнейших характеристикой диалога является его темп. Он зависит от используемых аппаратных и программных средств, а также специфики решаемых задач. Время ответа (отклика) системы определяется как интервал между событием и реакции системы на него. Медленный ответ не соответствует психофизиологическим особенностям пользователя, что приводит к снижению эффективности работы. Излишне быстрый ответ системы "подгоняет" пользователя, что заставляет пользователя суетиться, чтобы не отстать от системы. Время ответа должно соответствовать естественному темпу работы людей, обычно это около 2 секунд.

Характеристики

Список файлов лекций