11)Варианты использования. User cases.

На этом этапе у нас есть

-Пользователи (актеры, персоны) и их конкретные User Story.

-Требования к системе в виде большого списка.

-Дополнительная информация (желания заказчика) о системе в виде MindMap.

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

(описать свой юскейс!назвать из него пункты)

Диаграмма прецедентов или Use Case Diagram На диаграмме прецедентов контекст модели прецедентов изображается в виде блока с именем контекста. В нашем случае для каждого актера должна быть своя диаграмма: Варианты художественного представления.

Идентификация прецедентов Чтобы найти прецедент, надо спросить: «Как каждый из актеров использует систему?» и «Что система делает для каждого актера?» Каждому прецеденту должно быть присвоено короткое описательное имя, представляющее собой глагольную группу, прецедент означает «выполнить» что-нибудь!. ­­Ниже приводится полезный список вопросов, которые можно задавать при идентификации прецедентов.

Какие функциональные возможности понадобятся конкретному актеру от системы?

Система сохраняет и извлекает информацию? Если да, какой из актеров инициирует это поведение?

Что происходит, когда система изменяет состояние? Кто-нибудь из актеров получает при этом уведомление?

Какие-либо внешние события оказывают влияние на систему? Как система узнает об этих событиях?

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

Устанавливаются границы потенциальной системы.

Выявляются актеры.

Выявляются прецеденты:

определяется прецедент;

устанавливаются основные альтернативные потоки.

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

Обычно начинают с самой общей оценки границ системы(сайта), чтобы обозначить область моделирования. Затем все действия осуществляются итеративно и зачастую параллельно. Прецеденты - способ записи требований. Результат этой деятельности - модель прецедентов. В этой модели четыре компонента:

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

Актеры - роли, выполняемые людьми или сущностями, использующими систему.

Прецеденты — то, что актеры могут делать с системой.

Отношения — значимые отношения между актерами и прецедентами.

12)Протопитирование.

Различают четыре версии прототипа:

-бумажная

-презентационная

-псевдореальная

-реальная

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

Презентационная версия прототипа. После того как исчерпаны возможности бумажной версии прототипа, стоит создать новую версию. Для этого точно так же рисуется интерфейс, но уже не на бумаге, а в какой-либо презентационной программе. С этой версией прототипа можно тестировать значительно более сложное взаимодействие человека с системой, нежели с бумажной. В то же время исправлять ошибки значительно труднее. Такая версия прототипа может создаваться уже на этапе высокоуровневого проектирования, но на этапе низкоуровневого проектирования ПИ она обязательна. Достаточно распространенными инструментами для создания прототипов этого вида являются на сегодняшний день МS PowerPoint и МS Visio. Однако дизайнеру привычнее работать в графических редакторах. Так что милости прошу: PhotoShop, Illustator и иже с ними. Можно сформулировать некоторые требования к протопиту: 1. Для тестирования прототипа на пользователях крайне желательно, чтобы он хоть немного работал, т.е. нажатие на кнопку вызывало другое окно или из выпадающего списка можно было выбрать значение. 2. Если в вашем интерфейсе планируется принципиально новый элемент, то его необходимо прототипировать. 3. Не стоит увлекаться детализацией прототипа, для прототипирования требуются лишь настройки внешнего вида — шрифт, цвет, текст, размер. 4. Для Web проектов есть смысл прототипировать в том виде, в котором будет реальное использование. Т.е. с помощью HTML, если сайт будет HTML или flash, если сайт планируется с использованием этой технологии. Для прототипирования использовалась програма - AxureRP-Pro-Setup.exe Псевдореальная версия прототипа. В тех случаях, когда в интерфейсе появляются нестандартные элементы или необходимо проверить реальную скорость взаимодействия пользователя с системой, создается еще одна версия прототипа — реально выглядящая, но лишенная каких-либо алгоритмов и, соответственно, не показывающая реальных данных. Делать этот вариант можно как в средах разработки, благо в них есть визуальные инструменты создания интерфейсов, так и в редакторах изображений, что обычно быстрее. Фактически при этом создаются фальшивые снимки экрана, на которых и производят тестирование. Понятно, что как-то модифицировать эти экраны затруднительно, так что лучше не увлекаться такой работой, не получив каких-либо гарантий ее правильности. Эта версия прототипа больше соответствует этапу низкоуровневой разработки ПИ, но может применяться и на этапе высокоуровневой разработки. Реальная версия прототипа. Иногда необходимо тестировать взаимодействие пользователя не только с интерфейсом системы, но и с обрабатываемыми системой данными. Например, работая с графической программой, пользователь не только нажимает на экранные кнопки, но также создает и модифицирует изображения мышью. Область же редактирования данных зачастую вообще не содержит каких-либо визуальных интерфейсных элементов, из чего вовсе не следует, что интерфейса в ней нет, его, наоборот, много. Просто счет в нем идет не на кнопки и переключатели, а на пиксели и миллисекунды. Понятно, что прототип в таких условиях практически не будет отличаться от готового ПИ. Поэтому лучше всего написать нужные участки программы до создания всего остального и проводить юзабилити-тестирование на реальной версии прототипа ПИ. Разумеется, прототип такой версии, если он все-таки разрабатывается, возможен только на этапе низкоуровневого проектирования.