Глава 6. Основные требования, предъявляемые к программному продукту со стороны пользователя

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

Покупатель оценивает стоимость программной системы и трудоемкость ее освоения (Т):

3 = С + к Т,

где к – стоимость норма-часа специалиста, который осваивает программный продукт.

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

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

Например,

1) Текст – процессоры имеют в своем составе команду GLOBAL FORMAT, с помощью которой форматируют текст. При ее применении текст форматируется со вставленными в него таблицами. Таблицы, после применения такой команды превращаются в нечто, что не читается и практически не восстанавливается;

2) электронные таблицы (Spread Sheets): LOTOS 1-2-3, SUPERCALC, QUATTRO PRO, EXCEL, которые предоставляют программисту самые широкие возможности при создании продукта, которые передаются пользователю. Пользователь вынужден работать со всем инструментарием, который предоставляется и программисту. И это богатство возможностей часто играет с неквалифицированным пользователем скверную шутку. Например, при использовании команд типа: SORT или ARRANGE работа пользователя будет безнадежно испорчена. При этом, подобные команды выполняются электронной таблицей без лишних расспросов, к тому же, команда ARRANGE в меню стоит первой.

Недопустимо, чтобы продукт, явно ориентированный на пользователя, предъявлял к нему такие требования, которые затруднят и многих программистов. А также очень нежелательно, чтобы пользователю надо было бы освоить большое число команд (например, в редакторе их “всего” от 44 до 300 и более). В электронных таблицах, например, используется восьмиуровневое иерархическое меню, каждый уровень содержит до 20 команд, а общее их сочетание достигает 15 тыс.. Что делать пользователю (а также и программисту), если изрядная часть этих 15 тыс. команд приводит к фатальным последствиям?

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

Допустимость для пользователя программного продукта заключается в том, чтобы продукт НЕ потребовал от него.

1) высокого интеллекта;

2) тренированной памяти;

3) интеллектуальных усилий;

4) полного самоконтроля;

5) напряженного внимания;

6) трудолюбия и полной самоотдачи;

7) интенсивной работы с клавиатурой или мышью.

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

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

1) ввести данные неправильного типа или формата;

2) ввести данные не туда;

3) забыть сохранить файл данных;

4) сохранить файл данных так, что потом система его не найдет;

5) потерять, испортить, стереть файл;

6) дать неправильную команду (их просто не существует);

7) задать неверный режим;

8) потерять результаты;

9) получить результаты, непригодные для использования;

10) «подвесить» программу и многое, многое другое.

Более того у пользователя не должно возникать вопросов при работе с программной системой, поэтому нет необходимости в HELP-файлах, «горячих клавишах».

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

Рассмотрим некоторые положения этой технологии:

1) Алгоритмы ввода-вывода и обработки данных не должны содержать ветвящихся путей, тем более путей, выводящих на конец программы в обход ее основных блоков. Другими словами, его блок-схема должна представлять собой вытянутую одномерную структуру. Только такая структура дает гарантию того, что при любых действиях пользователя программа придет к благополучному результату. Если же программным путем разрешить движение только в одном направлении, а именно в направлении «успеха», то он будет достигнут еще быстрее.

2) Идеальный случай – программный продукт не содержит управляющих клавиш. Активны лишь алфавитно–цифровые клавиши, клавиши управления курсором, клавиша ENTER

3) Идеальный случай - программный продукт не содержит управляющих команд (никаких F10, CTRL+B, ALT+X, ESC). Управление вводом-выводом осуществляет сама программа с помощью встроенного в него Анализатора экрана.

В основу Анализатора экрана положен факт, что в каждый заданный момент ввода редактирование вывода состояния экрана и всей задачи уникально. Следовательно, не так трудно отследить момент, когда нужно произвести какие-либо действия и эмулировать необходимую команду без участия пользователя. В качестве критерия можно использовать, например, текущее положение курсора или заполненность определенного поля. Можно применять и менее очевидные критерии, например, состояние и содержание буферов и стеков. В сложных программных системах Анализатор контролирует содержимое экрана или программы до 18 раз в секунду и отслеживает одновременно до 50 различных состояний. Соответственно, в любой момент (но не одновременно) могут быть выполнены до 50 различных команд без какого-либо участия пользователя.

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

4) Диалог должен быть типа “Короткий вопрос - Короткий ответ” (SQSA). Например, если по мнению Анализатора, ввод исходных данных завершен, то на экране будет выведен следующий вопрос:

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

Вопрос должен быть предельно коротким и ясным, а из возможных ответов допустимы лишь ДА и НЕТ. Максимально возможное число выводимых подряд оконных микроменю не более трех. Программа, задающая свыше трех вопросов подряд, вызывает у пользователя раздражение.

5) Следует иметь только одно (главное) меню. Причем оно должно содержать 5-6 пунктов и быть одноуровневым. Если же после выбора пункта меню у программной системы останутся вопросы, то их можно уточнить позднее, в форме «Кратких вопросов» (SQSA). Оптимальным считается простейшее вертикальное меню типа NORTON, распложенное в центре экрана на нейтральном фоне. Меню не должно содержать функций удаления чего бы то не было. Удаление файлов, баз данных и так далее может производиться пользователем только после выхода из программной системы средствами MS-DOS.

6) Создание новых файлов должна выполнять программная система, а не пользователь. При этом ставить об этом в известность пользователя нет необходимости. И не в коем случае пользователь не должен присваивать файлу имя. Оптимальным вариантом является извлечение имени файла из какого-либо поля вводимых данных этого файла. Причем пользователь, вводя данные, не обязан знать, что одно из них станет именем файла. Разумеется, в программе следует предусмотреть защиту этого же поля от ввода символов, запрещенных операционной системой для имени файлов, а также ограничить размер записи.

Если программная система предусматривает выбор и загрузку одного из ранее созданных пользователем файлов, не желательно приводить в меню одни только их имена. К имени файла весьма уместен комментарий (приблизительно на 40-50 символов). Комментарий извлекается из какого-либо поля файла данных. Полезна также датировка.

Например,

G_KOLON	Деталь изделия ПМГ-10	12.05.92
G_RUCH	Деталь изделия Д-700	05.07.92
G_BAL	Деталь изделия ПМГ-10	01.11.12

Если пользователь не задает имени файла, то его присваивает система со специальными символами. Например, ## DDMMYY, где DD.MM.YY- показания системного таймера, а ## - порядковый номер сеанса или файла, созданного в указанный день. В этом случае меню выбора для пользователя выглядит так:

Сеанс 07 от 25 июня 1992 года

Сеанс 01 от 29 июня 1992 года

При выходе из системы файл должен быть сохранен автоматически.

7) Ввод данных должен проводиться по «по бумажному», т.е. экран полностью, до деталей, копирует знакомый пользователю бланк или документ. Следует стараться организовать экран так, чтобы в любой момент работы у пользователя не возникала необходимость произвести сложный скроллинг экрана. Иначе говоря, для ввода или получения справки он должен пользоваться только стрелками ”←“, ”→”, “↑”, “↓”.

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

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

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

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

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

Следует блокировать ненужные пользователю клавиши программным путем. Не должны влиять на ход вычислений случайные нажатия клавиш ESC, BREAKE и т.п.. В сложных системах следует применять динамическое (в зависимости от шага) блокирование клавиш.

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

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

Когда просмотр результата, по мнению Анализатора, закончен, то на экране можно вывести вопрос:

В случае НЕТ просмотр продолжается либо следует окончить сеанс. По окончании печати документов полезно повторить запрос, поскольку документы печатаются в нескольких экземплярах:

Результирующие файлы должны быть сохранены на диске, не ожидая указаний пользователя.

В программах вывода необходимо предусматривать все возможные сбои периферийного устройства вывода (типа PAGER OUT). Они не должны приводить к сбоям или зависаниям программной системы.

Технология создания программного продукта.

7) Виды памяти, модель внешней памяти, организация обмена данными между оперативной и внешней памятью.

8) Функции, принципы и способы построения ПО САПР и реализации в них типовых алгоритмов проектирования.

9) Этапы жизненного цикла программ.

10) Особенности технологии программирования сложных программных комплексов.