Проектирование взаимодействия с пользователем

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

– минимизацией ошибок пользователя;

– обнаружением ошибок пользователя, когда они все же возникают;

– минимизацией сложности.

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

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

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

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

4. Обеспечивайте развитые средства помощи.

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

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

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

Основные правила обнаружения ошибок пользователя:

1. Спроектируйте систему так, чтобы она принимала любые данные. Если введенная информация не является тем, что системы считает допус­тимым, она должна информировать пользователя.

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

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

4. Там, где особенно важна аккуратность, обеспечьте избыточность входных данных: например, самопроверяемые счета в банковских систе­мах.

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

Вопрос, который всегда возникает при внешнем проектировании диалоговой системы, – подсказывать ли пользователю, в какой части вход­ного сообщения содержится ошибка. Предположим, что студент задал ве­роятность ошибки на символ, равную 10^–4, при кратности исправляемой ошибки 2.

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

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

До широкого распространения Delphi и С++ для научных и инже­нерных вычислений использовался язык ПЛ/1. Он содержал такой широ­кий набор синтаксических конструкций и встроенных функций, что, веро­ятно, не существует ни одного компилятора, поддерживающего все воз­можности этого языка. Простое перечисление всех вариантов вызова ком­пилятора занимало две страницы руководства для пользователей. В ре­зультате неопытный пользователь долго и мучительно пытался сообразить, как же откомпилировать его маленькую простейшую учебную программу. Вообще говоря, обилие дополнительных возможностей неблагоприятно сказывается на работе пользователя, подталкивая его к выбору по прин­ципу «скорее всего, так» и приводя к последствиям неправильного выбора. Разработчик должен тщательно рассмотреть каждую предоставляемую возможность, сопоставляя ее полезность и степень усложнения ПО. Когда имеются сомнения, безопаснее отказаться от рассматриваемого варианта. Множество доступных мелких возможностей не повысит конкурентоспо­собности продукта, а скорее всего, негативно повлияет на потенциального покупателя, показывая, что разработчик не имеет ясного представления о том, как именно его система будет использоваться.

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