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

Персональные вычисления или макетирование программ?

Типовая для 80-х годов последовательность разработки прикладных программ включала следующие три основных этапа.

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

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

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

2. В случае, когда программа убедительно демонстрирует практическую полезность в рамках автоматизируемой производственной задачи (но не за ее пределами), однако нуждается в совершенствовании по машинным критериям эффективности, профессиональный программист пытается найти (и, как правило, находит) в тексте работающей программы те 5% программного кода, которые обычно в любой прикладной программе "съедают" более 50% всех необходимых ей машинных ресурсов [26, C.43],  причем программист "расшивает" лишь "узкое место" в программе, по возможности не затрагивая все, что можно оставить в первозданном виде.

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

Разумеется, в реальной практике отмеченные варианты не обязательно реализуются в "чистом" виде или точно определяются лишь перечисленными условиями.

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

Существование к началу технологического цикла разработки программного продукта выверенной в реальной производственной эксплуатации программы-прототипа позволяет:

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

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

-  более чем в 5 раз снизить трудозатраты на этапах тестирования и отладки программного продукта   (так как 83% этих трудозатрат [25] до сих пор были связаны лишь с неточностями формальных спецификаций на программу).

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

"Почему фирма BAS может гарантировать дату окончания работ и поддерживать их стоимость на фиксированном уровне, если продолжительность программных проектов и их стоимость обычно значительно больше предварительных оценок?

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

Во-вторых, здесь нет никакого творчества, кроме того, что возникает при переходе из А в В в данном машинном окружении; этапы преобразования определены заранее, и каждая строка получившейся программы проверяется двумя людьми, что уменьшает возможность возникновения досадных ошибок и использования ненужных индивидуальных методов.

Основная цель преобразования состоит в получении новой программы, которая функционально эквивалентна старой; эту задачу поставить легче и легче решить, чем при разработке новой системы, легче оценить се точную стоимость [27, с. 230].

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

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

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

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

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

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

Здесь, видимо, уместно вспомнить предупреждение Дж. фон Неймана - одного из выдающихся современных математиков, с именем которого связывают фундаментальные понятия архитектуры традиционных ЭВМ. Около 30 лет назад он отмечал, обращаясь к энтузиастам широкого внедрения средств вычислительной техники, что возможности формального описания решаемых на ЭВМ сложных задач существенно ограничены: "У нас нет полной уверенности в том, что в этой области реальный объект не может являться простейшим описанием самого себя, т.е. что всякая попытка описать его с помощью обычного словесного или формально-логического метода не приведет к чему-то более сложному, запутанному и трудновыполнимому..." [28, с.91].

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

Книга Пойа "Математическое открытие" начинается следующим утверждением Лейбница: "Метод решения хорош, если с самого начала мы можем предвидеть - и далее подтвердить это, - что, следуя этому методу, мы достигнем цели" [29, с. 13]. В технологии программирования до сих пор нет иного метода, кроме макетирования, который бы удовлетворял этому критерию Лейбница.


[1] То, что Дж. Мартин определяет как "программирование без программистов" [25].


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