53. Проектирование гип. Обзор основных этапов разработки.

В процессе разработки ГИ можно выделить 3 основных этапа:

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

2. Создание прототипа.

3. Тестирование и модификация прототипа.

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

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

Для проектирования вам понадобится следующий инструментарий:

1. Ручка

2. Бумага

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

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

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

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

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

Проектирование состоит из следующих этапов:

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

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

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

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

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

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

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

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

Традиционно требования функциональности исходят от отдела продаж. Они имеют 2 источника: жалобы клиентов и функциональность конкурентов.

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

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

Анализ целей пользователя.

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

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

Анализ действий пользователя.

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

Низкоуровневая и высокоуровневая функция.

Существует 2 подхода к функциональности системы:

1. Функциональность состоит из минимальных (атомарных) функций

2. Добавляются еще и метафункции, построенные на основе атомарных.