Евгений Лишак - Записки парасистемного программиста

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

Следуя примеру [1], попытаемся выделить еще несколько существенных для обслуживания СОД свойств ПО. 1. Неприхотливость, то есть способность ПО работать на неисправном оборудовании, пока оно не сломалось до такой степени, что неисправность легко обнаруживается и устраняется. Нужно всегда помнить, что перевести устройство из хорошего состояния в отличное на несколько порядков сложнее, чем из плохого в удовлетворительное. 2. Безопасность, то есть способность при любом сбое не произвести во внешней среде необратимых изменений. Следует отличать это свойство от устойчивости. При внешнем или внутреннем возмущении устойчивое ПО будет стараться выполнить свое назначение. Например, ПО, ответственное за посадку автомата на Луну, постарается хоть криво и не туда, куда хотелось бы, но все же автомат посадить. А вот "криво" исправленная база данных (невосстановимая приемлимыми средствами) — это часто гораздо хуже, чем отказ ПО. Следует различать разницу между отказом ПО и отказом СОД. 3. Дотошность, то есть способность ПО во время функционирования предоставлять информацию, достаточную для последующего ремонта оборудования. Любопытен еще и такой факт. Большинство характеристик качества ПО носит объектный характер, то есть они прямо или косвенно указывают, что с этим ПО можно (нельзя) сделать. Для тех же, кто с этим ПО ничего делать и не собирается, кто хочет спокойно сосуществовать с этим ПО, обслуживая сод, для тех едва ли не менее интересны субъектные свойства ПО. Им важно, что это ПО само сможет (не сможет) сделать. Сравните "прозрачное" — сквозь которое может смотреть (кто-то другой), и "неприхотливое" — которое может (само) терпеть.

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

Этюд.

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

// ЕХЕС UРD,D=ZОNТIК./ СНАNGЕ./ DЕLЕТЕ SЕQ1=20,SЕQ2=20

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

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

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