Практичность

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

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

♦ Эффективное использование системы. Каким образом система способствует повышению эффективности работы с ней?

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

♦ Адаптация системы к потребностям пользователя. Что может сделать пользователь (или система), чтобы выполнить его задачу стало проще?

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

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

Общие сценарии практичности

Пример сценария практичности приводится на рис. 4.8. «Пользователь, желающий свести к минимуму последствия допущенной ошибки, пытается отменить системную операцию в момент ее исполнения; отмена занимает менее одной секунды». Общие сценарии практичности состоят из следующих элементов.

♦ Источник стимула. В роли источника стимула всегда выступает конечный пользователь.

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

♦ Артефакт. Артефактом всегда является система.

ПРАКТИЧНОСТЬ: БЫЛИ НЕ ПРАВЫ, КАЕМСЯ

(ИЛИ «ЭТО НЕ ПО-АРХИТЕКТУРНОМУ»)

Примерно пять лет назад ряд уважаемых специалистов в области программной инженерии сделали весьма смелое публичное заявление:

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

К нашему несчастью, этих специалистов звали Басс, Клеменц и Кацман, а книга называлась «Архитектура программных систем: практическое пособие, 1-е издание». За пять последующих лет мы узнали много нового о разных атрибутах качества, но больше всего мы поднаторели в вопросах практичности.

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

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

К чему мы все это говорим? Утверждать, что тот или иной атрибут качества или ряд его аспектов носят неархитектурный характер, проще всего. Не все имеет отношение к архитектуре, это правда, однако довольно часто наши выводы по этому вопросу основываются на поверхностном анализе проблемы. Стоит копнуть чуть глубже, и свидетельства о связи с архитектурой не заставят себя долго ждать. И горе тому архитектору (равно как и авторам книг по архитектуре!), который их не заметит.

— RK

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

♦ Реакция. Система должна либо предоставлять пользователю все необходимые средства, либо уметь предвидеть его потребности. В нашем примере отмена операции производится по желанию пользователя, а система восстанавливается в предшествующем состоянии.

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

Варианты составления общих сценариев практичности представлены в табл. 4.6.