Последующий анализ

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

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

• Снизить время на задачу.

• Повысить пользовательскую удовлетворенность.

• Снизить количество обращений за помощью.

• Уменьшить количество отчетов по проблемам.

• Снизить уровень серьезности проблем.

• Увеличить количество положительных замечаний.

• Уменьшить количество отрицательных замечаний.

• Повысить уровень предпочтительности по отношению к конкурирующим продуктам.

Пример ожидаемого результата для времени на задачу показан на рис. 15.3 (затраты времени на задачу уменьшились между итерациями 1 и 2). Другие результаты можно изобразить аналогичным способом.

Инженерные изменения. Функциональные возможности, не удовлетво­ряющие критериям или непопулярные среди пользователей, требуют коррекции. Из­менения следует вносить помалу, постепенно наращивая их объем. Быстро произво­дятся изменения для насущных нужд и для последующей оценки. Преобразования, требующие больших затрат на разработку, должны пройти через этап перепланиро­вания.

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

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

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

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

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

Это также относится к облегчению изучения и понимания продукта.

SAFCO-факторы. Рассматривая FUPRID-факторы, мысленно возвратитесь к перечню проблем, используя принципы проектирования SAPCO. Пришло время за­давать вопросы, касающиеся решений.

Как можно сделать продукт более простым?

• Что пользователю необходимо знать и необходимо делать, чтобы применять продукт эффективно?

• Как можно сделать ПИ интуитивно более понятным и само документируемым?

• Как сделать боле ясными отклики, касающиеся положения дел?

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

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

Как можно сделать продукт более эстетичным?

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

• Как можно эффективно использовать выравнивание, интервалы, цвет и шрифты?

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

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

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

• Существуют ли какие-либо экраны и рабочие операции, которые можно объединить или исключить?

• Как можно использовать методы введения параметров, устанавливаемых по умолчанию, и запоминание предыдущей информации, введенной пользова­телем?

• В достаточном ли объеме реализованы функциональные возможности для прикладной области и ПИ?

• Отличается ли продукт достаточным уровнем быстродействия и надежности?

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

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

• Достаточно ли встроенной в продукт гибкости для его приспособления к различным пользовательским предпочтениям в отношении стилей компоновки и взаимодействия?

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

Каким образом продукт мог бы удовлетворить ожидания пользователей в отноше­нии других возможностей ПИ-ориентированного приложения?

• Достаточно ли приложение терпимо к ошибкам пользователей?

• Как можно применить к продукту методы непосредственного манипулирования и непосредственного ввода?

• Достаточно ли точна и понятна поддерживающая документация?

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

Пример подобной проблематичной компоненты — кнопка счетчика. Исследования показали, что около половины пользователей-новичков щелкают на символе "стрелка вверх" для увеличения отображаемого значения, а другая половина использует символ "стрелка вниз" для выполнения той же операции. Вероятно, пользователи ведут себя подобным образом, потому что такова их пользовательская модель, описывающая по­ведение кнопки в контексте интегрированного использования с другими компонен­тами ПИ (например, полосами прокрутки полей и окон). Некоторые пользователи полагают, что копка "стрелка вверх" должна увеличивать значение, в то время как другие пользователи уверены, что это должна делать копка "стрелка вниз". Исходя из подобной тенденции пользовательского поведения, проектная бригада должна рас­смотреть вопрос о том, насколько уместно интенсивное использование данной ком­поненты в приложении, и в каких ситуациях.

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

• Предполагаемая пользовательская модель.

• Терминология, пиктограммы и битовые образы.

• Объекты и действия.

• Диалоги и шаги взаимодействия.

• Использование устройств.

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

Полезное правило. Если элементы SAPCO вас не удовлетворяют, очередь мо­жет быть за исправлениями.

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

А теперь, сделайте это! Альтернативы, обладающие наилучшей общей сба­лансированностью, выбираются и применяются к продукту. Цикл повторяется до тех пор, пока требования не будут удовлетворены.