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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основным инструментом для создания макетов прикладных программ, утверждает Мартин, являются терминалы больших ЭВМ. Эти терминалы позволяют пользователям в интерактивном режиме самостоятельно создавать прикладные программы, пользуясь для этого так называемыми языками четвертого поколения (4 GLs) типа NOMAD и др.

Итак, в начале 80-х годов Мартин и Черер открыли макет как средство повышения эффективности разработки прикладных программ на больших ЭВМ. При этом они, по-видимому, по разным причинам, но с одинаковой последовательностью не заметили факта существования персональных ЭВМ — самой популярной в это время макетницы для миллионов конечных пользователей и профессиональных программистов. К весне 1981 г., когда было опубликовано «открытие Черер—Мартина», за пределами мира больших ЭВМ уже свыше пяти лет широко использовались преимущества, провозглашенного Мартином революционного подхода: «Разработка прикладных программ без программистов». Основным инструментом этой принципиально новой технологии программирования — технологии автоформализации профессиональных знаний — были микро-ЭВМ в режиме персональных вычислений.


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