Национальные информационные ресурсы:
проблемы промышленной эксплуатации.
Г.Р.Громов. Москва, Наука, 1984

 

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

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

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

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

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

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

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

Разумеется, и реальной практике отмеченные варианты не обязательно реализуются в «чистом» виде или точно определяются лишь перечисленными условиями. Чтобы проиллюстрировать многообразие возможных подходов к практической реализации концепции макета или программы-про­тотипа, выше была приведена схема Топ технологии, разработанной в НИВЦ АН СССР для создания «кремниевого программного обеспечения» лабораторных микро-ЭВМ, анализировался опыт этой разработки и обсуждались некоторые другие реализации исследуемого подхода.

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

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

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

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

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

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

«Почему фирма «Би-эй-эс» может гарантировать дату окончания работ и поддерживать их стоимость на фиксированием уровне, если продолжительность программных проектов и их стоимость обычно значительно больше предвари тельных оценок?

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

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

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

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

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

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

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

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

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

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

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

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

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


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