Первоначальное проектирование

Включает в себя 7 этапов:

´ Определение необходимой функциональности системы

´ Прилив вдохновения J

´ Создание пользовательских сценариев

´ Проектирование общей структуры

´ Конструирование отдельных блоков

´ Создание глоссария

´ Сбор и начальная проверка полной схемы системы

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

Прилив вдохновения: чем раньше – тем лучше. Это когда из анализа, проведённого на первом этапе, разработчик начинает представлять, как это всё будет выглядеть, в каких цветах и т. д.

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

Елизавета Андреевна запускает почтовую программу, вручную скачивает из почтового ящика несколько писем, читает все сообщения, часть удаляет, на одно из них отвечает, а затем выключает программу.

Второй сценарий:

Еремей Карапетович делает активным окно уже открытой программы, скачивает все сообщения, одно сообщение пересылает другу, одно из них печатает, а затем переключается на другую задачу.

Третий сценарий:

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

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

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

Конструирование отдельных блоков – это создание всех экранов системы (экран – отдельное, отличающееся от других, визуальное состояние системы).

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

Для проектирования отдельных блоков можно использовать дополнительные вспомогательные методики. Например, методику GOMS (Goals, Operators, Methods and Selection rules – цели, операторы, методы и правила их выбора). Это метод оценки интерфейса, позволяющий быстро выбрать лучший по скорости работы пользователя вариант. Вот некоторые правила GOMS:

Действие	Затрачиваемое время
Нажатие на клавишу клавиатуры, включая Alt, Ctrl и Shift	0,28 сек
Нажатие на кнопку мыши	0,1 сек
Перемещение курсора мыши	1,1 сек
Взятие или бросание мыши	0,4 сек
Продолжительность выбора действия	1,2 сек
Время реакции системы	От 0,1 до бесконечности (для базовых операций, таких как работа с меню, это время можно не учитывать, т. к. с момента создания метода производительность компьютеров многократно возросла)

Для упрощения логики работы системы вместе с методикой GOMS используется адаптивная функциональность. Она делает работу пользователя более простой и естественной. На вопрос о том, как определить, какие фрагменты и функции системы должны быть адаптивными, может дать ответ только детальный анализ взаимодействия пользователей с системой. Помочь здесь может только тестирование интерфейса на пользователях. Примером адаптивной функциональности является, например, запрос о сохранении внесённых изменений при нажатии кнопки “Закрыть”. Другим примером может быть телевизионный пульт: выключить телевизор можно нажатием на одну кнопку, а включить можно разными способами – нажатием на кнопку номера канала, нажатием на кнопку переключения канала и т. д.

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

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

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

Правила экспертной оценки:

· Количество экспертов должно быть больше единицы (разные люди замечают разные ошибки)

· Лучше привлекать несколько экспертов не одновременно, а последовательно (один эксперт высказался о недостатках, мы недостатки исправили и пригласили уже другого эксперта, он сможет найти что-то новое)

· Чем больше информации о проектируемой системе будет предоставлено эксперту, тем глубже проблемы он сможет выявить

· Нельзя требовать от эксперта работы по весу или количеству (не надо требовать 10 страничный доклад по 1000 рублей за страницу – эксперт просто нальёт туда воду)

На следующей лекции рассматривается построение прототипа.

15.03.2012 Подготовка к лабораторной работе №1 и обсуждение контрольной работы

Темы для контрольной работы:

1. Офисные программы (Морозов и Билиенко)

2. Работа с векторной графикой

3. Работа с растровой графикой (Арсланов и Искандаров)

4. Работа с 3D-графикой (Жданов и Донцов)

5. Среды интегрированной разработки – IDE (Коноплёв и Хорольский)

6. Работа со звуком (Жуков)

Моя тема – сравнение программных пакетов работы с растровой графикой. Оптимальный выбор: сравнение пакетов Adobe Photoshop и GIMP.

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

Цель работы – провести сравнительный анализ нескольких программных пакетов по следующим пунктам:

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

2. Сравнение интерфейса – юзабилити

3. Сравнение поддерживаемых форматов

4. Платный пакет или бесплатный

5. Обязательно приложить субъективное мнение в отношении удобства работы

Итог работы: выступление с презентацией. Обязательна съёмка скриншотов. Можно снимать видео.