ББК 32.973 5 страница

ЧТО ТАКОЕ ТЕХНОЛОГИЧЕСКИЙ ЯЗЫК?

По мнению автора, выявленное сходство понятий “алгоритм” и “техпроцесс” имеет фундаментальный характер и далеко идущие последствия. К сожалению, это сходство до сих пор не привлекало к себе должного внимания ученых, что привело к негативным результатам и в немалой степени способствовало разделению науки на “изолированные клетки”, создавая неоправданные препятствия для межотраслевых и междисциплинарных контактов. Сегодня программисты и технологи (в широком смысле слова, включая агрономов, медиков, педагогов, управленцев и т. д.) — это разные “касты”, которые получают разное образование и говорят на разных профессиональных языках. Подобные барьеры сильно затрудняют взаимопонимание между специалистами при решении проблем автоматизации и работе над междисциплинар­ными проектами.

Названный недостаток (трудности взаимопонимания) можно ослабить или устранить, создав единый язык, одинаково удобный для технологов, программистов и других специалистов. Для обозначения этого языка предлагается термин технологический язык (техноязык). Первым кандидатом на роль технологического языка является ДРАКОН.

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

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

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

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

ТЕХНОЛОГИЧЕСКИЕ
И ДЕКЛАРАТИВНЫЕ ЗНАНИЯ

Человеческие знания, выраженные с помощью любого письменного языка, можно разбить на две части: технологические[5] и декларативные.

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

Декларативные (дескриптивные, атрибутивные, описательные) — это знания не о действиях, а об описаниях информационных и физических объектов. Примером является типичная запись в базе данных:

Фамилия	Имя	Отчество	Год рождения	Образование	Должность	Семейное положение
Иванов	Сергей	Петрович		высшее	менеджер	женат

Для изложения декларативных знаний представители разных профессий нередко используют различные декларативные языки, в том числе графические (визуальные). Например, декларативные знания конструктора выражаются на языке конструкторских чертежей, электрика — на языке электрических схем, географа — на языке географических карт.

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

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

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

Во-первых, создаются благоприятные предпосылки для построения универсального технологического языка, позволяющего выражать любые технологические знания в любой предметной области в ЕДИНОЙ СТАНДАРТНОЙ ФОРМЕ.

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

В-третьих, средства для описания структуры деятельности, технологические знания играют особую роль в человеческой жизни. В самом деле, человек — деятельное существо. От рождения до смерти он непрерывно действует. Деятельность выражает сущность жизни. Бездеятельность — это смерть. Поэтому знания о структуре деятельности (технологические знания) составляют важнейший компонент человеческих знаний, их основу. Можно предположить, что в системе человеческих знаний технологические знания играют фундаментальную роль — роль несущей конструкции или каркаса, который скрепляет между собой (склеивает, цементирует) отдельные фрагменты декларативных знаний. Сказанное хорошо согласуется с известным мнением, что “большинство знаний об окружающем мире можно выразить в виде процедур или последовательности действий, направленных на достижение конкретных целей” [13].

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

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

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

ПОЧЕМУ НЕЛЬЗЯ ЖИТЬ ПО-СТАРОМУ?

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

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

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

СОЦИАЛЬНЫЕ ТЕХНОЛОГИИ
И ЭЛЕКТРОННЫЕ МЕТОДОЛОГИИ

Информационные технологии — не самоцель, а средство для улучшения промышленных и социальных технологий. Социальные технологии — новое и многообещающее направление [14,15], нацеленное на повышение эффективности взаимодействия людей, групп, организаций и государств (как в локальном, так и в глобальном масштабе). Неумение проектировать эффективные социальные технологии — это, пожалуй, главная причина нынешних бед цивилизации. Поэтому крайне важно научиться использовать огромный опыт человечества, накопленный при создании технических технологий для проектирования технологий социальных.

На повестке дня остро стоит вопрос о разработке нового поколения социальных технологий, способных вывести планету из нынешнего цивилизационного тупика. Это грандиозная по сложности задача. Необходимо превратить всемирную армию политиков, чиновников и специалистов (от низовых работников до руководителей государств) в профессиональных социальных технологов и социальных конструкторов, вооруженных всем богатством социально-гуманитарных и иных знаний и методов. Впрочем, это дело будущего. Сегодня делаются лишь первые шаги по совершенствованию отдельных частных аспектов социальных технологий. Одним из них является чрезвычайно интересная группа идей и подходов, направленных на качественное улучшение эффективности организаций, для обозначения которых используются выражения: “реинжиниринг бизнес-процессов”, “управление процессами”, “электронные методологии”[7]. Примеры методологий: RAD, IDEF и др. Мы ограничимся кратким знакомством с первой из них.

МЕТОДОЛОГИЯ БЫСТРОЙ РАЗРАБОТКИ
СИСТЕМ RAD

Методология RAD (Rapid Application Development) служит для разработки (при активном участии пользователей) относительно небольших, но довольно сложных коммерческих информационных систем для бизнес-приложений, обеспечивающих (в этом вся суть) качественный рост эффективности организаций. Работа выполняется одним человеком или командой (до шести человек) за срок от трех до шести месяцев по строго определенной технологии. Она включает четыре этапа:

1) анализ и планирование требований,

2) проектирование,

3) конструирование,

4) внедрение,

и преследует триединую цель: обеспечить высокую скорость разработки систем при одновременном повышении качества программного продукта и снижении его стоимости [16].

Методология RAD является обобщением мировых достижений и ориентирована на использование мощных инструментальных средств. Она постоянно пополняется новыми изобретениями и вместе с тем содержит твердое ядро основополагающих идей.

Изложение методологии RAD не входит в наши планы. Руководст­во [16] — фундаментальный труд, насчитывающий более 800 страниц. Это энциклопедия и одновременно патетический гимн во славу RAD,
а лучше сказать, настольная библия для разработчиков информационных систем, в которой детально расписаны указания, обеспечивающие эффективное практическое использование этого метода.

Мы ограничимся лишь самыми краткими сведениями, позволяющими ответить на вопрос: в каких отношениях находятся два понятия: “методология RAD ” и “язык ДРАКОН”.

В 1989 г. журнал “Форчун” попытался выяснить, почему так трудно писать программы: «Программное обеспечение — это “материя чистой мысли”, бестелесная и умозрительная; поэтому проектировщики не в состоянии нарисовать ясные, точные и подробные чертежи и схемы, как это делают разработчики электронных приборов, чтобы дать четкие указания программистам, что нужно сделать. Следовательно, повседневное общение между программистами, их начальниками и обычными людьми, которые используют программы, — это вещь в себе». Однако сторонники RAD думают по-другому. Комментируя указанную статью, Джеймс Мартин пишет: “Важно понять, что эта народная мудрость сегодня уже неверна”. В рамках RAD применяются “точные и детальные чертежи и схемы (аналогичные тем, что рисуют конструкторы электрон­ного оборудования) с помощью техно­логии I-CASE, причем из этих чертежей генерируется программный код. На уровне чертежей выполняется значительная часть проверок. Эти чертежи и схемы весьма эффективны при повседневном общении программистов, системных аналитиков, менеджеров и конечных пользователей. Попытка создавать программы без этих средств означает только одно — безответственное руководство” [16].

Добавим, что I-CASE (Integrated Computer-Aided Systems Engineering) — это специальный термин, обозначающий интегрированную технологию автоматизированного создания систем, обязательный признак которой — в отличие от обычной, неинтегрированной CASE -технологии — наличие автоматического преобразования чертежей в исходный код нужного языка (и далее — в объектный код).

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

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

Каждая из перечисленных схем представляет собой строго определенный визуальный (графический) язык. Средства I-CASE позволяют устанавливать точные связи между схемами, увязывая их тем самым в единую компьютерную гиперсхему, конвертировать чертежи друг в друга, хранить их значение в репозитории (так называется база знаний, представляющая собой общее хранилище всей информации о проекте). Репозиторий снабжен координатором знаний (knowledge coordinator), который обеспечивает согласованность между различными частями зна­ний, хранящимися в репозитории, и проверку на правильность вновь вводимых в него данных. Информация с выхода репозитория поступает на генератор кода и, если нужно, оптимизатор. Эти и многие другие методы, средства и инструменты, предусмотренные в RAD, обеспечивают значительный рост производительности труда.

СХЕМЫ ДЕЙСТВИЙ И ЯЗЫК ДРАКОН

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

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

Для представления программных структур в методологии RAD используются специальные чертежи под названием “схемы действий” (action diagrams). Эти схемы можно рисовать независимо от любого языка программирования в виде графического псевдокода, а можно настроить на какой-либо конкретный язык, например язык генератора кода. Они используются также для представления спецификаций в структурной форме.

Большинство ведущих CASE -технологий используют схемы действий. Мартин считает, что они “представляют собой наилучший способ для представления структурных программ и работы с ними” [16].

Автор не может согласиться с последним утверждением. По нашему мнению, хотя схемы действий обладают рядом достоинств, тем не менее по всем наиболее важным параметрам они уступают языку ДРАКОН
и представляют собой самое слабое место RAD -методологии. Одна из целей создания языка ДРАКОН — улучшение характеристик методологии RAD за счет замены схем действий на язык ДРАКОН.

В последнее время появились новые схемы — схемы деятельности (activity diagrams). Однако они также явно проигрывают по сравнению с ДРАКОНОМ.

НЕОБХОДИМОСТЬ КУЛЬТУРНЫХ ИЗМЕНЕНИЙ

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

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

Думается, сегодня имеет место примерно такая же ситуация, ибо сформировалась общественная потребность в техноязыке, как инструменте интеллектуального взаимопонимания и взаимодействия людей, межотраслевого синтеза и автоформализации императивных знаний, эффективного описания структуры деятельности, проектирования социальных технологий, улучшения работы ума. Известно, что “многие люди с активным умом и блестящими идеями оказываются не в состоянии заставить своих коллег точно понять, что они имеют в виду”, причем подобная ситуация, вызванная неадекватностью используемых языковых средств, является одной из причин недостаточной восприим­чивости современной индустрии к новым идеям [17]. Эти и другие со­ображения свидетельствуют о том, что для улучшения взаимопонимания необходимо провести отнюдь не простые системные изменения в культуре. По-видимому, в качестве одного из первых шагов целесооб­разно сделать техноязык частью системы образования в школе и вузе, причем не как факультатив, а как обязательный компонент учебной программы.

ТЕХНОЯЗЫК КАК ЭЛЕМЕНТ КУЛЬТУРЫ

Изложим без доказательства пять тезисов по вопросу о возможной роли языка ДРАКОН в человеческой культуре. Автор отчетливо сознает дискуссионный характер тезисов, однако питает надежду, что, дочитав книгу до конца, вы, возможно, посчитаете их хотя бы частично обоснованными.

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

! Несмотря на то, что в современных компьютерных методологиях, в частности в методологии RAD, применяется значительное число — свыше десятка — различных графических языков (схемы “сущность—связь”, схемы потоков данных, схемы действий и т. д.), с точки зрения человеческой культуры все они имеют лишь локальную эффективность как инструменты создания информационных систем и не удовлетворяют требованиям, предъявляемым к техно­языку. Это значит, что ни один из этих языков не может стать новым элементом языковой культуры человечества, который следует рекомендовать для массового изучения в школах и вузах.

! Среди указанного семейства графических языков единственным более или менее приемлемым средством для представления технологических знаний и описания структуры деятельности являются схемы действий и схемы деятельности. Однако они обладают серьезными недостатками и по своим эргономическим и дидактическим характеристикам значительно уступают языку ДРАКОН. Поэтому в качестве техноязыка и нового элемента культуры следует использовать ДРАКОН, а не схемы действий.

! Ставка на язык ДРАКОН является оправданной, так как она позво­ляет осуществить системные изменения в культуре: в системе образования, на производстве (программы и технологии), в науке (улучшение общения между учеными), в социальных технологиях и других областях.

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

ВЫВОДЫ

1. Необходимо различать три понятия: производительность системы “персонал—компьютеры”, производительность компьютеров и производительность персонала. Последняя не зависит от характеристик компьютеров и определяется характеристиками языка. Чтобы повысить продуктивность персонала, нужно улучшить когнитивные характеристики профессионального языка, используемого специалистами при выполнении интеллектуальной работы.

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

3. Сегодня формализация знаний — дорогостоящий и трудоемкий процесс. Задача состоит в том, чтобы увеличить производительность труда в процессе автоформализации технологических знаний, при описании структуры деятельности примерно на два порядка.

4. Языки представления декларативных знаний не поддаются унификации. С технологическими знаниями ситуация иная. Существует возможность построить единый универсальный технологический язык (техноязык).

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

6. Техноязык следует использовать в современных компьютерных методологиях, что заметно повысит их эффективность.

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

 

Г Л А В А 4

Понимание и взаимопонимание —
ключевые проблемы
информатики

Понимание — функция разума, главная его функция...

Наталья Автономова

ОТСУТСТВИЕ ПОНИМАНИЯ ВЕДЕТ
К МИЛЛИОННЫМ УБЫТКАМ

Главным требованием к языку ДРАКОН считается облегчение и улучшение работы ума, улучшение понимаемости проектов, алгоритмов, программ и технологических знаний. Для обозначения данного требования вводится понятие “критерий сверхвысокой понимаемости”. Считается, что язык удовлетворяет этому критерию, если написанные на нем проекты, алгоритмы, программы и технологии обладают наивысшим когнитивным качеством.

Вспомним общеизвестные факты не столь уж далекого прошлого. Один из руководителей фирмы IBM Джозеф Фокс сообщает, что в начале 1970-х гг. две основные авиакомпании возбудили дело против своих подрядчиков, поскольку созданная ими система обработки данных стоимостью 40 млн. долл. не только не работала, но и вообще не подавала никаких признаков жизни. Крупный европейский банк направил в суд иск о взыскании 70 млн. долл., выплаченных за программное обеспечение. Военно-воздушные силы США затратили более 300 млн. долл. на тщетную попытку автоматизировать комплексную систему перевозок и снабжения. Продолжая тему, Альгирдас Авиженис отмечает случаи, когда сложные и дорогие системы так и не смогли заработать из-за того, что в рамках установленных сроков и средств не удалось устранить ошибки в программном обеспечении. Джон Муса указывает: эксплуатационные и экономические последствия программных ошибок становятся “поистине ужасными”. Причина всех этих “земных катастроф” больших программистских проектов, как правило, заключалась в том, что заказчик и исполнитель совершенно по-разному понимали задачу. Грубо говоря, заказчик надеялся получить систему “про Фому”, а исполнитель сделал “про Ерему”.

Перечисленные классические примеры крупномасштабных неудач, а также многие другие факты, в том числе эпидемия казавшихся непонятными провалов проектов АСУ[8] в нашей стране хотя и стали достоянием истории, тем не менее остаются поучительными до сих пор. Анализ подобных инцидентов позволяет сделать четыре вывода:

1) успех крупного проекта напрямую зависит от взаимопонимания между его участниками;

2) чтобы добиться взаимопонимания, нужны недели и месяцы, а в сложных случаях — годы кропотливой совместной работы заказчика и исполнителя;

3) проблему взаимопонимания нельзя считать решенной до сих пор; достижение взаимопонимания — тяжелый и сложный интеллектуальный труд, производительность которого крайне низка;

4) было бы крайне желательно формализовать этот труд и резко увеличить его производительность.

ИЗДЕВАТЕЛЬСТВО НАД ЗДРАВЫМ СМЫСЛОМ
ПОД НАЗВАНИЕМ
“АБСОЛЮТНО ПРАВИЛЬНАЯ ПРОГРАММА”

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