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

Альтернатива "реликтовому" критерию?

Можно предположить, что указанные выше факторы лишь частично объясняют сложившуюся  парадоксальную ситуацию. Дело в том, что, пока в большинстве практически интересных случаев не выработано количественной оценки правильности программ, разработчик старается сделать ее правильной хотя бы по одному точно ему известному, пусть в данном случае несущественному, но профессионально престижному (количественному!) критерию. Таким универсальным для всех областей приложений и наиболее точно измеряемым критерием остается до сих пор внутренний критерий эффективности, оцениваемый по ресурсам ЭВМ: "Сколько времени Ваша программа обрабатывает массив из ...по...? А моя ...! А объем памяти?"... Это единственный универсальный критерий, который обеспечивает код профессионального общения для программистов из разных коллективов, организаций и стран. И критерий этот будет, видимо, существовать до тех пор, пока у него нет альтернативы.

Трудно предположить, чтобы, следуя, например, приведенной выше "формуле эффективности по Майерсу", профессиональные программисты решились сопоставлять итоги отдельных разработок в таких терминах: "Насколько работа Вашей программы более правильно отражает существо поставленной пользователем прикладной задачи, чем моя?" В какой "метрике" оценивать правильность прикладных программ?

В середине 70-х годов Э. Дейкстра предложил следующий объективный критерий оценки качества программы: ""элегантным" мы всегда называем то, что допускает красивое короткое доказательство... длина формального доказательства - это объективный критерий" [5, С.272]. Таким образом, из двух сопоставляемых программ более "элегантной" следует считать ту, для формального доказательства правильности которой потребуется более короткое доказательство. К сожалению, несмотря на успех книги "Дисциплина программирования", в которой обосновывается этот критерий "элегантности", пока не заметно, чтобы он сколько-нибудь потеснил "реликтовый" критерий эффективности.

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

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

Разумеется, предлагалось и предлагается много других оценок для объективного измерения качества программ[1]. Однако лишь очень немногие из них выдерживают даже короткое испытание временем. В качестве примера оценок, интерес к которым сохраняется (хотя пока лишь на академическом уровне), можно указать на так называемый критерий Хэлстеда [6-8].

В 1972 г. М. Хэлстед обратил внимание на устойчивый рисунок в статистическом распределении частоты используемых в программах операторов и операндов на различных этапах трансляции программ. Выполняя затем реассемблирование большого числа объективных модулей для разного типа и размеров программ, он наблюдал инверсное распределение частоты символов программного кода, которое напомнило ему результаты из опубликованной в 1949 г. работы Г. Зипфа, исследовавшего тексты на естественном языке. На основании этой оказавшейся содержательной аналогии Хэлстед предложил новую статистическую оценку качества программы - логарифмическую меру, которая связывает число активно используемых базовых символов программного кода с "фактором длины" программы. По его мнению, такой фактор длины (length estimator) может объективно характеризовать качество программного кода на всех фазах преобразования текста программы: от языка высокого уровня до ассемблера.

В 1982 г. была опубликована статья Н. Безера "Теоретические и экспериментальные основы программирования"[2], в которой автор (кроме обзора избранных работ по этой теме, выполненных в IBM и других крупнейших фирмах) приводит собственные экспериментальные результаты, полученные обработкой большого объема программных текстов, доказывающие статистическую связь фактора длины с практически интересными характеристиками качества программ, в том числе и ожидаемой вероятностью ошибок [6].

Итак, пока не известно новых критериев качества программ, которые приближались бы по простоте их интуитивного понимания и универсальности применения (а следовательно, и популярности) к "реликтовым" критериям оценки, основанным на прямых измерениях используемых  машинных ресурсов: какую вычислительную мощность потребляет программа от всей мощности Процессора и какой объем памяти она при этом занимает. Что может быть проще, чем два широкоизвестных аналога основных понятий окружающего нас мира: скорость (операций/с); объем (куб памяти, три куба памяти и т.д.). По-видимому, нелегко будет найти иные критерии, близкие по доходчивости и практически неограниченному кругу применения. Но как оценивать качество прикладных программ потребителю программного продукта - конечному пользователю, если сами программисты пока не в состоянии найти разумную альтернативу "реликтовым" критериям? Где новый ориентир? Оценка правильности прикладных программ. Неуклонное сближение средств обработки и передачи информации сопровождается их усиливающимся взаимным влиянием, причем не только технологическим. По-видимому, близок этап сближения и многих основных концепций: "...критерий верности не универсален и не задан заранее; он должен выбираться в каждом данном случае, исходя из задач и обстановки", - отмечал академик А. А. Харкевич в 1963 г.

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

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

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

В условиях наблюдаемого кризиса традиционного подхода к созданию прикладных программ основным критерием правильности создаваемой программы оказываются только вызываемые ею изменения в характере производственной деятельности конечного пользователя: помогает ли ему в практической работе созданный программный продукт. Иными словами, основным показателем эффективности технологии программирования в 80-х годах становится достигаемый уровень повышения производительности труда конечного пользователя.

Наиболее трудной задачей оказывается в этих условиях организация активного производственного взаимодействия конечного пользователя с разработчиками программ на всех основных этапах создания программного продукта. В завершающей стадии успех (или провал) разработки по существу определяется ответом конечного пользователя на два основных вопроса:

1)  сделано ли именно то, что он пытался сформулировать (самостоятельно или с помощью системного аналитика) как задачу разработки программного продукта (или результатом разработки оказалось нечто иное);

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

Один из наиболее драматических парадоксов технологии программирования заключается в том, что профессионально сделанная прикладная программа с вероятностью, близкой к единице, оказывается бесполезной. В более чем 9 случаев из 10 организация-пользователь или отдельные конечные пользователи дают разочаровывающий программиста ответ по крайней мере на один из двух поставленных выше вопросов. Например, по результатам исследований, выполненных компанией Applied Data Research, на американском рынке программного обеспечения ЭВМ в среднем только 1 из 10 разрабатываемых пакетов имеет шанс на успех у пользователя [9].

При этом данная оценка еще не означает, что индустрия прикладных программ к началу 80-х годов работала, пользуясь терминологией изготовителей интегральных схем, с "10%-ным выходом годных". К сожалению, и эту оценку следует считать завышенной, поскольку на усредненные "10% выхода годных" приходятся и все те программы, которые, хотя и были приобретены конечным пользователем, но затем сразу осели на стеллажах с неиспользованными колодами.

Такая ситуация, как правило, складывается, когда организация приобретает пакет, оказавшийся (по отзывам) полезным в другой, близкой по производственному профилю организации. Причины возникающих затем разочарований понятны. "Жизнь сложна потому, что конкретна", - пояснял М. И. Лазарев, один из разработчиков в НИВЦ АН СССР пакетов для прочностных расчетов. Американские эксперты предпочитают афоризмам количественные иллюстрации: "Если у вас есть пакет прикладных программ, и вы устанавливаете его в 16 различных организациях, то при этом вы создаете 16 различных пакетов" [10, с. 142].

Чтобы объяснить причины, по которым пользователь на этапе внедрения нередко отказывается от сформулированных им же самим требований на программу и утверждает, что имелось в виду нечто совершенно иное, Дж. Мартин предложил в 1981 г. ЭВМ-вариант известного в физике принципа неопределенности: "Начало процесса автоматизации задач, которые ставит конечный пользователь, немедленно изменяет его представление об этих задачах. Решение проблемы изменяет саму проблему" [11].

Таким образом, к началу 80-х годов в индустрии ЭВМ сложилась ситуация, когда ни разработка прикладных программ, ни тиражирование ранее созданных программных продуктов не могут быть сколько-нибудь эффективными без организации активного производственного взаимодействия разработчиков с конечным пользователем на всех этапах технологического цикла создания и внедрения созданного изделия. Готовых технологических решений или научно обоснованных рекомендаций для организации эффективных форм индивидуального взаимодействия профессиональных лидеров в конкретной предметной области ("пилот-пользователей") с разработчиками программных изделий в арсеналах большой науки программирования нет. Результативность традиционной технологии прикладного программирования, неуклонно снижаясь с ростом областей применений ЭВМ, к началу 80-х годов упала до уровня ниже 10%, т.е. более чем 90% профессионально созданных прикладных программ не находили практического применения.


[1]Специалисты, озабоченные проблемой количественных измерений в программировании, объединены и специальную рабочую группу при ACM (SlGMеtrics).
[2] Широковещательное название этой работы (тем не менее в содержательном плане безусловно интересной), видимо, представляет собой в некотором роде дань сложившейся в этой отрасли инженерного искусства традиции, по которой любой сколько-нибудь нетривиальный результат, как правило, оказывается поводом для создания очередных "основ науки программирования" ("foundations of software science").

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