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

Тут очень важно избежать эгоцентризма. Очень трудно отказаться от мысли «если это нужно мне, это нужно и многим». Возможно, что и нужно. А возможно, что и нет. Единственным же способом проверить, нужна функция или нет, является наблюдение за пользователями и анализ их действий.

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

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

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

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

Сценарий взаимодействия пользователя с виртуальной библиотекой: «Пользователь открывает программу, выбирает книгу из каталога и начинает её чтение».

Сценарий взаимодействия администратора с программой: «Администратор открывает редактор, выбирает существующую книгу для редактирования или добавляет новую в список».

2. Высокоуровневое проектирование

2.1 Проектирование структуры экранов системы

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

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

Программное обеспечение «Виртуальная библиотека» будет состоять из двух частей: клиентской (Таблица 2.1) и администраторской (Таблица 2.2).

Таблица 2.1 - функциональные блоки клиентской части приложения.

Таблица 2.2 - функциональные блоки администраторской части приложения.

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

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

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

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

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

Процессуальная связь. Процессуальная связь описывает не вполне логичное, но естественное для имеющегося процесса взаимодействие. Установление качественной процессуальной связи обычно довольно трудная задача, поскольку единственным источником информации является наблюдение за пользователем. В то же время установление такой связи дело исключительно полезное. Зачем, например, рисовать на экране сложную систему навигации, если точно известно, к какому блоку пользователь перейдет дальше? В этом смысле зачастую оправдано навязывать пользователю какую-либо процессуальную связь, жертвуя удобством, зато выигрывая с скорости обучения (поскольку пользователю приходится думать меньше). Жестко заданная связь позволяет также уменьшить количество ошибок. Классическим примером жестко заданной процессуальной связи является устройство мастеров, при котором пользователя заставляют нажимать кнопку «Далее».

2.2 Проектирование навигационной системы

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

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

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

Навигация в программе будет осуществляться посредством мышки, путём нажатия на графические элементы - кнопки (для перехода между экранами).

2.3 Проектирование структуры справочной системы

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

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

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

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

3. Низкоуровневое проектирование

На данном этапе разрабатываются интерфейсы конкретных экранов системы (состав, взаимное расположение и поддерживающие текст интерфейсных элементов).

3.1 Проектирование экранов клиентской части

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

Чтобы упорядочить наименования книг по автору, достаточно нажать на заголовок столбца «Автор» (Рисунок 3.2). При этом вокруг элемента появится рамка. Всего доступно 3 группы сортировки: по автору, по названию книги и по жанру.

Наибольшее пространство в главной форме принадлежит списку книг (Рисунок 3.3), справа от которого расположена вертикальная полоса прокрутки, дающая возможность перемещаться по этому списку. Активный элемент (при наведении мышки) подсвечивается зелёным цветом.

Форма поиска (Рисунок 3.4) позволяет искать пользователю интересующие его книги по списку.

Экран информации о книге. Данный экран предоставляет краткую информацию о книге, такую как: название, автор, издательство и небольшое описание (Рисунок 3.5).

Внизу формы расположена пара кнопок. Кнопка «Читать» откроет содержание книги, а кнопка «Каталог» вернёт пользователя к списку литературы.

Экран содержания книги. На этомэкране отображается содержание книги (Рисунок 3.6). Навигация по нему осуществляется с помощью полосы вертикальной прокрутки.

Для более удобной навигации, на этой форме присутствует поле поиска. Чтобы вернуться обратно к списку литературы, следует нажать на кнопку «Каталог».

3.2 Проектирование экранов администраторской части

Основной экран. Основной экран администраторской части несильно отличается от экрана клиентской. Помимо уже упомянутых ранее элементов, на нём появилось пара новых (Рисунок 3.7).

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

Экран изменения и редактирования. На этом экране осуществляется заполнение информации о книге, перед её добавлением в таблицу или при изменении уже существующей (Рисунок 3.8).

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

3.3 Тестирование

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

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

После этого необходимо этот список улучшить. Для этого необходимо:

• уменьшить длину всех получившихся элементов;

• показать этот список любому потенциальному пользователю системы и спросить его, как она понимает каждый элемент. Если текст какого-то элемента воспринимается неправильно, его нужно заменить;

• уменьшить длину всех получившихся элементов;

• проверить, что одно и то же понятие не называется в разных местах по-разному;

• проверить текст на совпадение стиля с официальным для выбранной платформы (если вы делаете программу, эталоном является текст из MS Windows);

• уменьшить длину всех получившихся элементов;

• убедится, что на всех командных кнопках стоят глаголы-инфинитивы (Отменить, Удалить, Отправить).

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

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