Книга: Программное обеспечение и его разработка

Устойчивые программы, или программы, дружественные пользователю

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

В тот момент, когда мы подключили людей к диалогу с вычислительной машиной (типы III, IV и V), задачи, стоявшие перед нами, значительно возросли. Мы должны писать теперь программы, которые могут давать людям возможность взаимодействовать — вести диалог с системой.

Я однажды работал с небольшой группой программистов — всего 7 человек, — занимавшейся созданием диалоговой программы по анализу многозначных решений. Программы писались на языке APL; их размер составлял 10 тыс. операторов языка APL — из них 9 тыс. операторов было написано для управления интерфейсом с человеком. Девять из десяти. Нам необходимо было сделать так, чтобы надежды пользователей оправдались, иначе нашей системой не стали бы пользоваться.

Если необходимо было ввести букву О, а пользователь набирал цифру 0 либо наоборот — мы не ограничивались тем, что сообщали «неверные данные на входе». Мы давали подсказки, чтобы помочь поддержать процесс активным. «Вы хотели ввести символ нуль или О?» — выдавали мы на экран.

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

Оглавление книги