рону при работе над
первым проектом.  ‚  результате получаетсЯ, говорЯ словами ЋвидиЯ,  "большаЯ
куча".  ђассмотрим,  например, архитектуру  IBM  709, воплощенную позднее  в
машине  7090. ќто - модернизациЯ, вторЯ система длЯ очень успешной и  хорошо
скроенной  системы  704.  Ќабор команд был настолько богат и  изобилен,  что
регулЯрно использовалась примерно лишь половина его.
     ђассмотрим  в качестве более сильного примера архитектуру, разработку и
даже  реализацию  компьютера  Stretch,  которые  дали  выход  сдерживающимсЯ
изобретательским стремлениЯм многих людей,  длЯ большинства которых это было
втораЯ система. ‚от что пишет в своем обзоре ‘трейчи (Strachey):
     <i>“ менЯ  создалось впечатление,  что  некоторым  образом Stretch  ЯвлЯет
собой окончание определенного направлениЯ разработок. Љак и некоторые ранние
компьютерные программы,  эта система чрезвычайно изобретательна, чрезвычайно
сложна и очень эффективна, но в то же времЯ ЯвлЯетсЯ сырой, расточительной и
неизЯщной, оставлЯЯ ощущение, что эти вещи можно делать лучшим образом</i>.1
     Operating   System/360  была  второй  системой  длЯ  большинства  своих
проектировщиков.  ѓруппы  проектировщиков пришли после работы  над  дисковой
операционной  системой  1410-7010, операционной  системой  Stretch, системой
реального  времени Project Mercury и  IBSYS длЯ 7090. …два  ли кто-то из них
имел опыт работы над <i>двумЯ</i> предшествующими операционными системами.  Џоэтому
OS/360 ЯвлЯетсЯ  Ярким  примером эффекта второй системы,  аналогом Stretch в
искусстве программированиЯ, к которому в полной мере применимы и  похвалы, и
упреки приведенной критики ‘трейчи.
     Ќапример,  в  OS/360  отводитсЯ  26  байт  длЯ  резидентной   процедуры
преобразованиЯ даты,  чтобы правильно обрабатывать  31  декабрЯ в високосном
году (когда это 366-й день). ќто можно было оставить оператору.
     ќффект  второй  системы  имеет  и  другое  проЯвление,  кроме  простого
украшательства  функциЯми.  ќто  - склонность  к усовершенствованию методов,
само существование которых стало анахронизмом благодарЯ изменениЯм в базовых
принципах системы.  OS/360  содержит  многочисленные примеры, подтверждающие
это.
     ђассмотрим  редактор  свЯзей,  предназначенный длЯ  загрузки независимо
скомпилированных программ и разрешениЯ их  перекрестных  ссылок. Џомимо этой
основной  функции он  также  управлЯет программными  оверлеЯми.  ќто одно из
лучших  когда-либо  созданных  средств работы  с  оверлеЯми.  Ћно  позволЯет
создавать оверлейную структуру внешним образом при редактировании свЯзей, не
трогаЯ  исходного  кода.  Ћно  позволЯет  изменЯть  структуру  оверлеев  без
перекомпилЯции при  каждом прогоне. Ћно предоставлЯет богатый выбор полезных
опций и  возможностей. ‚  известном смысле, это завершающий итог многолетней
разработки технологии статических оверлеев.
     €  в  то  же  времЯ это  последний и совершеннейший динозавр, поскольку
входит  в систему, в которой  многопрограммность ЯвлЯетсЯ обычным режимом, а
динамическое распределение памЯти - базовым принципом. ќто вступает в прЯмой
конфликт с  понЯтием  использованиЯ  статических  оверлеев. Ќесколько  лучше
работала бы  система, если бы  усилиЯ,  потраченные на управление оверлеЯми,
были  перенаправлены  на  то,   чтобы   ускорить  работу  средств  поддержки
динамического распределениЯ памЯти и перекрестных ссылок!
     Ѓолее того, редактор свЯзей  требует  так много памЯти,  и сам содержит
столько оверлеев, что даже  при использовании только длЯ редактированиЯ  без
управлениЯ оверлеЯми уступает в скорости большинству системных компилЯторов.
€рониЯ  состоит в том, что назначение  редактора свЯзей - избежать повторной
компилЯции.  Љак  у  конькобежца  корпус  оказываетсЯ  впереди  ног,  так  и
усовершенствованиЯ продолжались,  пока не вышли  далеко  за рамки  системных
принципов.
     „ругим   примером   этой   тенденции  ЯвлЯетсЯ  отладчик  TESTRAN.  ќто
совершенный  пакетный  отладчик,  предоставлЯющий  действительно  элегантные
средства  получениЯ мгновенных  снимков и дампов памЯти.  ‚ нем используетсЯ
понЯтие  управлЯющих разделов и  искуснаЯ технологиЯ  генерации, позволЯющие
осуществлЯть  избирательную  трассировку и получение мгновенных  снимков без
дополнительных  расходов  на  интерпретацию или  рекомпилЯцию. ‡десь  пышным
цветом расцвели  впечатлЯющие концепции операционной системы Share Operating
System3 длЯ модели 709.
     Њежду тем устарела сама идеЯ пакетной отладки без рекомпилЯции. ѓлавный
вызов  был брошен интерактивным  вычислительным системам с  интерпретаторами
Языков программированиЯ  и  пошаговыми компилЯторами.  Ќо даже в  системах с
пакетной обработкой поЯвление компилЯторов с быстрой компилЯцией и медленным
выполнением  сделало  более предпочтительной  технологию  отладки  на уровне
исходного кода и  получениЯ мгновенных снимков. Ќасколько лучше оказалась бы
система, если бы силы, потраченные на проект TESTRAN, были перенаправлены на
ускоренное создание  лучших  средств  длЯ  интерактивной  работы  и  быстрой
компилЯции!
     …ще  один  пример - планировщик, предоставлЯющий действительно отличные
возможности   длЯ  управлениЯ  потоком  фиксированных  пакетов  заданий.  Ќа
практике   этот  планировщик  ЯвлЯетсЯ   усовершенствованной,  улучшенной  и
наделенной  разными  украшениЯми  второй  системой,  которой  предшествовала
дисковаЯ  операционнаЯ  система 1410-7010 - система пакетной  обработки,  не
ЯвлЯющаЯсЯ многопрограммной, за исключением ввода-вывода, и предназначенной,
главным образом,  длЯ деловых приложений. ‚ этом качестве планировщик OS/360
хорош.  Ќо  на него  почти никакого влиЯниЯ не оказали потребности  OS/360 в
удаленном  вводе  заданий,   многопрограммности   и  резидентном  размещении
интерактивных  подсистем.  € действительно,  проект  планировщика затруднЯет
решение этих задач.
     Љак архитектору избежать эффекта второй  системы? Ћчевидно,  пропустить
свою  вторую систему он не может. Ќо он может  отдавать себе отчет  в особых
опасностЯх,  которым   она  его   подвергает,   и   проЯвить  дополнительную
самодисциплину, чтобы избежать  функционального украшательства и  сохранениЯ
функций, нужда в которых отпала ввиду изменений в принципах и целЯх.
     ЏорЯдок, способный открыть  архитектору глаза, заключаетсЯ в том, чтобы
присвоить численное значение  каждой, пусть малой, функции: характеристика <i>x</i>
должна  обойтись  не более чем в  <i>m</i>  байтов памЯти и  <i>n</i> микросекунд на  один
вызов.  ќти  величины  должны служить руководством  при  принЯтии  начальных
решений, а также напоминанием и руководством при реализации.
     Љак менеджеру проекта избежать  эффекта второй  системы?  Ќастаивать на
том, чтобы его старший архитектор имел опыт  разработки хотЯ бы двух систем.
Љроме  того,  будучи   осведомленным  о   возможных  опасностЯх,  он   может
предъЯвлЯть необходимые требованиЯ длЯ того, чтобы в детальном проекте нашли
полное отражение идеологических концепций и цели.

        ѓлава 6. „онести слово
     <i>Ћн сЯдет здесь  и будет  распорЯжатьсЯ:  "‘делайте
это! ‘делайте то!"</i> <b><i>Ђ дело и с места не сдвинетсЯ</b></i><b><i>.</b>
     ѓЂђђ€ ‘. ’ђ“Њ…Ќ. "Ћ Џђ…‡€„…Ќ’‘ЉЋ‰ ‚‹Ђ‘’€"1</i>
     Љак   менеджеру,  имеЯ  опытных  дисциплинированных  архитекторов   и
достаточное число исполнителей, добитьсЯ того, чтобы все услышали,  понЯли и
выполнили  решениЯ  архитектора? Љак группе из 10 архитекторов  поддерживать
концептуальную  целостность системы, над которой трудитсЯ 1000 человек?  „лЯ
достижениЯ этого при осуществлении программы проектированиЯ аппаратной части
System/360  была разработана  целаЯ технологиЯ,  котораЯ  в  равной  степени
применима длЯ проектов созданиЯ программного обеспечениЯ.
     Џисьменные спецификации - руководство
     ђуководство, или письменнаЯ документациЯ, ЯвлЯетсЯ необходимым, хотЯ и
не достаточным,  инструментом.  ђуководство ЯвлЯетсЯ  <i>внешней</i>  спецификацией
продукта. ‚ нем  расписаны  все подробности того, что  видит пользователь, и
потому оно ЯвлЯетсЯ главным продуктом, который создает архитектор.
     …го  подготовка  идет  кругами,   собираЯ  замечаниЯ  пользователей   и
разработчиков  о   недостатках  проекта,   затруднЯющих   использование  или
реализацию.  „лЯ  удобства  разработчиков  необходимо квантовать  изменениЯ:
согласно определенным в графике датам выпускать очередные версии.
     €нструкциЯ должна не только описывать все,  что видит  пользователь,  в
том  числе все  интерфейсы,  но и  воздерживатьсЯ  от  описаниЯ  того,  чего
пользователь не видит. Џоследнее - забота разработчика, и  здесь свобода его
решений  не  должна  быть  ограничена. Ђрхитектор всегда должен  быть  готов
показать <i>пример</i>  реализации любой описанной им  функции,  но  он  не  должен
пытатьсЯ навЯзывать <i>определенную</i> реализацию.
     ‘тиль должен быть точным, полным и  очень подробным. Џользователь часто
обращаетсЯ к отдельному  определению,  поэтому во  всех  из  них должны быть
повторены все существенные элементы,  и все они должны быть согласованы друг
с другом. Џо  этой причине инструкции часто скучно читать, но точность имеет
приоритет перед увлекательностью.
     …динство "Џринципов работы System/360" проистекает из  того, что  у них
было  лишь два автора: „жерри Ѓлау и  Ђндрис Џадега.  Ђвторами идей ЯвлЯютсЯ
порЯдка десЯти человек, но  если требуетсЯ соблюсти согласованность описаниЯ
и  продукта, отливку решений в прозаические спецификации должны осуществлЯть
не более  двух человек.  „лЯ написаниЯ  определениЯ требуетсЯ принЯть  массу
мини-решений,  которые  не  столь  важны,  чтобы  выносить  их  на  всеобщее
обсуждение.  „лЯ System/360  примером  служат  подробности  того,  как после
каждой  операции  устанавливаетсЯ   код   условиЯ.  Ћднако  задача  всеобщей
согласованности таких мини- решений <i>не</i> ЯвлЯетсЯ тривиальной.
     „умаю, что лучший виденный мной образец  руководства -  это  написанное
Ѓлау приложение  к "Џринципам работы  System/360". ‚ нем  тщательно и  точно
описаны  <i>границы</i> совместимости System/360. „ано  определение  совместимости,
предписываетсЯ,  к чему нужно  стремитьсЯ, и  перечислены те области внешних
проЯвлений, где  архитектура  намеренно молчит, и где результаты, полученные
на разных моделЯх, могут отличатьсЯ между собой, где разные экземплЯры одной
модели могут дать различные  результаты и даже один и тот же экземплЯр может
давать  различиЯ после конструктивных изменений.  ќто  уровень  точности,  к
которому стремЯтсЯ составители  руководств. Ћни  должны  одинаково описывать
как то, что можно делать, так и то, что делать нельзЯ.
     ”ормальные определениЯ
     Ђнглийский  Язык,  как и  любой  другой  естественный Язык, по  своей
природе  не  ЯвлЯетсЯ  точным инструментом,  пригодным  длЯ таких  описаний.
Џоэтому составитель  руководства  должен  держать  в узде  себЯ и свой Язык,
чтобы    достичь    необходимой    строгости.   Џривлекательна   возможность
использованиЯ длЯ таких определений формальных обозначений. ‚ конце  концов,
целью  ЯвлЯетсЯ точность, что обусловливает право формальных обозначений  на
жизнь.
     ђассмотрим   достоинства   и  слабости  формальных   определений.   Љак
отмечалось, формальные определениЯ ЯвлЯютсЯ точными. Ћни тЯготеют к полноте:
пробелы  заметнее,  а  потому  скорее  восстанавливаютсЯ.  €х  недостаток  -
трудность пониманиЯ. Ќа английском Языке можно описать структурные принципы,
очертить структуры  по  этапам  или  по  уровнЯм и привести  примеры.  ‹егко
отметить исключениЯ и  подчеркнуть противоположности. …ще важнее,  что можно
объЯснить <i>причины</i>. ЏредлагавшиесЯ до сих пор формальные определениЯ вызывали
восхищение своей элегантностью и уверенность в их точности. Ќо они требовали
текстуальных поЯснений длЯ  облегчениЯ  изучениЯ своего содержаниЯ. Џо  этой
причине  Я  полагаю,  что в  будущем  спецификации  будут  состоЯть  как  из
формальных, так и из текстовых описаний.
     „ревнее изречение  предупреждает о том,  что  в  море нельзЯ выходить с
двумЯ хронометрами: нужно взЯть один или три. ’о же, очевидно, применимо и к
текстовым и формальным  определениЯм. …сли имеютсЯ оба вида,  то один должен
быть стандартом,  а другой - производным  описанием, о чем должно быть прЯмо
указано. Ћсновным стандартом может быть любой из них. ‚ Algol  68 в качестве
стандарта выбрано формальное определение, а текстовые  определениЯ  ЯвлЯютсЯ
описательными.  ‚ PL/I стандартом ЯвлЯетсЯ текст, а формальное определение -
производным.  ‚  System/360  также  в  качестве  стандарта принЯт  текст,  а
производными ЯвлЯютсЯ формальные описаниЯ.
     …сть  много средств  созданиЯ  формальных определений.  „лЯ определениЯ
Языков часто  используетсЯ  форма  Ѓэкуса-Ќаура,  по  которой  есть  богатаЯ
литература.2  ‚  формальном  описании PL/I  используютсЯ  новые  обозначениЯ
абстрактного  синтаксиса,  надлежащим образом описанные.3  APL  €версона был
использован длЯ описаниЯ машин, в частности, IBM 70904 и System/360.7 Ѓелл и
Ќьюэлл предложили новые нотации длЯ описаниЯ как конфигураций,  так и машин,
и  проиллюстрировали их  на нескольких машинах, включаЯ DEC PDP-8,6 70906  и
System/360.7
     Џочти  все формальные определениЯ  оказались пригодными длЯ  воплощениЯ
или описаниЯ аппаратных средств или программных систем, внешние спецификации
которых они регламентируют. ‘интаксис  можно описать без этого, но семантика
обычно определЯетсЯ  с помощью программы, выполнЯющей определЯемую операцию.
Љонечно,   это  ЯвлЯетсЯ  реализацией  и  в   этом  качестве  переопределЯет
архитектуру.  Џоэтому  нужно  указать, что формальное определение  относитсЯ
только к внешним спецификациЯм, и объЯснить, что ими ЯвлЯетсЯ.
     Ќе только формальное определение  ЯвлЯетсЯ реализацией, но и реализациЯ
может служить формальным определением. Љогда были созданы первые совместимые
компьютеры, использовалась именно  эта технологиЯ.  ЌоваЯ машина должна была
соответствовать имеющейсЯ.  ђуководство  туманно в некоторых местах? ‡адайте
вопрос  машине!  ‘оздавалась тестоваЯ  программа длЯ  выЯснениЯ поведениЯ, и
новаЯ машина строилась так, чтобы достигалось соответствие.
     ЏрограммнаЯ   модель   аппаратной   или   программной   системы   может
использоватьсЯ  точно  таким  же  образом.  ќто - реализациЯ.  Ћна работает.
Џоэтому  все вопросы,  свЯзанные  с определением, могут  быть  решены  путем
проверки.
     €спользование  реализации   в   качестве  определениЯ  имеет  некоторые
преимущества.  ‚се  проблемы можно  однозначно  решить  путем  эксперимента.
„искуссий не  требуетсЯ, поэтому ответ получаетсЯ  быстро. Ћтвет  может быть
сколь угодно точным и,  по определению, всегда ЯвлЯетсЯ правильным. ‘ другой
стороны,  есть  значительное  количество   недостатков.   ђеализациЯ   может
переопределЯть  даже  внешние  спецификации.  „аже при  ошибочном синтаксисе
всегда  получаетсЯ  некоторый  результат;   в  контролируемой  системе  этот
результат  ЯвлЯетсЯ указанием на ошибку  и <i>ничем больше</i>.  ‚ неконтролируемой
системе  могут   возникнуть  любые  побочные  эффекты  и  быть  использованы
программистами. Љогда мы,  например,  эмулировали  IBM 1401  на  System/360,
выЯвилось  30  различных "курьезов"  -  побочных  эффектов  предположительно
незаконных  операций,  которые  широко  использовались  и должны  были  быть
признаны частью определениЯ.  ђеализациЯ в качестве определениЯ возобладала.
Ћна не только говорила  о том, что должна делать машина, но и многое сказала
о том, как машина не должна была это делать.
     Љроме   того,   на  проницательные  вопросы   реализациЯ  иногда   дает
неожиданные  ответы, и  определение <i>де-факто</i>  часто  оказываетсЯ неизЯщным в
этих  особых   случаЯх  потому,  что  над  ними  никогда  не   задумывались.
Љопирование  этой  неэлегантности  в  другой  реализации  часто  оказываетсЯ
замедлЯющим  или дорогостоЯщим.  Ќапример,  в некоторых  машинах в  регистре
множимого  после  умножениЯ остаетсЯ  мусор.  ’очнаЯ  природа  этого  мусора
становитсЯ  частью  определениЯ   <i>де-факто</i>,  однако  его  копирование  может
помешать использованию более быстрого алгоритма умножениЯ.
     Ќаконец, использование  реализации  в качестве формального  определениЯ
может создать  неЯсность, какое из описаний  - текстовое или формальное  - в
действительности  ЯвлЯетсЯ стандартом. ќто относитсЯ особенно к  программным
моделЯм. ‘ледует  также воздерживатьсЯ от  внесениЯ  изменений в реализацию,
пока она служит в качестве стандарта.
     ЏрЯмое включение
     “ архитекторов программных  систем есть чудесный метод распространениЯ
и  внедрениЯ  определений.  Ћн особенно  полезен  при  установлении  если не
семантики, то  синтаксиса межмодульных  интерфейсов.  ќтот  прием состоит  в
создании  объЯвлений  передаваемых  параметров  или  совместно  используемой
памЯти  и  требовании  включениЯ  этих  объЯвлений   при  операциЯх  времени
компилЯции (макрос или  %INCLUDE  в  PL/I). …сли, кроме того,  все ссылки на
интерфейс  происходЯт  только  по  символическим  именам,  объЯвлениЯ  можно
менЯть, добавлЯЯ или  вставлЯЯ  новые имена и лишь  заново компилируЯ, но не
изменЯЯ использующую его программу.
     Љонференции и суды
     Ќет нужды  говорить  о  том, что совещаниЯ  необходимы.  ‘отни частных
консультаций должны дополнЯтьсЯ крупными  и более формальными собраниЯми. Њы
признали  полезными  два уровнЯ  таких  собраний. Џервый  - это еженедельнаЯ
конференциЯ   всех   архитекторов  вместе  с  официальными   представителЯми
разработчиков аппаратной  и  программной  части  и  сотрудниками  маркетинга
продолжительностью  в половину рабочего днЯ  под  председательством главного
архитектора системы.
     Џредлагать  задачи  и  изменениЯ  можно  всем,  но  обычно  предложениЯ
распространЯютсЯ  в  письменном  виде  до  совещаниЯ.  Ћбычно  новаЯ  задача
некоторое  времЯ обсуждаетсЯ.  “пор делаетсЯ  на  творческой стороне,  а  не
просто  на  принЯтии  решениЯ. ѓруппа пытаетсЯ предложить несколько  решений
проблемы,  затем рЯд предложенных  решений передаетсЯ одному или  нескольким
архитекторам  длЯ разработки подробных и точно сформулированных  предложений
по внесению изменений в руководство.
     Џодробные  предложениЯ  об  изменениЯх  затем  выносЯтсЯ  длЯ  принЯтиЯ
решениЯ.  ЏредложениЯ тщательно изучаютсЯ  исполнителЯми и пользователЯми, и
выЯснЯютсЯ  все "за" и "против".  …сли  возникает  всеобщее согласие, все  в
порЯдке.  ‚ противном случае решение  принимает главный  архитектор. ‚едетсЯ
протокол, и решениЯ формально, оперативно и широко распространЯютсЯ.
     ђешениЯ еженедельных  конференций дают  быстрые результаты  и позволЯют
продолжить  работу.  …сли  кто-то <i>очень</i>  недоволен, допускаетсЯ  немедленнаЯ
апеллЯциЯ к менеджеру проекта, но это происходит очень редко.
     Џлодотворность этих совещаний обусловлена несколькими причинами:
     1. Ћдна и та  же группа  - архитекторы, разработчики и исполнители - на
протЯжении  месЯцев встречаютсЯ  между  собой  каждую  неделю. Ќе  требуетсЯ
времени, чтобы ввести людей в курс дела.
     2.  ѓруппа состоит из предприимчивых, способных, хорошо осведомленных в
вопросах  и глубоко заинтересованных в  конечном результате людей. Ќикто  не
участвует  с  "совещательным" голосом. ‚се  уполномочены принимать  на  себЯ
обЯзательства.
     3.  Џри  возникновении проблем решениЯ  ищутсЯ  как  внутри, так и  вне
очевидных границ.
     4.  ЃлагодарЯ  формализму   письменных  предложений   сосредоточиваетсЯ
внимание,  требуетсЯ   принЯтие  решениЯ  и  устранЯетсЯ  несогласованность,
свойственнаЯ черновым решениЯм комиссий.
     5. Ћткрытое предоставление права принЯтиЯ  решениЯ главному архитектору
помогает избежать поиска компромиссов и задержек.
     ‘о  временем  выЯснЯетсЯ,  что  некоторые  решениЯ  не  в  полной  мере
выполнЯютсЯ.  ’от  или  иной  из  участников  так  и  не принЯл  всей  душой
какую-либо  мелочь.  „ругие  решениЯ  породили  непредвиденные  проблемы,  и
еженедельное совещание отказываетсЯ повторно их рассматривать. ’ак возникает
хвост  из  мелких  возражений,  открытых   тем   или  раздражениЯ.   „лЯ  их
урегулированиЯ  мы  проводим  ежегодные  "сессии  верховного  суда",  обычно
продолжающиесЯ две недели. (…сли бы Я  проводил их сейчас, то  делал бы  это
раз в полгода.)
     ќти сессии  проводились  накануне  важных  дат  окончательного принЯтиЯ
разделов руководства. Џрисутствовали не только представители программистов и
проектировщиков по архитектуре, но и менеджеры программных,  маркетинговых и
реализационных проектов.  Џредседательствовал менеджер  проекта  System/360.
Џовестка работы  включала  обычно  около  200  пунктов, в  основном  мелких,
перечисленных в развешанных по комнате  списках. ‡аслушивались все стороны и
принимались  решениЯ.  ЃлагодарЯ  чуду компьютерной верстки  (и превосходной
работе сотрудников) каждое утро каждый участник обнаруживал на своем рабочем
месте  исправленное руководство, в  которое  были внесены  решениЯ, принЯтые
накануне.
     ќти "осенние фестивали" были полезны  не только длЯ пересмотра решений,
но и длЯ того,  чтобы они были принЯты. Љаждый был  услышан, каждый принимал
участие,  каждый  лучше  понимал  сложные  ограничениЯ и  взаимосвЯзи  между
решениЯми.
     Њножественные реализации
     “ архитекторов System/360 было два почти беспрецедентных преимущества:
достаточно времени  длЯ тщательной работы и  такое же политическое  влиЯние,
как  у проектировщиков. Ќаличие  времени  было  обеспечено графиком по новой
технологии;  политическое  равенство  происходило  благодарЯ  одновременному
созданию нескольких реализаций. Ќеобходимость их строгой совместимости лучше
всего способствовала исполнению спецификаций.
     ‚  большинстве компьютерных проектов наступает день, когда оказываетсЯ,
что машина и руководство по ее использованию  не  согласуютсЯ. ‚ последующем
конфликте  обычно  проигрывает  руководство,  поскольку его  можно  изменить
значительно быстрее  и меньшей ценой,  чем  машину. Ћднако  это не так, если
существует  несколько  реализаций. ’огда  временные  и  финансовые издержки,
свЯзанные с исправлением машины с ошибками, могут быть ниже, чем свЯзанные с
переделкой машин, верно следовавших руководству.
     ќто  замечание   можно  с  пользой   применить  при  определении  Языка
программированиЯ.  Њожно  с  уверенностью  утверждать, что  рано или  поздно
потребуетсЯ создать несколько  интерпретаторов  или  компилЯторов длЯ разных
целей. Ћпределение будет Яснее,  а дисциплина более крепкой, если изначально
строЯтсЯ как минимум две реализации.
     †урнал регистрации телефонных разговоров
     Љакими  бы  точными  не  были  спецификации,  по  ходу проектированиЯ
возникает несчетное множество вопросов касательно интерпретации архитектуры.
Ћчевидно,  многие из этих вопросов требуют более Ясного изложениЯ  в тексте.
Џрочие просто отражают неправильное понимание.
     ‚ажно, чтобы озадаченные исполнители звонили ответственным архитекторам
и задавали вопросы, а не продолжали работу на основании догадок. ‚ажно также
понимать,  что ответы на  такие  вопросы ЯвлЯютсЯ <i>авторитетными</i>  заЯвлениЯми
архитекторов и должны доводитьсЯ до всех.
     Џолезным  механизмом  ЯвлЯетсЯ ведение архитектором журнала регистрации
телефонных  разговоров, в который  им заносЯтсЯ все вопросы и ответы. Љаждую
неделю журналы нескольких архитекторов объединЯютсЯ  воедино, размножаютсЯ и
распределЯютсЯ  среди  пользователей   и   исполнителей.  ЌесмотрЯ  на  свою
неформальность, такой механизм ЯвлЯетсЯ и быстрым, и понЯтным.
     ’естирование продукта
     ‹учший друг менеджера проекта  - его постоЯнный противник, независимаЯ
организациЯ,  тестирующаЯ продукт.  ѓруппа  проверЯет  соответствие  машин и
продуктов  спецификациЯм  и  выступает  пособником дьЯвола,  указываЯ на все
замеченные дефекты и несоответствиЯ. Љаждой организации, ведущей разработки,
нужна  такаЯ  независимаЯ  группа  технического аудита, котораЯ  должна быть
неподкупна.
     Џоследний  анализ  в   качестве  независимого   аудитора   осуществлЯет
покупатель. ‚  безжалостном  свете  практического  применениЯ  станет  виден
каждый  огрех.  ѓруппа тестированиЯ  продукта как  раз заменЯет  покупателЯ,
настроенного на поиск ошибок. ‚ремЯ  от времени тщательнаЯ проверка продукта
обнаруживает места, где  не услышали указание, где  проектные решениЯ понЯли
неправильно или выполнили неточно. Џоэтому такаЯ группа проверЯющих ЯвлЯетсЯ
необходимым  звеном  в  цепочке,  по которой  доходит слово  проектировщика,
звеном,   которое   должно  начать   действовать   рано  и   одновременно  с
проектированием.

        ѓлава 7. Џочему не удалось построить ‚авилонскую башню?
     <i>Ќа всей земле был
один Язык и одно наречие. „винувшись с востока, они  нашли в  земле  ‘еннаар
равнину и  поселились там. € сказали друг другу: наделаем кирпичей и обожжем
огнем. € стали у них кирпичи вместо камней, а землЯнаЯ смола вместо извести.
€ сказали они: построим себе город и башню, высотою до небес, и сделаем себе
имЯ прежде, нежели рассеемсЯ по лицу всей земли.  € сошел ѓосподь посмотреть
город и башню, которые строили  сыны человеческие.  €  сказал ѓосподь:  вот,
один  народ, и один у всех Язык; и вот что  они начали делать, и не отстанут
они от того, что задумали делать; сойдем же и смешаем там Язык их, так чтобы
один не понимал речи другого.  € рассеЯл их ѓосподь оттуда по  всей земле; и
они перестали строить город [и башню].
     ЉЌ€ѓЂ Ѓ›’€џ 11:1-8</i>
     <b>Ђудит менеджмента ‚авилонского проекта</b>
     ‘огласно Љниге бытиЯ, ‚авилонскаЯ башнЯ была вторым крупным инженерным
предприЯтием человека после Ќоева  ковчега.  ‚авилонскаЯ башнЯ  стала первым
инженерным фиаско.
     ќта  историЯ глубока и  поучительна в нескольких  отношениЯх.  „авайте,
однако, рассмотрим ее как  чисто технический проект и посмотрим, какие уроки
администрированиЯ  можно  из  нее  извлечь.  Ќасколько  хорошо   проект  был
обеспечен необходимыми составлЯющими успеха? €мелись ли:
     1. <i>џсность цели?</i>  „а, хотЯ и  наивно  недостижимой.  Џроект  провалилсЯ
задолго до того, как столкнулсЯ с эти принципиальным ограничением.
     2. <i>—еловеческие ресурсы?</i> ‚ большом числе.
     3. <i>Њатериалы?</i> ѓлина и битум в изобилии имеютсЯ в Њесопотамии.
     4.  <i>„остаточно  времени?</i>  „а, нет  никаких указаний  на ограничениЯ  по
времени.
     5.  <i>Ђдекватные  технологии?</i> „а,  пирамидальной или конической структуре
присуща устойчивость  и  хорошее  распределение  нагрузки  сжатиЯ. Ћчевидно,
свойства каменной кладки были хорошо  известны.  Џроект провалилсЯ  до того,
как вышел за пределы технологических ограничений.
     ’ак почему же провалилсЯ проект, если все это у них было? —его у них не
хватало?  „вух вещей - <i>обмена информацией</i> и вытекающей  из него <i>организации</i>.
Ћни  не  могли  разговаривать друг с другом и, как следствие,  согласовывать
усилиЯ. Љогда  отказала  координациЯ, работа  встала. —итаЯ  между строк, мы
обнаруживаем, что  отсутствие обмена информацией привело  к  спорам, дурному
настроению и взаимной ревности. ‚скоре  кланы начали расходитьсЯ,  предпочтЯ
обособленность спорам.
     Ћбмен информацией в большом программном проекте
     ‚   наше   времЯ  происходит  тоже  самое.  Ћтставание  от  графика,
несоответствие функциональности, системные ошибки - все это из-за  того, что
леваЯ рука не  знает, что творит праваЯ.  Џо ходу работы участвующие  в  ней
несколько  бригад  понемногу изменЯют функции,  размер, быстродействие своих
программ, Явно или  косвенно  менЯют допущениЯ относительно входных данных и
использованиЯ выходных.
     Ќапример,  исполнитель  функции,   осуществлЯющей  оверлейную  загрузку
программ,   может  столкнутьсЯ  с  проблемами   и  снизить   быстродействие,
основываЯсь на статистических данных, указывающих на  редкость использованиЯ
этой  функции в  прикладных  программах.  ‚  то  же  времЯ  его сосед  может
разрабатывать важную часть супервизора таким образом, что она крайне зависит
от скорости  выполнениЯ этой функции. ќто  изменение  скорости выполнениЯ, в
сущности,  становитсЯ  значительным  изменением  спецификаций,  о  нем нужно
широко объЯвить и оценить с точки зрениЯ системы.
     Љак  же  должны бригады обмениватьсЯ  между  собой  информацией?  ‚семи
возможными способами:
     -   <i>Ќеформально</i>.   •орошаЯ   телефоннаЯ  свЯзь  и   Ясное   определение
взаимозависимостей  между  бригадами  должны  способствовать  многочисленным
телефонным переговорам, от  которых  зависит  единаЯ  интерпретациЯ печатных
документов.
     -   <i>‘овещаниЯ</i>.  ЌельзЯ   переоценить  значение   регулЯрных   совещаний
участников  проекта с поочередным заслушиванием  технических отчетов бригад.
’аким путем устранЯютсЯ сотни мелких непониманий.
     - <i>ђабочаЯ тетрадь</i>. ‚  самом начале  нужно завести рабочую тетрадь учета
проделанной работы. ќта тема заслуживает отдельного раздела.
     <b>ђабочаЯ тетрадь проекта
     —то</b>. ђабочаЯ тетрадь проекта ЯвлЯетсЯ не столько  отдельным документом,
сколько структурой,  налагаемой на все  документы, которые  будут созданы во
времЯ выполнениЯ проекта.
     <i>‚се</i> документы проекта должны входить  в  эту структуру,  включаЯ  цели,
внешние  спецификации,  спецификации  интерфейсов,  технические   стандарты,
внутренние спецификации и административные записки.
     <b>Џочему</b>.  ’ехнологический  документ практически вечен. …сли  исследовать
генеалогию   руководства  пользователЯ   по  какому-нибудь  аппаратному  или
программному  продукту, можно  проследить не  только идеи,  но  и  множество
отдельных  предложений  и параграфов,  вплоть  до  первой  памЯтной записки,
предлагающей  продукт   или  поЯснЯющей  первый   проект.   „лЯ  составителЯ
документации ножницы и клей - такаЯ же важнаЯ вещь, как перо.
     ђаз это так, и завтрашние руководства длЯ готового продукта развиваютсЯ
из  сегоднЯшних памЯтных записок, очень важно правильно определить структуру
документации.   ђазработка  рабочей  тетради  проекта   на   ранних   этапах
обеспечивает продуманную, а не случайную структуру документации. Ѓолее того,
задание структуры позволЯет  составленные позднее документы оформить  в виде
отрывков, которые вписываютсЯ в эту структуру.
     ‚торой  причиной  длЯ ведениЯ  рабочей тетради  ЯвлЯетсЯ  необходимость
управлениЯ   процессом  распространениЯ  информации.  ‡адача  состоит  не  в
ограничении доступа к информации, а в том, чтобы соответствующаЯ  информациЯ
достигла всех, кому она может понадобитьсЯ.
     Џервым  делом  следует пронумеровать  все  памЯтные записки,  так чтобы
имелись  упорЯдоченные списки названий,  и каждый работник  мог  убедитьсЯ в
наличии  необходимых   ему  материалов.  ЋрганизациЯ  рабочей  тетради  идет
значительно  дальше, устанавливаЯ  древовидную  структуру  памЯтных записок.
„ревовиднаЯ   структура   позволЯет,   если   нужно,  организовать  доставку
информации соответственно поддеревьЯм.
     <b>Њеханика</b>. Љак и во  многих  задачах управлениЯ программными  проектами,
проблема  технических  меморандумов усложнЯетсЯ  нелинейным образом  по мере
увеличениЯ  объема данных. …сли в работе  участвуют  10  человек,  документы
можно  просто  пронумеровать. …сли участвуют  100  человек, часто достаточно
нескольких  линейных  последовательностей.  „лЯ 1000 сотрудников,  неизбежно
разбросанных    по   нескольким    площадкам,   возрастает   <i>потребность</i>   в
структурированной  рабочей  тетради, и, следовательно, возрастает ее  <i>объем</i>.
Љак поступать в этом случае?
     џ думаю,  мы  правильно  поступили при работе над  проектом OS/360.  Ќа
необходимости хорошо структурированной рабочей тетради особенно настаивал Ћ.
‘.  ‹окен,  который  убедилсЯ  в  ее  эффективности  при  работе  над  своим
предыдущим проектом, - операционной системой 1410-7010.
     Њы  быстро  принЯли  решение,  что  <i>каждый</i>   программист  должен  иметь
возможность видеть  <i>весь</i>  материал,  т.е.  должен  иметь  экземплЯр  рабочей
тетради в своем офисе.
     ђешающее  значение  имеет  своевременное  обновление.  ђабочаЯ  тетрадь
должна  отражать текущее  состоЯние проекта.  ќто очень трудно  осуществить,
когда длЯ внесениЯ обновлений нужно перепечатывать целые документы. Ћднако в
тетради  с  вынимающимисЯ листами достаточно заменить отдельные  страницы. “
нас  имелась   компьютернаЯ  система   редактированиЯ   текста,  оказавшаЯсЯ
бесценной  длЯ своевременного  обновлениЯ.  Ћфсетные  формы  изготавливались
непосредственно на принтере, и  цикл обработки составлЯл меньше  одного днЯ.
Џеред получателем  всех  этих обновленных  страниц встает,  однако, проблема
усвоениЯ.  Љогда  он  впервые получает обновленную  страницу, то  ему  нужно
знать,  что  было изменено.  Љогда он  позже  обращаетсЯ к ней, то ему нужно
знать, какое определение действительно на текущий день.
     Џоследнюю    потребность    удовлетворЯет   непрерывность    обновлениЯ
документации.  —тобы  выделить изменениЯ, требуютсЯ другие меры.  ‚о-первых,
нужно  отметить  на  странице   измененный   текст,   например,  с   помощью
вертикальной  линии на полЯх рЯдом  с каждой измененной строчкой. ‚о-вторых,
необходимо вместе с измененными страницами  распространЯть краткую отдельную
сводку с перечислением изменений и характеристикой их значениЯ.
     Ќаш проект не перешел  и шестимесЯчного рубежа, когда  мы столкнулись с
другой проблемой.  ’олщина рабочей  тетради составила <i>около</i> полутора метров!
…сли бы мы сложили в одну стопку требующиесЯ программистам 100 экземплЯров в
своих помещениЯх  зданиЯ Time-Life в Њанхеттене, она бы  превысила по высоте
само здание. Љроме того, ежедневные  исправлениЯ  имели толщину  больше пЯти
сантиметров  и насчитывали около 150  страниц, которые надо  было  заменить.
Џоддержка  рабочей  тетради стала  занимать значительную  часть  ежедневного
рабочего времени.
     ‘ этого времени мы перешли на микрофиши, что  сберегло миллион долларов
даже с учетом стоимости  устройств длЯ чтениЯ микрофишей в каждом  офисе. Њы
смогли  достичь  отличной продолжительности цикла  производства  микрофишей.
ђабочаЯ тетрадь уменьшилась в объеме с 90  дм3 до 5 дм3 и, что  более важно,
обновлениЯ  выпускались  порциЯми   по  сотне  страниц,  стократно  уменьшаЯ
сложность замены листов.
     Њикрофиши имеют свои  недостатки.  ‘ точки зрениЯ менеджера, неудобство
замены  бумажных страниц  гарантировало, что  их прочтут, длЯ  чего и велась
рабочаЯ тетрадь. Њикрофиши слишком облегчили задачу ведениЯ рабочей тетради,
если  только  они  не  сопровождались печатным  документом  с  перечислением
изменений.
     Љроме  того, микрофиши  не  позволЯют читателю легко делать  выделениЯ,
пометки  и  комментарии. „окументы, с  которыми  читатель  работал, приносЯт
больше пользы  автору  и читателю.  ‚звешиваЯ все, Я полагаю, что  микрофиши
ЯвлЯютсЯ очень удачной технологией,  и длЯ очень крупных проектов Я бы отдал
им предпочтение перед бумажной рабочей тетрадью.
     <b>Љак  можно осуществить это сегоднЯ?</b> ‘егоднЯшние системные технологии, Я
думаю,  делают  предпочтительнее  ведение рабочей  тетради  в  файле прЯмого
доступа  с  полосками,  помечающими  измененные  части,  и  датами  внесениЯ
изменений.  ‹юбой пользователь  может  обратитьсЯ к  журналу  с  дисплейного
терминала. ‘водка изменений, готовЯщаЯсЯ ежедневно,  должна хранитьсЯ в виде
стека  (LIFO) с установленной точкой доступа. Џрограммист может ежедневно ее
читать,  но если  он пропустил один  день,  ему  придетсЯ  дольше  читать на
следующий день. ЏрочтЯ об изменениЯх, он  может  прерватьсЯ  и  прочесть сам
измененный текст.
     Ћбратите внимание, что сама  рабочаЯ тетрадь остаетсЯ  неизменной.  Ћна
по-  прежнему  остаетсЯ  собранием всей  проектной  документации,  тщательно
организованной. …динственное изменение - механизм распределениЯ  доступа. „.
‘.   ќнглебарт   с   коллегами   создали   такую  систему   в   ‘тэнфордском
исследовательском институте и используют ее длЯ ведениЯ документации по сети
ARPA.
     „.  ‹.  Џранас  и  “ниверситета   Љарнеги-Њелона  предложил  еще  более
радикальное решение.1 Ћн полагает, что производительность программиста  выше
всего, когда он огражден от подробностей конструкции тех частей системы, над
которыми он не работает.  ќто предполагает, что все интерфейсы  полностью  и
точно заданы.  ’акой проект  определенно  хорош, но  если полагатьсЯ на  его
идеальное осуществление, это  приведет к катастрофе.  •орошаЯ информационнаЯ
система не  только должна выЯвлЯть ошибки в интерфейсах, но и способствовать
их исправлению.
     ЋрганизациЯ крупного программного проекта
     …сли  над  проектом  работает  <i>n</i>  человек,  то   существует  <i>(n2-n)/2</i>
интерфейсов, через  которые может  происходить обмен данными, и потенциально
существует почти 2<i>n</i> групп, внутри  которых  должно происходить согласование.
–ель организации  работы состоит  в сокращении  необходимого  объема  обмена
информацией  и согласованиЯ.  Џоэтому  создание  правильной  организационной
структуры  ЯвлЯетсЯ  решающим направлением  решениЯ  проблем информационного
обмена, рассматривавшихсЯ выше.
     ‘пособы,  которыми сокращаетсЯ обмен  информацией, - <i>разделение труда</i> и
<i>специализациЯ  функций</i>.   „ревовиднаЯ  организационнаЯ   структура  отражает
уменьшение  потребности в  подробном  обмене  информацией при  использовании
разделениЯ труда и специализации.
     ‚   действительности,  организациЯ  в   виде   дерева   возникает   как
структуризациЯ полномочий  и  ответственности.  Џринцип, что никто  не может
быть   слугой  двух  господ,  требует,   чтобы   структура  полномочий  была
древовидной. Ћднако  структура обмена  информацией  не  столь  ограничена, и
дерево  ЯвлЯетсЯ  мало  пригодным приближением  структуры  общениЯ,  котораЯ
ЯвлЯетсЯ   сетью.   Ќеадекватность  приближениЯ   деревом  служит   причиной
возникновениЯ  бригад, целевых групп, комиссий и даже организаций матричного
типа, существующих во многих инженерных лабораториЯх.
     ђассмотрим   древовидную    организацию   программистов   и   исследуем
существенные характеристики, которыми должны обладать поддеревьЯ, чтобы быть
эффективными. ’аковыми ЯвлЯютсЯ:
     1 - задание,
     2 - продюсер,
     3 - технический директор или архитектор,
     4 - график работ,
     5 - разделение труда,
     6 - определение интерфейсов между разными частЯми.
     ‚се перечисленное очевидно и обычно, исключаЯ различие между продюсером
и техническим директором. ‘начала  рассмотрим сами эти две функции, а  затем
их взаимоотношениЯ.
     ‚  чем назначение продюсера? Ћн собирает бригаду, распределЯет работу и
устанавливает график ее выполнениЯ. Ћн  занимаетсЯ приобретением необходимых
ресурсов. ќто  означает,  что большаЯ часть его  функций состоит в  общении,
которое направлено вне бригады,  - вверх и в стороны. Ћн устанавливает схему
свЯзи и предоставлениЯ отчетности внутри бригады.  Ќаконец, он  обеспечивает
выполнение  графика,  осуществлЯЯ  маневр  ресурсами и  менЯЯ организацию  в
соответствии с новыми обстоЯтельствами.
     Ђ что же технический директор? Ћн постигает проект, который должен быть
реализован, выЯвлЯет его составлЯющие,  определЯет,  как  он будет выглЯдеть
внешне, и  делает эскиз внутренней  структуры.  Ћн  обеспечивает единство  и
концептуальную  целостность проекта в  целом  и таким  образом  способствует
ограничению  сложности  системы.  Џри  возникновении технических проблем  он
изыскивает их решениЯ  или при необходимости изменЯет системный проект.  Ћн,
согласно прелестному  выражению  Ђла  Љаппа,  ЯвлЯетсЯ  "своим  человеком  в
паршивых делах". Ћбщение его происходит  преимущественно внутри команды. …го
работа почти исключительно техническаЯ.
     ’еперь  видно,  что длЯ этих двух  функций требуютсЯ совершенно  разные
способности. ‘пособности встречаютсЯ в  разных сочетаниЯх, и отношениЯ между
продюсером  и  директором должны определЯтьсЯ теми конкретными  сочетаниЯми,
которыми они  обладают. Ќе люди должны быть  втиснуты в  чисто теоретические
организационные формы,  а организациЯ должна  строитьсЯ  вокруг  тех  людей,
которые есть.
     ‚озможны  три  типа  отношений,  и все  они  с  успехом встречаютсЯ  на
практике.
     <b>Ћдно и то  же  лицо может быть продюсером и техническим директором.</b> ќто
вполне  оправдано  в  маленьких командах,  насчитывающих  от  трех до  шести
программистов. ‚ более крупных проектах это  очень редко осуществимо по двум
причинам. ‚о-первых,  редко  встречаютсЯ люди,  сочетающие  в  себе  большие
административные и  технические способности.  Њыслители  встречаютсЯ  редко,
практики еще реже, но реже  всего - мыслители-практики. ‚о-вторых, в больших
проектах выполнение каждой  из функций требует полного рабочего днЯ или даже
больше.  Џродюсеру  трудно   передать  кому-либо  достаточную  часть   своих
обЯзанностей,  чтобы  высвободить  времЯ длЯ  технической работы.  „иректору
невозможно  передать  свои  обЯзанности,  не  наносЯ  ущерба  концептуальной
целостности проекта.  <b>Џродюсер может быть  начальником,  а  директор  -  его
правой  рукой.</b>  ‘ложность здесь состоит  в том, чтобы определить  <i>полномочиЯ</i>
директора  при принЯтии технических решений, с тем чтобы  он не тратил  свое
врем