Очерки информационной технологии.
Г.Р.Громов.
Москва, ИнфоАрт, 1992, 1993.

1 % эффективности: критический порог?

Как известно, возможности перехода от пакетной обработки к системам разделения времени начали рассматриваться в практическом плане в 60-х годах лишь тогда, когда эффективность обработки информации на больших вычислительных центрах снизилась до уровня ниже 1%.

Подготовленный М. Драммондом (один из ведущих экспертов фирмы IBM) фундаментальный труд "Методы оценки и измерений цифровых вычислительных систем" был опубликован в 1973 г., когда еще свежи были в памяти воспоминания об эпохе расцвета пакетной обработки, а для многих вычислительных центров, особенно базирующихся на машинах фирмы IBM, это все еще был основной режим работы. Вот некоторые оценки, приводимые в этой работе: "Время от поступления задания в вычислительный центр до введения его в машину составляет около 44% времени прохождения задания через систему... время от получения всех результатов вычислений на машине до выдачи их пользователю составляет 55%. Другими словами, в классической пакетно-ориентированной системе задание находилось в машине лишь 1 % общего времени прохождения задания" [14, с.71].

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

Этот основной критерий эффективности отражал те экономические аспекты процесса обработки данных, которые сложились в конце 50-х годов, когда формировалась концепция пакетной обработки данных. Час работы ЦП тогда стоил больше, чем часовая ставка всех ожидавших очереди к нему пользователей вычислительного центра, вместе взятых. Поэтому основная концепция первого этапа информационной технологии формулировалась достаточно жестко: все, что могут делать люди, должны делать люди; ЦП выполняет лишь ту часть работы по обработке данных, которую люди принципиально выполнить не могут, - массовый счет.

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

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

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

Так в конце 60-х годов, после этапа культа ЦП, наступил этап массовой рабочей эксплуатации ЭВМ. С этого момента относительно старое в технике понятие - автоматизация и относительно новое - программирование начали неуклонно сближаться. Создать прикладную программу по существу означает (в случае удачи) автоматизировать одну из почти безбрежного океана задач, повседневно решаемых людьми в своей профессиональной деятельности.

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

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

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

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

Успехи большой науки программирования за 30 лет ее формирования, развития и становления как самостоятельной научной дисциплины позволяют к настоящему времени в большинстве случаев получать ответ (хотя, как правило, и не в количественных терминах, но все-таки ответ) на два основных вопроса: 1) качество программного кода (программа, "плохая - хорошая"); 2) соответствие программы заданным на нес формальным спецификациям ("далеко - близко"). В то же время вопрос: "Насколько точно формальные спецификации отражают существо поставленной задачи?" - почти всегда находился, так сказать, за кадром. Качество выполнения основного процесса, полностью определяющего судьбу программистского проекта в целом - процесса отображения реального мира в мир формальных алгоритмов, - оставалось за пределами интересов большой науки программирования.

По мнению В. Турского, программист "слишком часто сосредоточивает внимание на программе, которую надо написать, а не на задаче, которую предстоит решить".

"Существует, - продолжает В. Турский, - хорошее историческое объяснение такого положения дел: очень многие программисты приобщились к этой профессии в те дни, когда быть программистом значило то же самое, что быть верховным жрецом новой и могущественной религии; запутанная и неполная документация, царственное пренебрежение вопросами стоимости и озабоченность лишь своими внутренними проблемами - все это можно отнести к искусственно возвышаемому положению шамана от программирования. Процесс обучения программистов также несет свою долю ответственности за это: в нем слишком часто переоценивается возможность трюков и внутренних методик, поощряется такой образ мысли, при котором внутренняя красота программы предпочитается ее полезности" [15, с.205].

Работа в комфортных границах профессиональной ответственности оказалась длительное время возможной из-за своеобразного, почти неизвестного в других отраслях техники принципа отбора решаемых задач. Была выработана корпоративная точка зрения[2], согласно которой качество формальных спецификаций отражает не уровень профессионального мастерства проектировщика программного продукта (или текущий уровень проектирования), а степень "дозревания" конкретной прикладной задачи до необходимости ее автоматизации. Надежные, точные спецификации - значит задача для автоматизации "дозрела"; в противном случае - "не дозрела". По этой длительное время казавшейся естественной классификации в число "недозревших" попадали, как правило, наиболее интересные с народнохозяйственной точки зрения прикладные задачи: экономики, технологии и организации производства, медицины и биологии и многие другие трудноформализуемые, так называемые слабоструктурированные задачи.


[1] Здесь, разумеется, рассматриваются только информационные аспекты проблем автоматизации и не затрагиваются многие другие, в ряде случаев существенно более важные ограничения: энергетические, механические и т.д., рассмотрение которых выходит за рамки обсуждаемой темы.

 [2] "Спокойствие многих было бы надежнее, если бы дозволено было относить все неприятности на казенный счет", - мечтал Козьма Прутков.


Онлайн-версия CD-ROM приложения к книге Г.Р.Громова
"
От гиперкниги к гипермозгу: информационные технологии
эпохи Интернета. Эссе, диалоги, очерки
."