Интерфейс Человек-ЭВМ

Содержание

Слайд 2

Рекомендуемая литература 1. Гарретт Дж. Веб-дизайн: книга Джесс Гарретта. Элементы опыта

Рекомендуемая литература

1. Гарретт Дж. Веб-дизайн: книга Джесс Гарретта. Элементы опыта взаимодействия.

– СПб.: Символ-Плюс, 2008.
2. Влад. В.Головач Дизайн пользовательского интерфейса. Искусство мыть слона. /Владислав Гловач. - Электрон.ст. - Режим доступа к ст.: http://www.usability.ru/Articles/Cheap-BA.html
3. Гото К., Котлер Э. Веб-редизайн: книга Келли Гото и Эмили Котлер. – СПб.: Символ-Плюс, 2003. .
4. Круг С. Веб-дизайн: книга Стива Круга или «не заставляйте меня думать!». - СПб.:Символ-Плюс, 2008.
5. Купер А. Психбольница в руках пациентов или Почему высокие технологии сводят нас с ума и как восстановить душевное равновесие. - М.: Символ, 2005.
6. Мандел Т. Разработка пользовательских интерфейсов. – М.: ДМК Пресс, 2001..
7. Нильсен Я. Веб-дизайн: книга Якоба Нильсена. - СПб.:Символ-Плюс, 2003.
8. Раскин Д. Интерфейс: новые направления в проектировании компьютерных систем/Пер. с англ. – СПб.: Символ-плюс, 2003.
9. Терещенко П.В. Интерфейсы информационных систем: учебное пособие/ П.В.Терещенко, В.А.Астапчук. – Новосибирск: Изд-во НГТУ, 2012.
10.Терещенко П.В., Бакаев М.А. Взаимодействие в человеко-компьютерных системах.- Новосибирск: Изд-во НГТУ, 2021 -86с.
Слайд 3

Расчетно-графическое задание Терещенко П.В., Шахмаметов Р.Г. Пользовательские интерфейсы информационных систем. –

Расчетно-графическое задание

Терещенко П.В., Шахмаметов Р.Г. Пользовательские интерфейсы информационных систем. – Новосибирск,

НГТУ, 2010 (Методические указания к выполнению расчетно-графического задания )
Варианты заданий
1. ОЦЕНКА СУБЪЕКТИВНОЙ УДОВЛЕТВОРЕННОСТИ ПОЛЬЗОВАТЕЛЯ ИНТЕРФЕЙСОМ ПРОГРАММНОГО ПРОДУКТА
2. ОЦЕНКА КАЧЕСТВА ИНТЕРФЕЙСА С ИСПОЛЬЗОВАНИЕМ КОНТРОЛЬНОГО СПИСКА ИНТЕРФЕЙСА
Выполняются (выбор) Задания 1.1 и 2 или Задания 1.2.и 2
Слайд 4

Компетенции (роли) специалистов в области ИТ, необходимые для создания ПИ КИС

Компетенции (роли) специалистов в области ИТ, необходимые для создания ПИ КИС
Роль

руководителя команды, осуществляющей эргономическое проектирование ИС.
Роль аналитика (анализ информации для формирования требований в ПИ).
Роль эксперта (организация эргономической экспертизы).
Роль инженера (получение проектных данных, обеспечивающих пользователям выполнение рабочих заданий и трансформация их в проектные решения).
Роль проектировщика (проектирование системы с учетом человеческого фактора (эргономических стандартов)).
Роль специалиста по полевым методам (работа непосредственно с реальными или потенциальными пользователями).
Роль технического писателя: разработка проектной документации (руководств, стандартов проектирования и т.д. ); разработка пользовательской документации (руководств пользователя, глоссариев, учебных пособий и т.д.).
Роль тестировщика (организация юзабилити-тестирования и трансформация результатов тестирования в проектные решения).
Роль дизайнера пользовательского интерфейса (разработка концептуальных и детальных прототипов ПИ, стиля и элементов дизайна).
Роль специалиста по обучению пользователей (разработка учебного курса, организация процесса обучения пользователей).
Какие из этих 10-и ролей Вы можете выполнять компетентно?
Слайд 5

Интерфейсы существуют, чтобы ими пользовались Интерфейс можно считать успешным, когда люди

Интерфейсы существуют, чтобы ими пользовались
Интерфейс можно считать успешным, когда люди им

пользуются.
Интерфейс должен не только льстить вашему дизайнерскому эго: им должны пользоваться!
Никому не нужен великолепный стул, если на нем невозможно сидеть.
Слайд 6

Введение 1.Основные понятия 2. Предмет и задачи дисциплины 3.Структура курса При

Введение 1.Основные понятия 2. Предмет и задачи дисциплины 3.Структура курса При установлении порядка появились

имена. Поскольку возникли имена, нужно знать предел их употребления. Знание предела позволяет избавиться от опасности. Лао Цзы
Слайд 7

Структура деятельности: схема «треугольника» (И.Энгестрем) Средства деятельности Разделение труда Правила Субъект

Структура деятельности: схема «треугольника» (И.Энгестрем)

Средства деятельности

Разделение труда

Правила

Субъект

Объект

Сообщество (организация, группа)

Результат (присвоенный объектом)

Результат
(присвоенный

субъектом)
Слайд 8

Схема системы «моделирование» (из ОТС) Культура субъекта Субъект Объект Модель

Схема системы «моделирование» (из ОТС)
Культура субъекта

Субъект

Объект

Модель

Слайд 9

«Пирамида» познания (Р. Акоффа ) Опыт Наблюдение Эксперимент Измерение Данные Информация

«Пирамида» познания (Р. Акоффа )

Опыт Наблюдение Эксперимент Измерение

Данные

Информация
Что? Кто? Когда? Где?

Классификация. Модель состава.

Знание
Как? Обнаружение связей. Модель структуры.

Понимание.
Почему? Объяснение связей.

Мудрость.
Зачем? Мораль, эстетика. Этика, идеология

Слайд 10

Задачи курса Что вы должны делать как проектировщики и разработчики программного

Задачи курса
Что вы должны делать как проектировщики и разработчики программного продукта

(ИТ-приложения, корпоративной информационной системы) по отношению к пользователям вашего продукта?
Что вы не должны делать как проектировщики и разработчики программного продукта (ИТ-приложения, информационной системы) по отношению к пользователям вашего продукта?
Что вы должны знать для создания хорошего продукта?
1. Спрашивайте пользователей (Знать: Зачем? Когда? О чем? Как? … они получают информацию и действуют). Модель пользователя!
Создавайте дизайн ПО вместе с пользователями (Знать: Кто? С кем? Как? … создает дизайн ПО). Модель проектирования!
Проведите тестирование на практичность в использовании (Знать: Что? Кто? Где? Каким образом? … делает. Кому результаты?) .

Ответы

Слайд 11

Структура курса История развития ПИ Основные понятия Критерии качества ПИ Типичные

Структура курса
История развития ПИ
Основные понятия
Критерии качества ПИ
Типичные проблемы ПИ

Проектирование концептуальной

(ментальной) модели пользователя

Типы пользовательских интерфейсов

Законы, правила, принципы, модели
проектирование ПИ

Структурные свойства диалоговых систем

Подходы к проектированию ПИ.
Элементы интерфейса.
Понятность системы (интерфейса).
Основные правила и принципы
проектирования интерфейсов.
Количественная оценка интерфейса.
Тестирование.
Этапы проектирования.

Понятие ПИ.
Модели деятельности:
управленческой;
операторской;
специалиста.
Информационно-технологическая модель ЛПР.
Методы исследования пользователей.
Взгляды проектировщиков АИС на удовлетворение информационных потребностей пользователей (ИПП).
Структурные свойства диалога.

Слайд 12

Тема 1 История ПИ Основные понятия Критерии качества Типичные проблемы ПИ

Тема 1
История ПИ
Основные понятия
Критерии качества
Типичные проблемы ПИ

Слайд 13

1.История развития ПИ (в системах «Человек-ЭВМ») 1.1. Развитие до 60-х годов

1.История развития ПИ (в системах «Человек-ЭВМ»)
1.1. Развитие до 60-х годов
Надо

ответить на вопрос «Кто пользователи ЭВМ в это время?»
1.2. 1960 год
Дж.К.Р. Ликлайдер (J.R.Licklider) выдвинул идею "симбиоза человека и компьютера" – объединения человеческого интеллекта и вычислительной техники для управления информацией.
Предложил промежуточные цели, достижение которых предполагает реализацию данной идеи.
Ближайшие цели:
разделение времени компьютера между пользователями;
электронный ввод/вывод символьной и графической информации;
интерактивные системы реального времени для обработки информации и программирования;
крупномасштабные системы хранения и поиска информации.
Слайд 14

Среднесрочные цели: координация объединения разработчиков для проектирования и программирования больших систем;

Среднесрочные цели:
координация объединения разработчиков для проектирования и программирования больших систем;
способность ЭВМ

распознавать речь оператора;
способность ЭВМ распознавать рукописные тексты;
возможность использования светового пера, в качестве устройства ввода координат и указки (световое перо – светочувствительное устройство, позволяющее выбрать точку экрана дисплея, указывая на нее).
Долгосрочные цели:
понимание ЭВМ естественного языка;
способность ЭВМ распознавать речь произвольного пользователя;
эвристическое программирование, т.е. "интеллектуализация" работы программы путем придания ей большей гибкости и эвристичности "мышления".
Идеи кибернетики и рассмотрения ЭВМ как усилителя интеллекта.
Ответ академика В.М.Глушкова.
Слайд 15

1.3.Середина 60-х годов: Появились вычислительные машины, поддерживающие большое количество пользователей, каждый

1.3.Середина 60-х годов:
Появились вычислительные машины, поддерживающие большое количество пользователей, каждый из

которых получал в свое распоряжение выделенный интерфейс к системе (терминал) и мог работать в интерактивном режиме.
Айвен Сазерленд (Ivan Sutherland) (1963 год) разработал SketchPad – графический комплекс (прообраз будущих САПР), оказавший огромное влияние на формирование базовых принципов графических пользовательских интерфейсов. Основные идеи:
использование объектно-ориентированной модели, где любой нарисованный элемент представлялся n-компонентной структурой, его можно было копировать, перемещать, поворачивать или масштабировать, сохраняя основные свойства;
реализация алгоритма прорисовки окон и алгоритма обрезки.
Слайд 16

3. Командой Дугласа Энгельбарта (Douglas C. Engelbart) разработана среда NLS (oN-LineSystem),

3. Командой Дугласа Энгельбарта (Douglas C. Engelbart) разработана среда NLS (oN-LineSystem), включающая в

себя:
принципиально новую операционную систему;
универсальный язык программирования;
электронную почту;
разделенные экраны телеконференций;
систему контекстной помощи;
прототип WIMP-интерфейса - интерфейса, использующего понятия окон (windows), пиктограмм (icons), меню (menus) и указателей (pointers). (Эти понятия являются ключевыми и для сегодняшних графических пользовательских программ и сред.)
первый манипулятор типа мышь. Он был создан вследствие того, что к оконной среде NLS существующие манипуляторы (джойстики, световые перья и прочие) принципиально не подходили.
Слайд 17

1.4.Реальность 70-х годов Взаимодействие пользователя с ЭВМ обеспечивалось за счет, так

1.4.Реальность 70-х годов
Взаимодействие пользователя с ЭВМ обеспечивалось за счет, так называемого,

интерфейса командной строки (CLI, Command Line Interface).
В процессе взаимодействия человек вводил команды (предписания на языке команд), а  компьютер
реагировал соответствующим образом (исполнял предписания). 
Пользователь должен был точно знать, какая команда приведет к выполнению нужных ему действий и отвечал за последствия и правильность введения команды в командную строку.
Слайд 18

1.5.Конец 70-х – начало 80-х годов: Стало понятно, что при создании

1.5.Конец 70-х – начало 80-х годов:
Стало понятно, что при создании

персональных компьютеров необходимо учитывать удобство пользователей.
Накопились знания (технологии) в области проектирования систем «Человек-машина», позволяющие реализовать эргономическое (инженерно-психологическое) проектирование вычислительной техники.
Появились персональные компьютеры с графическим интерфейсом, спроектированные с учетом удобства пользователя.
ПОЭТОМУ: Назрела необходимость изучения человеко-компьютерного взаимодействия в университетах при подготовке специалистов в области компьютерных наук.
Слайд 19

1.6. Дисциплина Человеко-компьютерное взаимодействие Человеко-компьютерное взаимодействие (HCI, Human-Computer Interaction) – это

1.6. Дисциплина Человеко-компьютерное взаимодействие
Человеко-компьютерное взаимодействие (HCI, Human-Computer  Interaction) – это

дисциплина, имеющая дело с проектированием, оцениванием и реализацией интерактивных вычислительных систем для использования человеком, а также с изучением основных явлений, связанных с этими вопросами.
Это определение было сформулировано группой, ответственной за разработку рекомендаций к образовательной программе в области человеко-компьютерного взаимодействия в августе 1988.
Группа была сформирована из членов ассоциации по вычислительной технике ACM (Association  for Computing Machinery).
ACM и  IEEE  Computer  Society - это крупнейшие научно-профессиональные сообщества специалистов  по  вычислительной технике. Эти сообщества играют ключевую роль в разработке образовательных программ в области компьютерных наук. С этого времени модуль HCI  (человеко-компьютерное заимодействие) включается как обязательная часть в курс «компьютерные науки».
Слайд 20

Основные понятия Информационная технология. Информационная система. Пользователь/Человек-оператор. Система «Человек-машина». Коммуникации. Информационно-коммуникационные

Основные понятия
Информационная технология.
Информационная система.
Пользователь/Человек-оператор. Система «Человек-машина».
Коммуникации. Информационно-коммуникационные технологии.
Процесс. Прикладной

процесс.
Интерфейс/Интерфейс человеко-машинный.
Пользовательский интерфейс.
Среда человеко-машинного интерфейса.
Интерфейс прикладной программы.
Качество программного продукта.
Слайд 21

Информационные технологии – приемы, способы и методы применения средств ВТ при

Информационные технологии – приемы, способы и методы применения средств ВТ при

выполнении функций сбора, хранения, обработки, передачи и использования данных (ГОСТ 34.003-90)
Определение 1. Информационная система (Information system) - по законодательству РФ - организационно упорядоченная совокупность документов (массивов документов) и информационных технологий, в том числе с использованием средств вычислительной техники и связи, реализующих информационные процессы.
Определение 2. Информационная система – система, предназначенная для хранения, обработки, поиска, распространения, передачи и предоставления информации.
Определение 3. Информационная система (ИС) – это вся инфраструктура предприятия, задействованная в процессе управления всеми информационно-документальными потоками, включающая в себя следующие обязательные элементы:
Слайд 22

(Обязательные элементы ИС в определении 3) 1. Информационная модель. Представляет собой

(Обязательные элементы ИС в определении 3)
1. Информационная модель. Представляет собой совокупность

правил и алгоритмов функционирования ИС. Информационная модель также включает в себя все формы документов, структуры справочников и данных, и т.д.
2. Регламент развития информационной модели и правила внесения в неё изменений.
3. Персонал, отвечающий за формирование и развитие информационной модели. (Как носитель неявной корпоративной информации).
4. Программный комплекс (ПК). Конфигурация ПК соответствует требованиям информационной модели, регламентирующим техническую и пользовательскую поддержку на протяжении всего жизненного цикла ПК. (Требования к поставщику ПК).
5. Персонал, отвечающий за конфигурирование ПК, и его соответствие утвержденной информационной модели.
Слайд 23

Обязательные элементы ИС (продолжение): 6. Состав функциональных модулей ПК и регламент

Обязательные элементы ИС (продолжение):
6. Состав функциональных модулей ПК и регламент внесения

изменений в его конфигурацию.
7. Аппаратно-техническая база, соответствующая требованиям по эксплуатации ПК (компьютеры на рабочих местах, периферия, каналы телекоммуникаций, системное ПО и СУБД)
8. Эксплуатационно-технический персонал, включая персонал по обслуживанию аппаратно-технической базы.
9. Правила использования ПК, пользовательские инструкции, регламент обучения и сертификации пользователей.
Слайд 24

Определение 4. Информационная система - среда, обеспечивающая целенаправленную деятельность организации, которая

Определение 4. Информационная система - среда, обеспечивающая целенаправленную деятельность организации, которая

включает в себя такие компоненты, как информацию, процедуры, персонал, аппаратное и программное обеспечение, объединенные регулируемыми взаимоотношениями для формирования организации как единого целого и обеспечения ее целенаправленной деятельности. (Понятие архитектуры предприятия и архитектуры КИС)

Цели
и стратегии организации

Цели
и стратегии ИС и ИТ

ИТ и ИС –архитектуру
(ИТ-ресурсы)

Транслируются в

Определяют

Слайд 25

Обратите внимание! По сложившейся традиции, информационной системой зачастую называют программные комплексы

Обратите внимание!
По сложившейся традиции, информационной системой зачастую называют программные комплексы (ПК),

что не является корректным.
(В курсе мы опираемся на определения 3 и 4)
Слайд 26

Основные корпоративные системы. Современное состояние. Вопрос. Кто пользователи этих систем и

Основные корпоративные системы. Современное состояние. Вопрос. Кто пользователи этих систем и

в чем различие их ментальных моделей деятельности ?

CSRP

Слайд 27

Программные продукты, рассматриваемые как возможные программные составляющие АИС (корпоративной информационной системы):

Программные продукты, рассматриваемые как возможные программные составляющие АИС (корпоративной информационной

системы):
 системы управления ресурсами предприятия (ERP - системы);
системы управления распределенной логистикой;
системы управления данными об изделиях на предприятиях (PDM): CAD/CAM/CAE системы;
системы документооборота (docflow);
среда Internet/Intranet;
системы электронной коммерции (e-commerce);
системы управления информационными ресурсами;
Слайд 28

(продолжение) системы извлечения данных (data mining); системы анализа данных OLAP; системы

(продолжение)
системы извлечения данных (data mining);
системы анализа данных OLAP;
системы представления данных для

анализа руководством (MIS);
специализированные рабочие места автономных пользователей;
системы моделирования и представления бизнес-процессов;
системы математического и имитационного моделирования процессов;
системы статистического анализа данных;
специализированные продукты или системы для реализации частных задач;
(список можно продолжить).
Что общего и в чем отличие пользовательских интерфейсов этих продуктов?
Слайд 29

Пользователь информации - по законодательству РФ - субъект, обращающийся к информационной


Пользователь информации - по законодательству РФ - субъект, обращающийся к информационной

системе или посреднику за получением необходимой ему информации.
Человек-оператор (оператор) — человек, осуществляющий трудовую деятельность, основу которой составляет взаимодействие с объектом воздействия, машиной и средой на рабочем месте при использовании информационной модели и органов управления.
Определение 1. Система «человек – машина» — это система, включающая в себя человека-оператора, «машину» (посредством «машины» человек осуществляет трудовую деятельность) и среду на рабочем месте. («МАШИНА» = Исп.Мех.+Пер.Мех.+Энерг.Уст.+Рег.+Интел.Маш.)
Определение 2. Система «человек-машина» — сложная система, в которой человек-оператор (группа операторов) взаимодействует с техническим устройством в процессе производства материальных ценностей, управления, обработки информации и т.д.
Системы «человек-машина» являются предметом исследования эргономики, инженерной психологии, системотехники.
Слайд 30

Эргономика — междисциплинарная отрасль, использующая знания, методы исследования и технологии проектирования

Эргономика — междисциплинарная отрасль, использующая знания, методы исследования и технологии проектирования

из следующих отраслей человеческого знания и практики:
Инженерная психология (инженерно-психологическое проектирование систем «человек-машина».
Психология труда, теория групповой деятельности, когнитивная психология.
Конструирование.
Гигиена и охрана труда, научная организация труда.
Антропология, антропометрия.
Медицина, анатомия и физиология человека.
Теория проектирования (инженерия).
Теория управления.
Слайд 31

Понятия «коммуникация» и «общения» Коммуникация (от лат. сommunico - делаю общим).

Понятия «коммуникация» и «общения»
Коммуникация (от лат. сommunico - делаю общим).
Коммуникация

- в широком смысле - обмен информацией между индивидами через посредство общей системы символов.
Коммуникация - в кибернетическом подходе - процесс кодирования, передачи информации (сообщений) от источника и приема информации (сообщений) получателем (Модель ИСКП).
Коммуникация - в деятельностном подходе - совместная деятельность участников коммуникации (коммуникантов), в ходе которой вырабатывается общий (до определенного предела) взгляд на вещи и действия с ними.
Общение – это форма деятельности, осуществляемая людьми и приводящая к взаимовлиянию, взаимопереживанию и взаимопониманию.
Насколько применимо понятие «общение» в разработке ПИ?
Информационно-коммуникационные технологии. ?
Слайд 32

Этапы и уровни развития ЧМ-систем ИМ ИМ1 ИМ2 Исполнит. механизм 4

Этапы и уровни развития ЧМ-систем

ИМ

ИМ1

ИМ2

Исполнит. механизм 4

ИМ3

ПМ1

ПМ2

ПМ3

Передат. механизм 4

ЭУ1

ЭУ2

Энергет. установка

3

Рег.1

Регулятор 2

Интеллект. машина

t

Ч

Ч

Ч

Ч

Ч

Развитие «машины»

Развитие «человека»

Слайд 33

Интерфейс (Interface) Интерфейс - в широком смысле - определенная стандартами граница

Интерфейс (Interface)
Интерфейс - в широком смысле - определенная стандартами граница между

взаимодействующими независимыми объектами. Интерфейс задает параметры, процедуры и характеристики взаимодействия объектов.
Интерфейс – место, где независимая система встречается и взаимодействует или проводит коммуникацию с другой такой же системой.
Интерфейс человеко-машинный (интерфейс) — комплекс технических и информационно-программных средств, посредством которых осуществляется диалоговый режим взаимодействия человека-оператора и машины.
Интерфейс прикладной программы(Application program interface) - интерфейс, посредством которого приложение получает доступ к операционной системе и другим сервисам.
Интерфейс (API) обеспечивает предоставление различных видов сервиса:
Системного (доступ к операционной системе).
Сетевого (обмен информацией по каналам связи между распределенными в пространстве процессами).
Информационного (доступ к базам данных).
Пользовательского (взаимодействие с пользователем).
Межпроцессного (взаимодействие прикладных программ)
Слайд 34

Пользовательский интерфейс 1. Пользовательский интерфейс – в самом широком смысле –

Пользовательский интерфейс
1. Пользовательский интерфейс – в самом широком смысле –

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

Пользователь
Пользовательский интерфейс

Процессы ввода
и вывода

Диалоговый
процесс

Слайд 35

Пользовательский интерфейс (ПИ, User Interface, UI, интерфейс пользователя). ПИ объединяет в

Пользовательский интерфейс (ПИ, User Interface, UI, интерфейс пользователя).
ПИ объединяет в себе

все элементы ИС, включая компоненты программы, которые способны оказывать влияние на взаимодействие пользователя с программным обеспечением.
К этим элементам относятся:
средства отображения информации,
отображаемая информация, форматы и коды;
командные режимы, язык взаимодействия;
устройства и технологии ввода данных;
диалоги, взаимодействие и транзакции между пользователем и компьютером;
обратная связь с пользователем (средства поддержки взаимодействия пользователя с ИС);
поддержка принятия решений в конкретной предметной области;
порядок использования программы и документация на нее.
Слайд 36

Пользовательский интерфейс (место в ИС) Пользователь Прикладной процесс (ПП) БД Бизнес-процесс

Пользовательский интерфейс (место в ИС)

Пользователь

Прикладной
процесс (ПП)

БД

Бизнес-процесс

Прикладной
Процесс
(Удаленный)

БД

Пользовательский
интерфейс

ПП

Платформа. Процессы платформы

Слайд 37

Среда человеко-машинного интерфейса: Порождается: технико-технологическими и инженерно-психологическими решениями, в их динамическом

Среда человеко-машинного интерфейса:
Порождается:
технико-технологическими и инженерно-психологическими решениями, в их динамическом

единстве и целостности ;
психофизиологической системой оператора (пользователя);
действительностью и факторами, её обеспечивающими (значимыми для пользователя);
2. Позволяет оператору (пользователю) получить и реализовать опыт для осуществления эффективной профессиональной деятельности.
Слайд 38

Виртуальная реальность (виртуальная интерактивная среда) — генерируемый компьютером искусственный мир, в

Виртуальная реальность (виртуальная интерактивная среда) — генерируемый компьютером искусственный мир, в

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

Качество программного продукта Пользователи взаимодействуют с компьютерами так же как с

Качество программного продукта
Пользователи взаимодействуют с компьютерами так же как с другими

предметами окружающего мира. Они имеют собственное представление о том как компьютер должен работать и помогать им в решении их задач
Существующая практика

Разработчики не понимают,
кто их клиенты

Пользователи не понимают,
зачем им нужна система

Поймите: Кто он такой? - Пользователь вашего программного продукта?

Помните
Не может быть одного наилучшего инструмента, наилучшей программы,
интерфейса для пользователя, потому что цели пользователей
меняются в зависимости от решаемых ими задач.
Компьютер (Программный продукт) – это одно из возможных средств
решения задач.
3. Нельзя давать в интерфейсе пользователю инструментов, которые
позволяют ему делать то, что вам не надо.
4. Нет такой программы или ПИ, которые отвечали бы всем потребностям
пользователя во все времена.

Слайд 40

Качество программного продукта – это качество опыта применения его пользователем в

Качество программного продукта – это качество опыта применения его пользователем в

своей работе, качество опыта успешной и положительной работы пользователя.
Наше взаимодействие с предметами (в том числе и с программными продуктами) определяется нашим опытом работы с ними (или с предметами похожими на них) и ожиданием того, как они будут работать. Мы реагируем на объекты согласно нашему опыту и нашим ожиданиям.
Под «опытом» понимаются все аспекты применения пользователем интерактивной программы:
впечатления от самого продукта;
понимание, как он работает;
ощущения, возникающие при работе с программой;
выполнение программой своего предназначения;
взаимодействие программы с другими программами.
При создании ИС, для понимания места «опыта» в структуре деятельности пользователя, необходимо:
использовать модель действующего субъекта;
понимать различие сущностей управленческой, операторской деятельности и деятельности специалиста. Ответить на вопрос «Как будет формироваться опыт?»
Слайд 41

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

Качество пользовательского интерфейса
Проектирование программного продукта должно базироваться на опыте и ожиданиях

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

Пользовательский
интерфейс

Специалисту в области информатики необходимо различать три модели ПИ:
Пользовательскую (концептуальную модель пользователя).
Программиста.
Проектировщика.

Точка зрения пользователя

Точка зрения программиста

Точка зрения проектировщика

Слайд 42

Три модели пользовательского интерфейса Модель проектировщика Концептуальная модель пользователя Модель программиста

Три модели пользовательского интерфейса

Модель проектировщика
Концептуальная модель пользователя
Модель программиста
Принципы и методы

проектирования ПИ

Модель программиста
Платформа
Операционная система
Оболочка
Инструменты разработки
Принципы и методы разработки

Концептуальная модель
пользователя
Опыт взаимодействия в реальном
мире:
Задачи
Процессы
Инструменты
Результаты

Слайд 43

Критерии обеспечения качества пользовательского интерфейса Понимание пользователей Эффективность процесса проектирования Изменяемость

Критерии обеспечения качества пользовательского интерфейса

Понимание
пользователей

Эффективность
процесса
проектирования

Изменяемость

Потребности

Управляемость

Эстетическое
чувство

Соответствие

Пригодность
к обучению

и использованию

Качество
опыта

Слайд 44

Характеристика критериев обеспечения качества пользовательского интерфейса Понимание пользователей (мотивация, функционал) понимание

Характеристика критериев обеспечения качества пользовательского интерфейса
Понимание пользователей (мотивация, функционал)
понимание группой проектировщиков

потребностей и задач тех людей, для которых предназначен программный продукт;
отражение понимания в программном продукте.
Потребности
потребности, удовлетворяемые продуктом;
экономическая, общественная и другая значимость продукта.
Управляемость
поддержка продуктом функциональности в полном объеме деятельности пользователя;
помощь пользователям в управлении процессами инсталяции, тренировки, сопровождения и др.;
соответствие требованиям коммерческих мероприятий;
соответствие концепции «право собственности».
Изменяемость
обоснованность способности продукта изменяться;
соответствие продукта требованиям индивидуального и группового использования;
возможности продукта подстраиваться под различные случаи использования.
Слайд 45

Пригодность к изучению и использованию сложность продукта в использовании и обучении;

Пригодность к изучению и использованию
сложность продукта в использовании и обучении;
организация поддержки

продукта в использовании;
наличие альтернативных путей достижения целей пользователем в зависимости от его опыта, навыков и привычек.
Соответствие
соответствие культурным, социальным, психологическим, экономическим и технико-технологическим аспектам жизнедеятельности пользователя;
соответствие требованиям практичности и целесообразности;
соответствие решению поставленных (заявленных) проблем.
Эстетическое чувство
цельность продукта с точки зрения дизайна, графики, последовательности действий, информативности;
удовлетворение технологическим нормам;
насколько его использование эстетически приятно;
хорошая интеграция программного и технического обеспечения.
Эффективность процесса проектирования
Эффективность менеджмента проекта, т.е. является ли продукт результатом управляемого проекта на всех этапах его жизненного цикла.
Слайд 46

Типичные проблемы интерфейса отечественных ИС Мнение специалистов: в большинстве случаев специалисты

Типичные проблемы интерфейса отечественных ИС
Мнение специалистов: в большинстве случаев специалисты

сталкиваются с однотипными проблемами, вызванными столь же однотипными ошибками разработчиков при проектировании ПО.
Эти проблемы таковы:
интерфейс не адекватен особенностям пользователей;
интерфейс не адекватен среде использования системы;
интерфейс не адекватен содержательной деятельности пользователей;
интерфейс не адекватно отражает объекты и связи между ними.
Примечание:
Здесь перечислены только типичные проблемы – проблемы несоответствия критериям качества ПИ.
Эти проблемы, как правило, не существуют по отдельности. На практике каждая система обладает тем или иным набором этих проблем.
Слайд 47

Интерфейс не адекватен особенностям пользователей Любой разработчик, начиная проектировать систему, всегда

Интерфейс не адекватен особенностям пользователей
Любой разработчик, начиная проектировать систему, всегда определяет

аппаратные требования к системе.
Требования, относящиеся к ограничениям и особенностям пользователей системы (ограничениям со стороны бизнес-контекста или пользовательской деятельности), детально не всегда определяются. В результате получается система, интерфейс которой:
в лучшем случае - противоречив (модули системы рассчитаны на различных по уровню квалификации пользователей и т.д.);
в худшем случае - подходит только таким пользователям, которые заведомо не будут пользоваться системой.
Единственным решением этой проблемы является формализация пользовательских требований к системе до начала проектирования самой системы (переделывать готовую систему гораздо дороже).
Слайд 48

Интерфейс не адекватен среде использования системы Основные составляющие среды использования: 1.

Интерфейс не адекватен среде использования системы
Основные составляющие среды использования:
1. Временные

ограничения на выполнение действия.
Если не определить временные характеристики интерфейса, то вероятность удовлетворения временным ограничениям со стороны деятельности пользователя (удовлетворения системы требованию к скорости) будет невелика.
2. Наличие прерываний в деятельности пользователей. Работа с информационной системой не является основной деятельностью многих пользователей. Пользователи могут отвлекаться на другую работу. В таких случаях интерфейс должен помогать пользователю вернуться к работе с информационной системой. Также во многих системах автоматизации есть операции, выполняемые во время разговора пользователя по телефону (например: операции в деятельности операторов складов и др.). Такие операции должны занимать малое время и должна быть обеспечена возможность возврата к системе.
3. Ограничения со стороны аппаратных средств
Например: разрешение мониторов и т.д.
Слайд 49

Интерфейс не адекватен содержательной деятельности пользователей Это ключевая проблема, суть которой

Интерфейс не адекватен содержательной деятельности пользователей
Это ключевая проблема, суть которой заключается

в следующем:
1. Структура пользовательского интерфейса приведена в соответствие с информационными потоками (структурой объектов) внутри самой информационной системы, а не в соответствие со структурой реальной коммуникационной деятельности пользователей:
интерфейс «зашумлен» информацией, релевантной объекту, с которым работает пользователь, но не нужной ему при решении конкретной задачи, либо не нужной ему вообще;
интерфейсные элементы (выходная информация или блоки ввода информации) являются атрибутами разных объектов и размещены на разных экранах, но для выполнения операций с этими интерфейсными элементами пользователю необходимо взаимодействовать с ними одновременно.
2. Создается интерфейс, обладающий универсальностью, т.е. разрабатывается единое окно, с которым будет работать несколько разных пользователей. Но эта универсальность зачастую оборачивается значительной неэффективностью интерфейса и, следовательно, системы в целом.
Пользовательский интерфейс должен, в первую очередь, определяться
структурой деятельности пользователей (структурой его опыта), а не
структурой объектов, с которыми пользователь взаимодействует в
процессе работы.
Слайд 50

Интерфейс неадекватно отображает объекты системы и связи между ними Типичные ошибки

Интерфейс неадекватно отображает объекты системы
и связи между ними
Типичные ошибки однозначности отображения

объектов в интерфейсе:
1. Взаимное размещение объектов на экране не совпадает с их логической связью и/или с их важностью.
2. В интерфейсе много избыточности.
Если заранее неизвестно, как именно пользователи будут работать с системой, у разработчиков возникает искушение многократно дублировать средства вызова объектов (например, вызвать один и тот же экран можно несколькими разными способами) в расчете, что если этих средств будет много, пользователь найдет хотя бы одно. Но чаще всего избыточность снижает эффективность интерфейса.
3. Разные части системы разрабатываются разными членами команды проекта без согласования друг с другом.
Команда проекта не имеет внутреннего стандарта на интерфейс.
4. Интерфейс разрабатывается без учета сложившихся стандартов.
Команда проекта не учитывает «внешние» стандарты на интерфейс. Эта проблема существенна для интернет-приложений, где стандартов почти нет.
Слайд 51

Пути решения проблем Построение модели деятельности пользователя (ментальной, когнитивной, концептуальной). Использование

Пути решения проблем
Построение модели деятельности пользователя (ментальной, когнитивной, концептуальной).
Использование технологии проектирования

АИС:
обоснование выбора подхода к проектированию ПИ;
следование правилам и принципам разработки ПИ;
использование стандартизованных интерфейсных библиотек (интерфейсных элементов, терминов и т.д.)
Слайд 52

Раздел 2 Концептуальная (ментальная) модель пользователя

Раздел 2
Концептуальная (ментальная) модель
пользователя

Слайд 53

Концептуальная модель пользователя Необходимость построения концептуальной (ментальной) модели пользователя. Ментальные способности

Концептуальная модель пользователя
Необходимость построения концептуальной (ментальной) модели пользователя.
Ментальные способности человека.
Схема формирования

опыта.
Структура работы (на примере управленческой деятельности).
Информационно-технологическая модель процесса принятия решений (ППР) /рассмотрена раньше/.
Функциональные, нефункциональные требования.
Источники требований.
Стратегии выявления требований.
Слайд 54

Необходимость построения концептуальной (ментальной) модели пользователя Проектирование концептуальной (ментальной) модели пользователя

Необходимость построения концептуальной (ментальной) модели пользователя
Проектирование концептуальной (ментальной) модели
пользователя –

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

РАБОТА

Информационные
потребности
пользователя (ИПП)

Слайд 55

Когнитивность – способность к умственному восприятию (когнитивное сознательное и когнитивное бессознательное)

Когнитивность – способность к умственному восприятию (когнитивное сознательное и когнитивное бессознательное)

и переработке внешней информации.
Бихевиоризм – до 50-х годов
Когнетика – с 50-х годов
Понятие когнитивность применяют к таким процессам как:
Память.
Внимание.
Восприятие.
Действие.
Принятие решений.
Воображение.
Сейчас исследуют в рамках когнетики эмоциональную компоненту.
Но есть другие взгляды. Например: «тело» – «душа»; «тело» – «душа» – «вера», где «душа»= разум + воля + чувства.
Слайд 56

Концептуальная (ментальная) модель – это внутреннее отображение того, как пользователь понимает

Концептуальная (ментальная) модель – это внутреннее отображение того, как пользователь понимает

и взаимодействует с информационной системой.
Ментальная модель помогает людям предсказывать, что произойдет далее. Она служит основой для понимания, анализа и принятия решений.
Ментальная модель позволяет пользователю:
предсказывать или обозначать события;
искать (приписывать) причины событий;
определять действия для осуществления нужных изменений;
использовать ее для запоминания событий и связей;
обеспечивать понимание аналогичных ситуаций;
преодолевать ограничения, заложенные в алгоритме обработки информации.
Слайд 57

Основа ментальной модели - все взаимоотношения между пользователем и их компьютерами,

Основа ментальной модели - все взаимоотношения между пользователем и их компьютерами,

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

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

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

Слайд 58

Свойства человека Необходимо исследовать Есть научные знания для моделирования Уникальные Типические

Свойства человека

Необходимо
исследовать

Есть научные знания
для моделирования

Уникальные

Типические

Стабиль-
ные

Перемен-
ные

Репертуарные решетки

Слайд 59

Ментальные способности человека Мы не можем перестроить внутренние механизмы сознания людей.

Ментальные способности человека
Мы не можем перестроить внутренние механизмы сознания людей.
Но!
Мы

создаем программные продукты для людей, поэтому интерфейс продуктов необходимо согласовать с когнитивными способностями человека.
1. Важно понимание влияния внутренних механизмов сознания на работу пользователя.
2.Необходимо правильно учитывать в проектировании ПИ особенности:
когнитивного сознательного;
когнитивного бессознательного.
Бессознательными будем называть те процессы, которые не осознаются человеком в тот момент, когда они происходят.
Нас не интересует природа и механизмы процессов.
Нам необходимы знания для применения их при проектировании ПИ.
Слайд 60

Свойства когнитивного сознательного и бессознательного

Свойства когнитивного сознательного и бессознательного

Слайд 61

Слайд 62

Ментальные способности человека (продолжение) 3. Можно представить сознательное и бессознательное как

Ментальные способности человека (продолжение)
3. Можно представить сознательное и бессознательное как

некие два отдела:
в них хранятся мысли или воспоминания.
они имеют разные способы взаимодействия с окружающим миром и с воспринимаемыми понятиями.
4. Мы до конца не знаем их свойства.
5. Когнитивное сознательное включается в тех случаях, когда человек сталкивается с ситуацией, которая кажется новой или представляет угрозу.
6. Когнитивное сознательное работает последовательно и может оперировать только одним вопросом или контролировать только одно действие в течении некоторого промежутка времени. Человек может осознавать от 4 до 8 отдельных мыслей или объектов.
7. Когнитивное сознательное проявляется всегда при решении ветвящихся задач. По мере повторения задачи ее выполнение может стать неветвящимся и автоматическим.
Слайд 63

8. Человек может, в определенной мере, контролировать превращение бессознательных мыслей в

8. Человек может, в определенной мере, контролировать превращение бессознательных мыслей в

сознательные. Но он не может намеренно перевести сознательные мысли в бессознательную область.
9. Из всех объектов или явлений окружающего мира, которые человек воспринимает с помощью своих органов чувств (сенсорных анализаторов) или воображения, в каждый момент времени он может сконцентрироваться только на одном.
Будем называть «локусом внимания» такое явление, когда в конкретный момент времени человек обращает внимание на мысль о чем-то.
Помните: Вы воспринимаете вашими органами чувств намного больше того, что становится локусом внимания.
10. Когда информация, находящаяся в сенсорном регистре становится локусом внимания, она перемещается в кратковременную память (в зону когнитивного сознательного)
11. Привычка – это отказ от внимания к деталям, то есть утрата сознательного контроля над выполняемым действием – действие выполняется автоматически.
Слайд 64

12. При постоянном использовании интерфейса у человека всегда формируются привычки, которые

12. При постоянном использовании интерфейса у человека всегда формируются привычки, которые

в дальнейшем трудно преодолеть. Задача проектировщиков ПИ – создавать интерфейсы, которые не позволяют привычкам вызывать проблемы у пользователей.
13. Автоматизм – выполнение действий человеком без участия сознания.
14. Автоматизм позволяет выполнять несколько действий одновременно. Поэтому все одновременно выполняемые человеком действия, за исключением одного, находящегося в локусе внимания, являются автоматическими.
15. Если человек выполняет несколько задач одновременно, ни одна из которых не является автоматичной, то он должен переключать внимание с одной задачи на другую, для сознательного контроля.
16. Никаким количеством повторений решения задачи (при обучении) нельзя научить человека не формировать привычки (при регулярном использовании того или иного интерфейса). Поэтому любой запрос о подтверждении, требующий установленного ответа, вскоре становится бесполезным.
Слайд 65

Схема формирования опыта Действующий субъект Опыт Видение предмета деятельности Ожидания Результат

Схема формирования опыта
Действующий
субъект

Опыт

Видение
предмета
деятельности

Ожидания

Результат
деятельности

Приоритеты
текущей
деятельности

Опред.

Включ.

Включ.

Формирует (влияет на) опыт

Слайд 66

Структура работы ОПЫТ Модели Компетенции ЗНАНИЯ Ценности цели/средства Стиль поведения В

Структура работы

ОПЫТ

Модели

Компетенции

ЗНАНИЯ

Ценности
цели/средства

Стиль
поведения

В управленческой
деятельности

В операторской
деятельности

В деятельности
специалиста

Слайд 67

Пример: Управленческое мышление Деятельность руководителя связана с решением множества задач —

Пример: Управленческое мышление

Деятельность руководителя связана с решением множества задач —

от «архитектурных», касающихся создания организации как единого целого, до координационных, ежедневно обеспечивающих взаимодействие людей разных специальностей.
Управленческое мышление — это:
1. Способность одновременно видеть:
целое и части;
процесс и результат;
индивидуальное и коллективное.
2. Умение использовать интеллектуальные инструменты, подходящие для решения конкретной задачи.
Знание инструментов открывает новые возможности.
«Если умеешь пользоваться только молотком, то повсюду мерещатся гвозди».
Слайд 68

Характеристика контекста управленческой деятельности Граница системы Граница организации Действующий субъект

Характеристика контекста управленческой деятельности

Граница системы
Граница организации

Действующий субъект

Слайд 69

Схема уровней осуществления действия в управленческой деятельности Границы системы Действующий субъект

Схема уровней осуществления действия в управленческой деятельности

Границы системы

Действующий субъект

Слайд 70

Три уровня осуществления действия в управленческой деятельности Первый уровень, - это

Три уровня осуществления действия в управленческой деятельности
Первый уровень, - это уровень

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

От менеджера зависит, какой именно уровень деятельности он выберет. Но при

От менеджера зависит, какой именно уровень деятельности он выберет. Но при

этом он знает и о существовании двух других уровней.
Тот уровень, на котором менеджер предпочитает работать – это важная детерминанта стиля его деятельности.
Это обстоятельство позволяет выделить:
«деятелей» - тех, кто предпочитает работать на уровне непосредственного действия;
«лидеров» - тех, кто ориентируется на работу с людьми;
«администраторов» - тех, кто опирается в основном на управление информационными потоками
Слайд 72

Стереотипы относительно использования информационных ресурсов, характеризующие корпоративную культуру «Руководитель нуждается в

Стереотипы относительно использования информационных ресурсов, характеризующие корпоративную культуру
«Руководитель нуждается в абсолютно

полной информации»
Руководителю нужна не "полная информация по предприятию" - ему нужна информация:
совокупная;
достоверная;
взвешенная  (собранные и обработанные данные);
распределенная по основным направлениям деятельности компании;
пригодная для всестороннего анализа;
достаточная для принятия решения.
Ее объем, степень формализации и детализации определяет сам руководитель в соответствии с информационной политикой предприятия, важностью задач, положением руководителя в иерархии управления, его ответственностью и уровнем компетентности, пониманием целей и миссии компании.
Пример: Планово-финансовые , производственные и сбытовые подразделения предприятия.
Одни отчитываются  по декадному циклу, другие - по недельному;
Одни считают проданной продукцию, выехавшую за ворота предприятия, а другие - лишь ту, по которой поступила оплата, и т. д.
Руководитель, требуя полную отчетность, получает несводимую информацию.
Слайд 73

2. «Чем больше информации, тем лучше» При наличии многоуровневой системы и

2. «Чем больше информации, тем лучше»
При наличии многоуровневой системы и

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

3. «К моему бизнесу нельзя подходить с обычными мерками!» Руководители таких

3. «К моему бизнесу нельзя подходить с обычными мерками!»
Руководители таких компаний:
всячески

стараются индивидуализировать свои бизнес-процессы;
упор в развитии компании делают не на объективное состояние экономики и конъюнктуры, а на умение улаживать дела с органами государственной власти, региональными администрациями и т.д.
ходят "по лезвию ножа" и информация, на основе которой они принимают решения, носит не деловой характер.
считают, что трудно использовать стандартизированную информационную систему для обслуживания своего предприятия.
Есть противоположный взгляд, когда предприниматели:
 максимально унифицируют свой бизнес с помощью признанных  международных стандартов и прибегают к независимому аудиту с целью минимизации затрат.
Понимают, что деятельность промышленных предприятий на 80% состоит из вполне стандартных бизнес-процессов.
Слайд 75

4. "Предприятие, обеспеченное первоклассной информацией и соответствующими технологиями, может и должно

4. "Предприятие, обеспеченное первоклассной информацией и соответствующими технологиями, может и должно

работать как часы»
Этот стереотип является следствием моды и дилетантского отношения к  менеджменту. "Постановка регулярного менеджмента" объявляется панацеей от всех бед - менеджмент прост, как семь нот, достаточно выучить их.
С позиции теории игр (по определению), бизнес – это игра с многосторонней стратегией, а в такой игре нет и быть не может заданных единственно правильных ходов. Все зависит от сферы деятельности, истории предприятия, его размеров, личностей руководителя и его команды, сложившихся взаимоотношений, выбранной стратегии развития и т.д.. Влияют также многочисленные внешние факторы. Поэтому бессмысленно говорить о "правильной" организации и расписывать, как должны выглядеть ее "правильные" организационная и информационная структуры.
Руководитель должен прояснить для себя, где находится предприятие в системе рыночных координат и куда движется, на какой сегмент рынка ориентируется, чем отличается от конкурентов, как воспринимается потребителями, клиентами.
Слайд 76

5."Неважно, кому подчиняется ИТ- служба" В таких компаниях ИТ-служба подчиняется кому

5."Неважно, кому подчиняется ИТ- служба"
В таких компаниях ИТ-служба подчиняется кому угодно,

только не первому лицу. Она может подчиняться главному инженеру. Если же на предприятии важной фигурой является главный бухгалтер, он вполне может подчинить службу себе, и в этом случае ИТ-подразделения фактически становятся частью бухгалтерии.
Как следствие – архитектура ИС - "лоскутная" автоматизация. Ее пороки очевидны: заказчиками разработок в этом случае являются представители служб предприятия. Для разработчиков достаточно понять алгоритм, по которому действует персонал, закодировать его, тестировать и внедрить. Результатом автоматизации, таким образом, будет консервация сложившегося положения, со всеми его пороками и недостатками.
На бизнес в целом подобные ИТ-службы не оказывают практически никакого влияния. Это не соответствует той роли, которую должны играть современные информационные технологии в бизнесе.
С другой стороны, трудно представить себе работающее предприятие, не имеющее опыта"лоскутной" автоматизации, не эксплуатировавшее различные программные средства (свои или закупленные) . «Лоскутная»  автоматизация  - это этап развития ИТ .
Слайд 77

Компоненты управленческой деятельности Внешняя среда Условия Нормы Принципы Потребность Мотив ЦЕЛЬ

Компоненты управленческой деятельности

Внешняя среда

Условия

Нормы

Принципы

Потребность Мотив

ЦЕЛЬ

Задачи

Технология (методы, средства)

Действие

Результат

Критерии

Оценка

Саморегуляция

Слайд 78

Информационно-технологическая модель ППР Этап 1 Подготовка и анализ данных Этап 2

Информационно-технологическая модель ППР

Этап 1
Подготовка и анализ данных

Этап 2
Подготовка задачи

Этап 3
Разработка вариантов

решения

Этап 4
Принятие решения

Этап 5
Оформление решения

Стадия
предрешения

Стадия
принятия
решения

Слайд 79

Логика процесса выбора ЛПР Представления об альтернативах Декларативное знание Представления о

Логика процесса выбора ЛПР

Представления об
альтернативах
Декларативное
знание

Представления о
действиях
Процедуральное
знание

Представления о
ценностях

Результат
выбора

Субъект
выбора

Процесс выбора,

осуществляемый ЛПР
состоит в одновременном конструировании
им для данной ситуации выбора 3-х
исходных объектов и одного
результирующего

ЛПР отрабатывает для ситуации
свои схемы, которые у него
закрепляются в стереотипах
мышления и поведения

Слайд 80

Исследование пользователей Функциональные, нефункциональные требования. Источники требований. Стратегии выявления требований. Маркетинговые

Исследование пользователей

Функциональные, нефункциональные требования.
Источники требований.
Стратегии выявления требований.
Маркетинговые исследования.
Исследование контекста.
Метод карточной сортировки.
Анализ

рабочих заданий.
Сегментация пользовательской аудитории (метод персонажей).
Контрольные листы (Checklists).
Плюралистическая проработка.
Протоколы самоотчета.
Фиксация «мыслей вслух».
Фокус-группы.
Эвристическое исследование.
Экспертиза компонентов.
Слайд 81

Определение понятия требования 1. В русской редакции нотации RUP (Rational Unified

Определение понятия требования
1. В русской редакции нотации RUP (Rational Unified Process)

приводится следующее определение: "Требование - это условие или возможность, которой должна соответствовать система". RUP – это процесс, направленный на поддержку коллективной разработки программной системы (ПС). RUP – это технологический процесс по созданию ПС, позволяющий улучшить производительность коллективной разработки путем предоставления для всех этапов жизненного цикла методик выполнения основных видов деятельности, шаблонов документов, инструкций по работе с инструментальными средствами. Все модели в RUP представляются в нотации UML.
2.В IEEE Standard Glossary of Software Engineering Terminology (1990) данное понятие трактуется шире. Требование - это:
условия или возможности, необходимые пользователю для решения проблем или достижения целей;
условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
документированное представление условий или возможностей для пунктов a) и b).
3. Требования - это исходные данные, на основании которых проектируются и создаются автоматизированные информационные системы. Требования нужны для того, чтобы Разработчик мог определить и согласовать с Заказчиком временные и финансовые перспективы проекта автоматизации. Поэтому значительная часть требований должна быть собрана и обработана на ранних этапах создания АИС.
Слайд 82

Требования к продукту и процессу Требования к продукту (каким должен быть

Требования к продукту и процессу
Требования к продукту (каким должен быть продукт?).


В своей основе требования - это то, что формулирует заказчик с целью получения хорошего конечного продукта - функционального и удобного в использовании. Требования к продукту являются основополагающим классом требований.
Требования к проекту (как следует создавать заказанный продукт?).
1. Это требования к тому, как Разработчик будет выполнять работы по созданию программной системы . Без регламентации этого процесса Заказчиком можно было бы обойтись, если бы все проекты всегда выполнялись точно и в срок. Статистика результатов программных проектов говорит об обратном.
2. Заказчик, вступая в договорные отношения с Разработчиком, несет различные риски, главными из которых является риск получить продукт с опозданием, либо ненадлежащего качества.
3. Регламентация процесса создания программного обеспечения и его аудит – это основные мероприятия по контролю и снижению риска.
4. Детальность регламентации требований к проекту зависит от множества факторов, таких, как ценность конечного продукта для Заказчика, степень доверия Заказчика к Разработчику, сумма подписанного контракта, увязка срока сдачи продукта в эксплуатацию с бизнес-планами Заказчика и т.д.
5. Хотя регламентация процесса Заказчиком позволяет снизить его риски, но мероприятия Заказчика по регламентации процесса приводят к дополнительным накладным расходам.
6.Требуется найти разумный компромисс между степенью контроля рисков и величиной расходов.
В качестве требований к проекту может быть внесен:
регламент отчетов Разработчика;
регламент совместных семинаров по оценке промежуточных результатов;
требования к компетенции и количеству участников рабочей группы, исполняющих проект;
указание на методологию управления проектом.
Слайд 83

Функциональные, нефункциональные требования Функциональные требования регламентируют функционирование или поведение системы (behavioral

Функциональные, нефункциональные требования
Функциональные требования регламентируют функционирование или поведение системы (behavioral requirements).

Функциональные требования отвечают на вопрос "что должна делать система" в тех или иных ситуациях. Функциональные требования определяют основной "фронт работ" Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые системой Заказчику.
Функциональные требования записываются разными способами. Например при посредстве предписывающих правил: "система должна позволять …… ", при помощи задания вариантов использования (users cases) и т.д. Это - основной, определяющий вид требований.
Слайд 84

Нефункциональные требования регламентируют внутренние и внешние условия или атрибуты функционирования системы.

Нефункциональные требования регламентируют внутренние и внешние условия или атрибуты функционирования системы.

Выделяют следующие основные группы нефункциональных требований:
1. Внешние интерфейсы (External Interfaces).
интерфейс пользователя (User Interface, UI)
интерфейсы с внешними устройствами (аппаратные интерфейсы);
программные интерфейсы;
интерфейсы передачи информации (коммуникационные интерфейсы).
2. Атрибуты качества (Quality Attributes),
3. Ограничения (Constraints).
Основные атрибуты качества:
применимость,
надежность,
производительность,
эксплуатационная пригодность и т.д.
Слайд 85

Источники требований Основным источником требований к информационной системе являются соображения, высказанные

Источники требований
Основным источником требований к информационной системе являются соображения, высказанные представителями

Заказчика. Данная информация структурируется как минимум на 2 уровня:
бизнес-требования;
требования пользователей.
Проблема состоит в том, что требования формулируются к создаваемой, еще не существующей системе, т.е. по сути решается начальная подзадача задачи проектирования АИС, а представители Заказчика далеко не всегда бывают компетентны в данном вопросе
Слайд 86

2. Наряду с требованиями, высказанными Заказчиком, целесообразно собирать и требования от

2. Наряду с требованиями, высказанными Заказчиком, целесообразно собирать и требования от

других совладельцев системы:
сотрудников аналитической группы исполнителя;
внешних экспертов и т.д.
Результирующий, часто достаточно сырой материал представляется, как документ «Требования совладельцев (стейкхолдеров)». На требования совладельцев обычно не накладывается никаких специальных ограничений.
Слайд 87

3. Важным источником информации, помимо выявления требований, являются артефакты, описывающие предметную

3. Важным источником информации, помимо выявления требований, являются артефакты, описывающие предметную

область, так как модель создаваемой информационной системы в определенной мере должна отражать модель организационной системы. Это могут быть:
документы с описанием бизнес-процессов предприятия, выполненные консалтинговым агентством;
документы (должностные инструкции, распоряжения, своды бизнес-правил), принятые на предприятии.
Слайд 88

4. Еще одна альтернатива, используемая при выявлении требований - так называемые

4. Еще одна альтернатива, используемая при выявлении требований - так называемые

"лучшие практики", широко используемые в настоящее время в бизнес-консалтинге и при внедрении корпоративных информационных систем. Лучшие практики представляют собой описания моделей деятельности успешных компаний отрасли, используемые длительное время в сотнях и тысячах компаний по всему миру. Но следует помнить, что это лишь один из источников и то, что хорошо «немцу» – смерть русскому.
  Чтобы данные для проектирования АИС поступили "на вход", аналитики требований должны проделать немалую работу, связанную с выбором респондентов, информационных материалов и т.д.
Слайд 89

Стратегии выявления требований Интервью (Использование техники интервью) Ключевой стратегией выявления требований

Стратегии выявления требований
Интервью (Использование техники интервью)
Ключевой стратегией выявления требований было и

остается интервью с экспертами.
Интервьюирование – это беседа представителя разработчика и заинтересованного лица. Применяется в случае, когда большим объемом знаний обладает ограниченных круг людей. Обычно используется для беседы с одним человеком. Метод используется в том случае, когда нереально собрать несколько ключевых пользователей одновременно в одном месте. Опасность применения метода заключается в том, что могут быть опрошены не все заинтересованные лица, и разработчики могут упустить ключевую информацию.
Слайд 90

Классификация методов интервью Свобода выбора ответа Свобода формулировки вопроса min max

Классификация методов интервью

Свобода выбора ответа

Свобода формулировки вопроса

min

max

max

1

2

3

4

5

Клиническое интервью

Свободное интервью

Направленное интервью

Интервью с

фиксированными вопросами
Слайд 91

Анкетирование Анкетирование - самый малозатратный для аналитика способ извлечения информации, он

Анкетирование
Анкетирование - самый малозатратный для аналитика способ извлечения информации, он же

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

Наблюдение Наблюдение за работой моделируемой организационной системы (ОС) - полезная стратегия

Наблюдение
Наблюдение за работой моделируемой организационной системы (ОС) - полезная стратегия получения

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

Самостоятельное описание требований Документы - хороший источник информации, потому что они

Самостоятельное описание требований
Документы - хороший источник информации, потому что они чаще

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

Совместные семинары Это стратегия, предполагающая широкое участие представителей Заказчика и Исполнителя.

Совместные семинары
Это стратегия, предполагающая широкое участие представителей Заказчика и Исполнителя.
Мозговой штурм – заключается

в обсуждении требований и записи всего, что будет высказано. Метод удобен, когда обсуждаются нестандартные решения незнакомой проблемы. Большинство хороших идей часто бывают результатом комбинации нескольких, на первый взгляд не связанных.
Совместная разработка приложений (joint application design (JAD-совещание)) – метод заключается в том, чтобы собрать всех заинтересованных лиц в одной комнате на день-два для интенсивной работы по идентификации требований их документированию и назначению приоритетов. Метод позволяет значительно сократить время опроса пользователей по отдельности, но требует высокой квалификации того, кто ведет JAD-совещание.
Слайд 95

Прототипирование Создание прототипов – создание скелета системы – прототипа, который позволяет

Прототипирование
Создание прототипов – создание скелета системы – прототипа, который позволяет предметно обсуждать

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

Сценарии и ролевые игры Метод заключается в создании легко модифицируемого схематичного

Сценарии и ролевые игры
Метод заключается в создании легко модифицируемого схематичного сценария

работы системы (не прототипа), который обсуждается с пользователем. Метод направлен на поиск акторов, участвующих в работе системы и получения от будущих пользователей обратной связи, например по вопросам интерфейса или по вопросам «что будет если...».
Для ролевых игр могут использоваться доски, простые листы бумаги или даже интерактивные сценарии, главное, чтобы пользователь понимал, как происходит взаимодействие с системой.
Сценарии особенно полезны в случае, когда в систему включены новые функции, плохо поняты требования, не определены акторы и варианты использования. Они также позволяют обсудить пользовательский интерфейс, не прибегая к трудоемкому созданию прототипов.
Слайд 97

Маркетинговые исследования (4Р: продукт, цена, место, продвижение) Эти методы особенно эффективны,

Маркетинговые исследования
(4Р: продукт, цена, место, продвижение)
Эти методы особенно эффективны, если вы

чётко понимаете - какую информацию вы хотите получить с их помощью. Для этого необходимо ответить на 2 вопроса:
1) Нужно ли вам знать, как ведут себя пользователи, когда они взаимодействуют с какой- то конкретной функцией продукта?
2) Хотим ли вы выяснить, почему они ведут себя именно так?
Чем четче вы опишите свои интересы, тем легче будет сформулировать вопросы, направленные на получение нужной информации.
(Владение техникой вопросов: Зачем? Когда? О чем? Каким образом? Техника интервью.)
Слайд 98

Исследование контекста Контекстуальное исследование - это набор методов по изучению контекста

Исследование контекста
Контекстуальное исследование - это набор методов по изучению контекста возникающего

в жизни пользователя. (Контекст повседневной жизни, контекст организации, контекст рабочего места (задачи)).
В основе инструментария лежат методы, применяемые при изучении культур и сообществ. (Более 100 вариантов определения понятия)
Недостатками контекстуального исследования являются высокая стоимость и большие затраты времени. При наличии ресурсов и требования глубокого знания пользовательской аудитории, контекстуальное исследование дает знание тонкостей пользовательского поведения.
Анализ задач.
В его основе лежит идея о том, что любое взаимодействие пользователя с продуктом (например, сайтом) происходит в контексте некоторой задачи, решаемой пользователем. Иногда это очень узкая задача, иногда широкая, хорошо структурированная или плохо и т.д..
Анализ задач является методом подробного изучения шагов, предпринимаемых пользователями при решении своих задач. Само изучение проводится с помощью интервью, либо с помощью непосредственных наблюдений за пользователями в его естественной среде обитания (метод наблюдения).
Слайд 99

Анализ рабочих заданий Анализ рабочих заданий - набор методов, использующих анкетирование

Анализ рабочих заданий
Анализ рабочих заданий - набор методов, использующих анкетирование или

интервью для формирования детального представления о том, как люди в настоящий момент выполняют конкретные задания.
В таком исследовании наиболее интересны следующие вопросы:
стоящая за заданием реальная цель — для чего пользователь выполняет задания;
частота и важность выполнения задания;
триггеры - что служит поводом или сигналом для выполнения задания;
зависимости - что требуется для выполнения задания и что зависит от его выполнения;
люди, которые вовлечены в выполнение задания, их роли и зоны ответственности;
конкретные действия, которые требуется выполнить;
решения, которые необходимо принять;
информация, которая нужна для принятия решений;
ошибки и исключительные ситуации — что может пойти не так;
способы исправления ошибок и обработки исключений.
После заполнения анкеты или проведены интервью, выполняются формальная декомпозиция и анализ рабочих заданий при помощи диаграммы потоков (кросс-функциональной диаграммы) или сходной диаграммы
Слайд 100

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

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

от целевой аудитории, особенностей разрабатываемого продукта и других факторов.
Суть метода - всю массу пользовательских потребностей разбиваем на части путем сегментирования пользовательской аудитории. Деление на группы происходит с помощью выделения сходных ключевых характеристик представителей каждой группы пользователей. На первых этапах сегментирования обычно получается большое количество групп, но в процессе определения приоритетов некоторые группы объединяются. В результате получается 3–4 основные целевые группы.
Для того чтобы лучше понять, какие цели преследуют пользователи необходимо сделать пользователей более конкретными. Для этого следует персонифицировать типичных представителей каждой группы целевой группы. (Метод персонажей).
Слайд 101

Метод персонажей (метод вербализованных представителей) Персонажи - модели пользователей, создаваемые посредством


Метод персонажей (метод вербализованных представителей)
Персонажи - модели пользователей, создаваемые посредством

описания некоторых вымышленных представителей, наиболее точно соответствующих ключевым характеристикам целевой аудитории, а не описания реальных людей, входящих в целевую аудиторию.
Персонажи обычно «рождаются» на стадии проектирования сайта (товара, услуги), а на последующих стадиях живут и развиваются. Придавая облик и имя разрозненным элементам данных, полученным в результате исследования и сегментации пользовательской аудитории, персонажи помогают постоянно помнить о пользователях в ходе работы над проектом.
Для наиболее чёткого представления основных приоритетов в дальнейшем процессе разработки имеет смысл сегментировать аудиторию потенциальных пользователей по группам (персонажи первого плана, второго плана и т.д.).
Каждая отдельная группа пользователей преследует свои цели и интересы, которые могут быть как совершенно не похожи на цели других групп, так и переплетаться с ними.
Слайд 102

Персонажи - не реальные люди, но они представляют реальных людей в

Персонажи - не реальные люди, но они представляют реальных людей в

процессе проектирования. Это гипотетические архетипы реальных пользователей, поэтому будучи воображаемыми, они определяются достаточно жестко и точно.
На практике мы обнаруживаем их в процессе исследования, а не «выдумываем» их.
Но мы действительно выдумываем их имена и личные сведения.
Персонажи являются наиболее значимыми объектами для моделирования.
Персонажи основаны на исследованных образцах поведения и целях пользователей.
Персонажи обобщают в себе нужды многих людей.
Понимание нужд и целей одного пользователя помогает удовлетворить других людей, имеющих такие же цели.
Слайд 103

«Матери» нужна безопасная, надежная машина, просторная, с большими дверями, для перевозки

«Матери» нужна безопасная, надежная машина, просторная, с большими дверями, для перевозки

детей, собаки, пакетов с покупками и т. д.
«Отцу» – нужен крепкий полноприводный пикап, достаточно большой, чтобы в него поместились лестницы, материалы, мешки с цементом и ящики с инструментами.
«Сыну» - руководящему работнику - нужна машина спортивного типа с мощным двигателем, жесткой подвеской, откидным верхом. Места в машине должно хватать только на двоих.

Пример 1:
Что мы получим, если будем проектировать автомобиль, удовлетворяющий всех возможных водителей –членов семьи?
Рассмотрим запросы пользователей:

Плохое решение!

Машина, включающая в себя все запросы от всех пользователей.

Слайд 104

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

Проектируем для одного персонажа

Выполнить запросы каждой категории пользователей.
Люди с аналогичными целями

так же будут удовлетворены одной из моделей.

Отличное решение!

Отличное решение!

Отличное решение!

Слайд 105

Контрольные листы (Checklists) Контрольные листы помогают удостовериться в том, что веб-сайт

Контрольные листы (Checklists)
Контрольные листы помогают удостовериться в том, что веб-сайт выполнен

с учетом принципов функциональности дизайна. Обычно их используют на заключительной стадии работы в дополнение к экспертным методам для того, чтобы структурировать экспертные оценки по каким-то определенным признакам.
Существует большое количество готовых контрольных листов, однако решение об использовании того или иного списка должно зависеть от задач исследования. Зачастую возникает необходимость в разработке собственных критериев качества в определенной области.
Подробности: Jan Alexander and Marsha Tate. Evaluating Web Resources. http://www.science.widener.edu/~withers/webeval.htm
Слайд 106

Плюралистическая проработка (Pluralistic Walkthroughs) Плюралистическая проработка проводится большой по размеру группой,

Плюралистическая проработка (Pluralistic Walkthroughs)
Плюралистическая проработка проводится большой по размеру группой, в

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

Протоколы самоотчета (Self-Reporting Logs) Протоколы самоотчета это бланки типа «карандаш-бумага», в

Протоколы самоотчета (Self-Reporting Logs)
Протоколы самоотчета это бланки типа «карандаш-бумага», в которых

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

Фиксация «мыслей вслух» (Thinking Aloud Protocol) Это одна из самых популярных

Фиксация «мыслей вслух» (Thinking Aloud Protocol)
Это одна из самых популярных техник

при оценке функциональности веб-сайта. Пользователя просят произносить вслух все мысли, чувства и представления, которые у него возникают в процессе решения задачи.
Пользователя обеспечивают доступом к тестируемому веб-сайту или его прототипу и дают ему задание, которое он должен реализовать в процессе его эксплуатации. Его задача – выполнять задачу, одновременно «озвучивая» все, что приходит в голову по поводу интерфейса. Ведется аудиозапись данных или данные фиксируются письменно. Техника позволяет оценить непосредственные реакции пользователя на взаимодействие с отдельными компонентами веб-сайта, не отсроченные по времени. Если его ожидания в отношении необходимых для решения задачи операций расходятся с дизайнерским решением веб-сайта, то следует это учесть.
Основной задачей техники является выяснение пользовательских представлений, но с ее помощью можно реализовывать и другие цели. Например, терминология, которую употребляет пользователь для обозначения тех или иных элементов интерфейса, может быть использована в дизайне веб-сайта.
Метод предполагает обобщение данных, полученных от нескольких пользователей.
Слайд 109

Фокус-группы (Focus Groups) Метод фокус-групп заключается в опросе специально отобранной группы

Фокус-группы (Focus Groups)
Метод фокус-групп заключается в опросе специально отобранной группы пользователей.

В исследование, которое обычно продолжается около 2 часов, вовлекается от 6 до 9 пользователей. Фокус-групп ы позволяют выявлять спонтанные реакции и идеи и оценивать отношение к этим идеям группы в целом.
Как правило, участники группы воспринимают происходящее как относительно свободный неструктурированный процесс, но ведущий группы должен иметь предварительный сценарий работы, вытекающий из целей исследования, и следить, чтобы групповая дискуссия не выходила из русла обсуждаемой проблемы. Кроме того, необходимо добиваться равного участия в дискуссии всех членов группы.
Результаты работы фокусной группы фиксируются. Рекомендуется проводить несколько фокус-групп, состоящих из репрезентативных пользователей.
Фокус-группы имеют и свои недостатки. Главным из них является неточность оценки, основанной на утверждениях, мнениях и предпочтениях небольшого количества пользователей. Поэтому при оценке веб-сайта фокус-группы должны использоваться лишь наряду с другими методами.
Фокус-группы могут использоваться как на любой стадии разработки веб-сайта, так и для оценки готового продукта.
Подробности: Jacob Nielsen.The Use and Misuse of Focus Groups. http://www.useit.com/papers/focusgroups.html
Слайд 110

Эвристическое исследование (Heuristic Evaluation) Эвристическое исследование проводится группой из 4-6 профессионалов

Эвристическое исследование (Heuristic Evaluation)
Эвристическое исследование проводится группой из 4-6 профессионалов в

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

Экспертиза компонентов (Feature Inspection) Экспертиза компонентов предназначена для анализа конкретного набора

Экспертиза компонентов (Feature Inspection)
Экспертиза компонентов предназначена для анализа конкретного набора признаков

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

Экспертиза – это система организационных, логических, математико-статистических процедур, направленных на получение

Экспертиза – это система организационных, логических, математико-статистических процедур, направленных на получение

от специалистов информации и ее анализ с целью выработки решений
Слайд 113

Подходы, основанные на экспертных оценках, применяются при отсутствии дискретных эмпирических данных.

Подходы, основанные на экспертных оценках, применяются при отсутствии дискретных эмпирических данных.
Характеристики

метода:
решение задачи основано на суждениях экспертов – специально отобранных специалистов ( от латинского expertus- опытный);
Результат решения задачи состоит в получении новой информации;
Суждения экспертов базируются на их опыте и интуиции, а не на результатах расчетов или экспериментов.
Слайд 114

Групповая экспертиза Метод основывается на следующих предположениях: эксперт обладает большим объемом

Групповая экспертиза

Метод основывается на следующих предположениях:
эксперт обладает большим объемом рационально

обработанной информации, и потому его можно рассматривать как качественный источник информации (модель или инструмент);
групповое мнение экспертов близко к истинному значению оцениваемых параметров объекта;
для построения процедур опроса и алгоритмов обработки экспертной информации можно использовать модели теории измерений и математической статистики (имитационного моделирования).
Слайд 115

Приборная концепция экспертизы Оценка эксперта понимается как результат измерения конкретным прибором.

Приборная концепция экспертизы
Оценка эксперта понимается как результат измерения конкретным прибором.
Проблемы:
Качество прибора.
Выбор

подходящего для исследования прибора.
Организация процесса измерения.
Что измерять? Что уже свершилось? Что может свершиться? Процесс. Результат процесса. Задача экспертизы.

Исследуемое явление

«Прибор» 1

«Прибор» 2

«Прибор» N

Массив данных (результаты измерения)

Формальная процедура анализа данных.
Принятие решения.

Слайд 116

Модельная концепция экспертизы Эксперт рассматривается как модель исследуемого явления (объекта). По-определению:

Модельная концепция экспертизы
Эксперт рассматривается как модель исследуемого явления (объекта). По-определению: «А»

является моделью «В», если «А» отвечает на вопросы относительно «В» с заданной точностью
Проблемы:
Качество модели.
Выбор подходящего для исследования модели.
Организация процесса моделирования. Эксперимент с моделью.
Задача экспертизы.

Исследуемое явление

«Модель» 1

«Модель» 2

«Модель» N

Массив данных (результаты моделирования)

Формальная или неформальная процедура анализа результатов.
Принятие решения.

Слайд 117

Слайд 118

Задачи экспертизы Нетрадиционные задачи экспертизы. Они предполагают: Написание сценариев будущих явлений.

Задачи экспертизы
Нетрадиционные задачи экспертизы. Они предполагают:
Написание сценариев будущих явлений.
Создание новых объектов.
Построение

«дерева целей».
Назначение вероятностей свершения каких-либо событий.
Выявление характеристик какого-либо процесса.
Традиционные задачи экспертизы. Они предполагают использование заданных шкал измерения при оценивании заданных свойств или объектов.
Задачи количественной оценки объектов по определенному критерию.
Задачи упорядочения объектов.
Задачи классификации объектов: на заданное число классов; свободная классификация.
Слайд 119

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

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

«снежного кома».
Оценка компетентности кандидатов в эксперты. Два подхода к решению задачи оценки:
Априорный – оценка до начала экспертизы. Методы оценки кандидатов: документальный, самооценки, взаимной оценки, судейский, тестовый.
Апостериорный – определение компетентности кандидатов по результатам экспертиз. Применяется в случае проведения серии однотипных экспертиз. Накапливается результаты и происходит отсев участников экспертизы.
Формирование экспертной группы. Нет общих принципов отбора и решения по количеству. Много влияющих факторов: результаты переговоров, согласие, стоимость и т.д.
Слайд 120

Требования к экспертам Компетентность. Характеризуется источниками информации (знаний) эксперта: собственный опыт,

Требования к экспертам
Компетентность. Характеризуется источниками информации (знаний) эксперта: собственный опыт, чужой

опыт, теоретические знания.
Креативность – способность решать творческие задачи.
Отношение к экспертизе. При негативном или пассивном отношении будет мало толку от эксперта.
Конформизм – подверженность влиянию авторитетов или мнению большинства.
Конструктивность мышления – прагматический аспект мышления, т.е. учет реальных условий решаемой проблемы.
Всесторонность (системность) – способность видеть проблему с различных точек зрения.
Самокритичность – способность воспринимать и принимать аргументы других.
Слайд 121

Классификатор процедур получения экспертной информации (экспертный опрос)

Классификатор процедур получения экспертной информации
(экспертный опрос)

Слайд 122

Метод Дельфи

Метод Дельфи

Слайд 123

Анализ экспертной информации Этап 1. Анализ индивидуальных суждений экспертов. Противоречивость суждений

Анализ экспертной информации
Этап 1. Анализ индивидуальных суждений экспертов. Противоречивость суждений (транзитивность).

Не все суждения можно проверить (количественные шкалы, классификации).
Этап 2. Анализ совокупности суждений с целью понимания взаимного расположения мнений экспертов. Варианты: 1) все суждения близки, т.е. одна группа; 2) есть несколько групп в которых суждения близки; 3) большое число групп суждений (плохо поставлена задача, низкая компетентность).
Этап 3. Агрегация экспертных суждений (оценок) с целью получения итогового заключения по экспертизе: для варианта 1 - одно итоговое суждение; для варианта 2 - агрегация по каждой группе.
Статистический подход к агрегации основан на предположении о том, что существует единственное верное суждение, а суждение каждого эксперта – это случайная реализация этого суждения. Суждения – это независимые испытания (см. концепции экспертиз 1 и 2).
Дискретный (алгебраический подход): все суждения равноправны. Нет истинного. Следует найти компромисс. Вводится расстояние между суждениями (см. многомерное шкалирование).
Слайд 124

Опрос Опрос – это вопросно-ответный способ сбора данных, при котором источником

Опрос
Опрос – это вопросно-ответный способ сбора данных, при котором источником информации

выступает словесное сообщение, формулируемое человеком. Это инструмент сбора данных, не доступных прямому наблюдению.
Разновидности опроса:
Анкетирование – опосредованный, письменный опрос.
Интервью – способ научного исследования, который использует процесс вербального общения.
Экспертный опрос- опрос компетентных лиц.
Социометрический опрос – опрос, с целью выявления социально-психологических проявлений межличностных отношений.
- Предыдущая
Восточно-европейская (русская) равнина
Следующая -
Происхождение Первой мировой войны

Похожие презентации

Оперативная память
Прикладные программы
создание модели детали по чертежу в программе автоматизированного проектирования КОМПАС-3D LT
Информационная разминка
Издательская система PageMaker
Базы данных
Компьютерная графика. Цвет. Цветовая модель CMYК. Характеристики цвета. Гармония цвета
Презентация "Знакомство со средой ЛогоМиры" - скачать презентации по Информатике
Презентация на тему «Устройство компьютера» Ученицы 9 класса «А» ГОУСОШ 867 Сафоновой Яны
Фізичні поля та їх характеристики
Годовой отчёт Приморского отделения Лиги юных журналистов
Використання веб-браузера
Python. Ввод-вывод. Типы данных
«Действия с информацией» (урок – игра)
Безопасный интернет (онлайн - игра)
Урок 26 8 класс
Функции в электронных таблицах
Условный оператор Автор: Облицова Татьяна Александровна, учитель информатики МБОУ СОШ № 6, г.Боготол, Красноярский край
ФАЙЛОВАЯ СИСТЕМА – хаос или порядок?
Системные блоки
Презентация "АСУ в медицине " - скачать презентации по Информатике
Основы HTML
Презентация по информатике Графический интерфейс операционных систем и приложений
Автоматизация отопления
UDP сокеты. Протокол пользовательских дейтаграмм(UDP)
Фонд социального страхования РФ. Буклет для страхователя по госуслугам
Поиск подстрок
Разработка АСОИ учёта основных средств завода «Электродвигатель»
Вы можете прислать нам Вашу презентацию и мы опубликуем ее на сайте.
Обратная связь
Для правообладателей
Email: Нажмите что бы посмотреть