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

Макет прикладной программы

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

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

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

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

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

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

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

- до сих пор нет каких-либо широкодоступных средств или технологических приемов для оптимизации самого процесса выработки требований к программам;

- не известно никаких объективных критериев для контроля качества результатов работы системного аналитика, кроме... успеха или провала проекта в целом" [24,с.139].

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

" - система принципиально должна быть определена пользователем в общепринятых терминах и категориях;

-  пользователь в состоянии определить свою систему, но не знает, как она будет функционировать;

-  пользователь понимает, какая система ему нужна и как она должна функционировать, но не в состоянии это точно сформулировать" [24, с. 140].

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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