ПрактичностьПрактичность выражает степень сложности выполнения пользователем стоящей перед ним задачи и тип реализованного в системе механизма помощи пользователю. У этого атрибута качества несколько сторон. ♦ Изучение возможностей системы. Каким образом можно облегчить задачу пользователя, связанную с изучением незнакомой системы или одного из ее аспектов? ♦ Эффективное использование системы. Каким образом система способствует повышению эффективности работы с ней? ♦ Минимизация последствий ошибок. Что система может сделать для того, чтобы ошибка, допущенная пользователем, не привела к серьезным последствиям? ♦ Адаптация системы к потребностям пользователя. Что может сделать пользователь (или система), чтобы выполнить его задачу стало проще? ♦ Доверие и удовлетворение пользователя. Как система может убедить пользователя в том, что он предпринял правильное действие? В последние пять лет активно изучались вопросы взаимосвязи между практичностью и программной архитектурой (см. врезку «Практичность: были не правы, каемся»). Как правило, проблемы, связанные с практичностью, в процессе разработки выявляются путем макетирования и пользовательского тестирования. Чем позже выявляется проблема и чем ниже в архитектурной иерархии находится ее решение, тем труднее, с точки зрения временных и финансовых ограничений, с ней разобраться. Излагая примеры сценариев, мы намерены сосредоточиться на тех аспектах практичности, которые в наибольшей степени влияют на характер архитектуры. Следовательно, в правильности составления этих сценариев необходимо убедиться еще до реализации архитектурного решения — в противном случае над этим придется работать в процессе пользовательского тестирования и макетирования. Общие сценарии практичности Пример сценария практичности приводится на рис. 4.8. «Пользователь, желающий свести к минимуму последствия допущенной ошибки, пытается отменить системную операцию в момент ее исполнения; отмена занимает менее одной секунды». Общие сценарии практичности состоят из следующих элементов. ♦ Источник стимула. В роли источника стимула всегда выступает конечный пользователь. ♦ Стимул. Стимул заключается в желании конечного пользователя добиться эффективного применения возможностей системы, изучить способы управления операциями системы, минимизировать последствия ошибок, адаптировать систему к выполнению стоящих перед ним задач или обеспечить удобство пользования системой. В нашем примере пользователь намерен отменить операцию — это один из вариантов минимизации последствий ошибок. ♦ Артефакт. Артефактом всегда является система.
ПРАКТИЧНОСТЬ: БЫЛИ НЕ ПРАВЫ, КАЕМСЯ (ИЛИ «ЭТО НЕ ПО-АРХИТЕКТУРНОМУ») Примерно пять лет назад ряд уважаемых специалистов в области программной инженерии сделали весьма смелое публичное заявление: Для того чтобы сделать пользовательский интерфейс четким и простым в применении, требуется тщательно наладить механизм взаимодействия пользователя с системой... «впрочем, эти вещи не имеют отношения к архитектуре». К нашему несчастью, этих специалистов звали Басс, Клеменц и Кацман, а книга называлась «Архитектура программных систем: практическое пособие, 1-е издание». За пять последующих лет мы узнали много нового о разных атрибутах качества, но больше всего мы поднаторели в вопросах практичности. Мы всегда утверждали, что качество системы напрямую зависит от качества архитектуры; впрочем, наша аргументация по этому поводу в первом издании временами страдала. Несмотря ни на что, за прошедшие пять лет не случилось ничего такого, что смогло бы поколебать нашу уверенность в жесткой взаимосвязи качества архитектуры и системы. Все свидетельства говорят в пользу этого утверждения, и практичность в этом смысле не исключение. Действительно, многие вопросы практичности завязаны на архитектуру. Более того — те характеристики практичности, реализовать которые труднее всего (в частности, те, которые почти нереально воплотить в жизнь после того, как система уже сконструирована), наиочевиднейшим образом демонстрируют связь с архитектурой. Если мы хотим, чтобы пользователь имел возможность прервать исполняемую операцию и, таким образом, вернуться к состоянию системы, зафиксированному до ее начала, мы должны прописать эту возможность в архитектуре. То же самое нужно сделать, чтобы позволить пользователю аннулировать результаты предыдущего действия или проинформировать его о состоянии текущей операции. Подобных примеров жуть как много. К чему мы все это говорим? Утверждать, что тот или иной атрибут качества или ряд его аспектов носят неархитектурный характер, проще всего. Не все имеет отношение к архитектуре, это правда, однако довольно часто наши выводы по этому вопросу основываются на поверхностном анализе проблемы. Стоит копнуть чуть глубже, и свидетельства о связи с архитектурой не заставят себя долго ждать. И горе тому архитектору (равно как и авторам книг по архитектуре!), который их не заметит. — RK ♦ Условия. Действия пользователя, имеющие отношение к практичности, всегда приходятся на периоды прогона или конфигурирования системы. Все действия, зафиксированные до наступления этих периодов, считаются произведенными разработчиками. Несмотря на то что пользователь и разработчик может оказаться одним и тем же лицом, мы всегда разделяем эти дне роли. В примере на рис. 4.8 отмена операции производится в период прогона. ♦ Реакция. Система должна либо предоставлять пользователю все необходимые средства, либо уметь предвидеть его потребности. В нашем примере отмена операции производится по желанию пользователя, а система восстанавливается в предшествующем состоянии. ♦ Количественная мера реакции. Реакция в данном случае измеряется продолжительностью выполнения задачи, количеством ошибок, количеством разрешенных проблем, степенью удовлетворения пользователя, повышением уровня знаний пользователя, процентным отношением успешно проведенных операций к общему числу операций, а также количеством времени/данных, потерянных из-за ошибки. Согласно примеру с рис. 4.8, отмена операции занимает не более одной секунды. Варианты составления общих сценариев практичности представлены в табл. 4.6.
|
