Записки парасистемного программиста

— Что тут непонятного? — Спросит любой програмист, в том числе и тот, который предложил такой великолепный способ исправления ошибок оператору подготовки данных, увы, этот программист забыл, что созданная им система нужна вовсе не программистам. В таком варианте она, скорее всего, не нужна никому, разве что переодетым в операторов подготовки данных создателям этого ППП. СОД может иметь несколько "подлиц", обращенных к различным категориям пользователей. Например, система подготовки данных с программным обеспечением типа генератора ввода может предполагать в качестве пользователей персонал подготовки данных с одной стороны и тех, кто эти данные приносит и желает иметь их в машинном виде, с другой стороны. Можно, конечно, отнести персонал подготовки данных и к обслуживающему систему персоналу, но, как правило, такие системы создаются не для тех, кому в конце концов все равно, каким образом "попадут в машину" их данные, а для облегчения работы и повышения производительности труда персонала подготовки данных. Если система предназначена для лиц, не являющихся профессиональными разработчиками других СОД, то есть, если сод находится на верхних уровнях иерархии СОД, то это ее лицо должно быть не сложнее передней панели телевизора.

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

Я думаю, что поставлено достаточное количество экспериментов, чтобы можно было определить эти границы, и не только для СОД, но и вообще для всех изделий — технических и организационных. Примером последней системы может служить, скажем, система хозяйственного законодательства. Второе лицо СОД обращено к обслуживающему ее персоналу. Для ОС — это мы, парасистемные программисты, для СУБД — это администратор баз данных, для АСУ "кадры", это группа ПО сопровождению задач на ВЦ и т. п. Если продолжить аналогию с телевизором, то обслуживающий его персонал — это мастер из телеателье. У телевизора это лицо находится сзади, а иногда и внутри — множество непонятных для непосвященного любителя штирлица кнопочек и ручек, подстроечных сопротивлений и конденсаторов, которые не имеющему дома даже тестера телезрителю лучше и не трогать.

Однако, механик из телеателье спит дома, а не на коврике, позади вашего телевизора, чего никак нельзя сказать про персонал, обслуживающий СОД. В данном случае его уместнее сравнивать с водителем такси. Итак, чем проще вам удастся сделать это второе лицо, тем больше шансов, что ваша система обретет жизнь. И, наконец, третье лицо СОД, повернуто к самому разработчику. Сюда относятся те параметры СОД, которые ни пользователь, ни обслуживающий персонал изменять не должны. Увы, у последних систем, программное обеспечение которых создается для ЕС ЭВМ, это лицо никак не выражено. Прежде всего, мы обязанны этим той системе, точнее отсутствию той системы сопровождения ПО, которая сложилась в последнее время.

Можно только мечтать о тех счастливых временах, когда разработчик будет периодически поставлять свежие версии своего ПО в обмен на информацию об ошибках и предложения о развитии системы. А пока что, каждый волен делать со своей СОД все, что ему захочется, и что не захочется тоже, так как делать это больше некому. Хорошо еще, если есть исходные тексты. Вот и растут, как грибы программы ассемблирования наоборот и специалисты по расшифровыванию чужих программных модулей. Лучше, чем В. Высоцкий, по этому поводу не скажешь:

Тридцать три богатыря
Порешили, что зазря
Берегли они царя
И моря!
Каждый взял себе надел,
Кур завел и в ем сидел,
Охраняя свой удел,
Hе у дел!

… (Лукоморье)

Очень важно, чтобы создатели СОД в архитектуре системы четко проводили политику разделения этих трех лиц. Иногда при внедрении СОД приходится проводить очень серьезную организационную работу, буквально перекраивая документацию, раздавая ее по листку, то пользователю, то обслуживающему сод персоналу.

Этюд.