Informix Logo


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

Г.Р. Громов


Весной 1981 г. независимо Л.Черер в статье, опубликованной апрельским номером Datamation, и в мае Дж.Мартин в лекциях, прочитанных в Англии, на   семинаре в Savant Inst., выступили с обоснованием необходимости для широкого класса программистских проектов начинать разработку не традиционными попытками составления формальных спецификаций, а макетированием.

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

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

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

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

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

С другой стороны, пользователь, который должен отвечать на вопросы системного аналитика, испытывает в ряде случаев не меньшие трудности. По мнению Л.Черер, типичными для пользователя являются следующие три ситуации:

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

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

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

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

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

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

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

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

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

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

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

  1. Разработка пилот-пользователем (квалифицированным специалистом в данной предметной области, освоившим режим персональных вычислений) прикладной программы, которая, по экспертным оценкам, обеспечивает решение одной из актуальных (для данной предметной области) задач автоматизации. Весь последующий ход разработки целиком определяется двумя прагматическими характеристиками качества созданной программы: достаточен ли достигнутый эффект повышения производительности труда от производственной эксплуатации созданной программы для инициирования работ по ее промышленной доводке и тиражированию; проходит ли программа в практически интересных режимах ее эксплуатации ограничения используемой конфигурации персональной вычислительной системы.Если ресурсы конкретной вычислительной системы, на которой создана программа, обеспечивают ее работоспособность для большей части практически интересных пользователю режимов эксплуатации, а интерес к ее тиражированию не очевиден, то для данной прикладной программы технологический цикл разработки может считаться завершенным (без вмешательства профессиональных программистов).
  2. В случае, когда программа убедительно демонстрирует практическую полезность в рамках автоматизируемой производственной задачи (но не за ее пределами), однако нуждается в совершенствовании по машинным критериям эффективности, профессиональный программист пытается найти (и, как правило, находит) в тексте работающей программы те 5% программного кода, которые обычно в любой прикладной программе "съедают" более 50% всех необходимых ей машинных ресурсов, причем программист "расшивает" лишь "узкое место" в программе, по возможности не затрагивая все, что можно оставить в первозданном виде.
  3. Если выясняется, что созданная пилот-пользователем программа вызывает практический интерес у большого числа специалистов в данной предметной области, а вопрос целесообразности ее тиражирования и широкой коммерческой поставки получил убедительное технико-экономическое обоснование, то текст программного кода "плохой" (или "грязной"), но правильно работающей программы используется в качестве точной формальной спецификации для начала промышленного цикла разработки программного продукта по традиционной схеме технологии программирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Украинская баннерная сеть
 

[Home]

Сайт поддерживается группой пользователей Информикс на Украине.

Hosted by NO-more.