Мифический человеко-месяц

      Последнее возражение касается распределения времени и этапов работы. Первый ответ, приходящий на ум, заключается в том, что не нужно нанимать разработчиков до тех пор, пока не будут готовы спецификации. Именно так поступают при строительстве здания.
      Однако в системном программировании темпы выше и график очень уплотнен. Насколько можно совместить этапы создания спецификаций и самого строительства?
      Как подчеркивает Блау, в творческой деятельности выделяются три различные этапа: архитектура, разработка и реализация. На практике оказывается, что все этапы могут начинаться одновременно и проходить параллельно.
      При проектировании вычислительной машины, например, разработчик уже может начинать работу, даже если он имеет довольно смутные представления о принципах действия, несколько более ясные технологические идеи и четко определенные понятия о стоимости и производительности. Он может начать проектировать информационные связи, управляющие последовательности, принципы компоновки п т. д. Он придумывает пли совершенствует средства, которые ему потребуются, особенно систему документирования, включая систему автоматизации проектирования.
      Одновременно может проходить разработка и устранение недостатков у интегральных схем, плат, кабелей, стоек, источников питания, запоминающих устройств и т. д., и составляться документация для них.
      Эта работа выполняется параллельно с созданием архитектуры и ее реализацией.
      Аналогично обстоит дело и при проектировании систем программирования. Задолго до того, как завершены спецификации, у разработчика уже много дел. Обладая некоторыми приблизительными сведениями о функциях системы, которые получат свое отражение во внешних спецификациях, он уже может действовать. Он должен точно знать поставленные ему сроки и отведенные средства. Он должен знать машину, на которой будут пропускаться его программы. Далее он может приступить к разработке сопряжения модулей, структуры таблиц, алгоритмов, распределению работы по фазам. Некоторое время следует затратить на установление контактов с архитекторами.
      Кроме того, и здесь на уровне реализации также много параллельной работы. В программировании тоже есть технология. Если машина новая, то предстоит большая работа с подпрограммами, супервизором, алгоритмами поиска и сортировки7).
      Концептуальное единство действительно требует, чтобы система отражала единую философию и чтобы спецификации в том виде, в каком они доходят до пользователя, исходили от нескольких человек. Реалъное разделение труда на архитектуру, разработку и реализацию вовсе не означает, чуб на создание системы в целом, спроектированной таким образом, потребуется больше времени. Опыт показывает обратное, а именно, отдельные модули быстрее объединяются в систему, и на се отладку требуется меньше времени. Таким образом, широко распространенное горизонтальное разделение труда сокращается за счет вертикального разделения труда, при этом существенно упрощается обеспечение связи и повышается концептуальное единство проекта.
      V. ЭФФЕКТ ВТОРОЙ СИСТЕМЫ
      Если ответственность за функциональные спецификации отделить от ответственности за быстрое создание дешевого конечного продукта, то как поставить пределы творческому энтузиазму архитектора?
      Фундаментальное решение этой проблемы заключается в установлении тесной, последовательной и основанной на симпатиях связи между архитектором и разработчиком. Но есть и более тонкий ее аспект, обычно ускользающий от нашего внимания.
      Принципы совместной работы
      Архитектор сооружения занимается финансовой сметой, используя собственные методы оценки, которые позже утверждаются подрядчиком, или же последний вносит в них свои коррективы. Часто оказывается, что величина затрат, определяемая подрядчиком, не укладывается в смету. Архитектору приходится тогда пересматривать свои методы оценки с точки зрения увеличения сметы и свой проект с точки зрения его удешевления. Однако он может предложить подрядчикам способы более дешевой реализации проекта, чем разработанные ими.
      В аналогичной ситуации находится архитектор вычислительной системы или системы программирования. Он обладает, однако, тем преимуществом, что подрядчики сообщают ему свои цены на гораздо более ранних этапах проекта: ахитектор может практически в любой момент потребовать от них сведения о затратах. Но он обычно испытывает неудобства из-за необходимости работать только с одним подрядчиком, который может повышать или понижать свои цены в зависимости от степени удовлетворенности проектом. На практике ранняя и постоянная связь помогает архитектору иметь нужные данные о затратах, а разработчику - осуществлять непосредственное знакомство с проектом, при этом/различия в обязанностях не стираются.
      Если архитектор оказался перед проблемой завышенных оценок, у него два выхода: урезать проект пли оспорить оценки, предложив более дешевую реализацию. Последний путь эмоционально очень опасен. Архитектор оспаривает метод выполнения работы строителя, предложенный самим строителем. Чтобы он привел к успеху, архитектор должен:
      * помнить, что строитель несет творческую ответственность за реализацию, поэтому архитектор предлагает, но не приказывает;
      * быть готовым к тому, чтобы предложить свой способ реализации продукта, спецификацию которого он написал, \i к тому, чтобы принять любой другой способ, если последний отвечает поставленным задачам;
      * выдвигать такие предложения спокойно, в узком кругу;
      * уметь отказываться от предлагаемых улучшенхщ. Обычно строитель начинает противиться предлагаемым изменениям в архитектуре. И зачастую он прав - какая-нибудь незначительная деталь может оказаться неожиданно дорогой в процессе реализации.
      Самодисциплина. Эффект второй системы
      В своей первой работе архитектор обычно проявляет умеренность и аккуратность. Он знает, что он не знает того, что делает, а потому делает это тщательно и держит себя "в рамках".
      В процессе работы над своим первым проектом ему приходят па ум всякого рода находки и украшательства. Все они откладываются "до следующего раза". Рано или поздно работа над первой системой приходит к концу, и архитектор, преисполненный уверенности и продемонстрировавший свое мастерство на системах этого класса, готов заняться второй системой.
      Эта вторая система - самая опасная из всех, которые когда-либо проектирует человек. Когда он будет делать следующие, опыт прежних разработок позволит ему установить общие характеристики таких систем, а различия между ними укажут на конкретные детали, не обобщаемые и не распространяющиеся на все системы.
      Общая тенденция Заключается в создании сверхпроекта второй системы, путем использования всех идей и находок, от которых предусмотрительно отказались в первой. В результате, как сказал Овидии, получается "большая куча". Рассмотрим в качестве примера архитектуру ЭВМ IBM-709, позже воплотившуюся в модели IBM-7090. Это - вторая система по отношению к очень удачной IBM-704. Набор операций в модели IBM-709 настолько велик и разнообразен, что едва ли половина из них регулярно используется.
      Еще более убедительный пример являет собой архитектура, разработка и даже реализация вычислительной машины Stretch, в которых нашли выход ранее сдерживаемые стремления многих людей к изобретательству, и которая была второй системой для большинства из них. Как говорит Стрейчив своем обзоре, "у меня создалось впечатление, что в известном смысле проект Stretch последнее звено в цепи развития. Как и некоторые предыдущие разработки, он в высшей степени хитроумен, в высшей степени усложнен, крайне эффективен, но в то же самое время он в чем-то не продуман, расточителен и неэлегантен, и чувствуется, что существуют гораздо лучшие способы создания таких вещей))1).
      Операционная система OS/360 была второй системой для большинства ее разработчиков. В этот коллектив вошли создатели таких разных проектов, как операционная система DOS/1410-7010, операционная система Stretch, система реального времени в проекте Mercury и IBSYS для IBM-7090. Но почти никто из них не имел опыта создания двух операционных систем 2). Таким образом, OS/360 - это чистый пример эффекта второй системы, своего рода stretch*) в искусстве системного программирования, и к ней равно относятся и похвалы, и порицания Стрейчи.
      Например, в OS/360 отводится 26 байтов оперативной памяти для постоянно хранящейся в ней программы, предназначенной для обработки даты "31 декабря" в високосном году (когда 366 дней). А это можно было бы оставить оператору.
      Эффект второй системы имеет и другое проявление, отличное от чисто функциональных украшательств. Это - тенденция к усовершенствованию методов, само существование /которых становится ненужным из-за изменений /в исходных посылках системы. OS/360 может /^ать много примеров такого рода. //
      Рассмотрим редактор связей, предназначенный для загрузки отдельно оттранслированных программ и обработки перекрестных ссылок. Кроме своих основных функций, он осуществляет также статистическую сегментацию программы. Это - одно из самых лучших средств сегментации, когда-либо придуманных. Оно позволяет осуществлять внешнюю сегментацию во время работы редактора связей, а не вводить ее в исходную машинную программу, что дает возможность менять структуру сегментов от прогона к прогону без повторной трансляции. Тем самым обеспечивается богатый набор полезных вариантов и возможностей. В определенном смысле это - кульминация развития метода статистической сегментации.
      Но одовременно это и последний из динозавров. Дело в том, что это средство принадлежит системе, в которой мультипрограммирование является нормальным режимом работы, а динамическое распределение памяти - исходной посылкой, что находится в прямом противоречии с идеей использования статистической сегментации. Насколько лучше работала бы система, если усилия, затраченные на управление сегментацией, были бы направлены на то, чтобы осуществлять динамическое распределение памяти и динамические перекрестные ссылки по-настоящему быстро.
      Далее, сам редактор связей требует такого большого объема памяти и содержит так много своих собственных сегментов, что если даже использовать его только для связи без управления сегментацией, то он работает медленнее большинства трансляторов. По иронии судьбы, сам редактор связей создавался для того, чтобы избежать ретрансляции. Как у конькобежца туловище опережает ноги, так и усовершенствования продолжаются до тех пор, пока исходные посылки системы не останутся позади.
      Другим примером этой тенденции служит средство отладки Testran. Это высшая точка развития средст пакетной отладки, обладающая действительно элегантными возможностями моментальной выдачи и распечатки памяти. Testran использует концепцию управляющей секции и простой\метод избирательной трассировки и получения выдач\ памяти без накладных расходов или ретрансляции. Творческие концепции операционной системы Share для IBM-709 расцвели здесь пышным цветом3). Тем временем сама идея отладки в пакетном режиме без ретрансляции устарела. Диалоговые вычислительные системы,\ используя языковые интерпретаторы или интерпретирующие компиляторы, обеспечили наиболее фундаментальные преимущества. Но даже в системах пакетной обработки появление "быстро транслирующих-медленно выполняющих" трансляторов привело к тому, что предпочтение стало отдаваться методам отладки и выдачам памяти па внешнем уровне. Насколько лучше была бы система, если вместо создания Testran'a все усилия были бы направлены на разработку диалоговых средств и быстрой трансляции.
      Еще одним аналогичным примером является планировщик, обеспечивающий превосходные возможности управления фиксированным потоком задач в пакетном режиме. На самом деле этот планировщик представляет собой улучшенную, усовершенствованную и приукрашенную вторую систему, созданную вслед за операционной системой DOS/1410-7010. Это - система пакетной обработки, не мультипрограммная, за исключением ввода/вывода, и предназначенная в основном для коммерческих приложений. В этом качестве планировщик OS/360 хорош. Но он почти совсем не удовлетворяет потребностям дистанционного ввода задач, мультипрограммирования и резидентных диалоговых подсистем, реализованным в OS/360.
      Как архитектору избежать эффекта второй системы? Очевидно, что просто перескочить через свою вторую систему ему не удастся. Но он может помнить об опасностях этой системы и повысить самодисциплину с тем, чтобы уметь отказаться от функциональных излишеств и избежать экстраполяции тех функций, которые не сохраняются при изменении основных идей и назначения системы.
      Чтобы не потерять бдительности, советуем архитектору присвоить каждой, даже самой малой, функции следующий показатель: средство х должно стоить не больше, чем т байтов памяти и п микросекунд.
      Эти показатели подскажут исходные решения и в процессе реализации будут и указанием, и предостережением.
      Как руководитель проекта может избежать эффекта второй системы? Во-первых, он должен проследить за тем, чтобы для главного архитектора эта система была, по меньшей мере, третьей. Кроме того, руководитель, зная о соблазнах, может вовремя проверить, насколько полно исходные концепции и поставленные задачи нашли свое отражение в подробно разработанном проекте.
      VI. ПУТЬ СЛОВА
      "Он сядет здесь и будет распоряжатъся: Сделайте то! Сделайте это!-- Но абсолютно ничто не сдвинется с места".
      (Г. С. Т р у м е н. "О президентской власти")
      Допустим, что в распоряжении руководителя есть несколько дисциплинированных и опытных архитекторов и большой коллектив разработчиков. Как руководитель сможет добиться того, чтобы все разработчики услышали, поняли и реализовали решения, предложенные архитекторами? Каким образом группа из 10 архитекторов сможет обеспечить концептуальное единство системы, которую создают 1000 человек? Целая технология, позволяющая это осуществить, была разработана для проекта Системы 360, и она равно приложима к проектам создания программного обеспечения.
      Письменные спецификации - руководство
      Руководство, пли письменная спецификация, является необходимым инструментом, хотя п недостаточным. Руководство - это внешняя спецификация конечного продукта. Оно описывает каждый элемент системы с точки зрения пользователя и предписывает его поведение. И как таковое представляет собой основной результат работы архитектора.
      Круг за кругом проходит процесс его подготовки, и в это время обратная связь с пользователями и разработчиками показывает, где проект неудобен для использования или реализации. Для разработчиков важно, чтобы все изменения квантовались, т. е. в графике отмечались датированные версии.
      Руководство должно описывать только все то, что видит пользователь, в том числе все сопряжения; оно не должно содержать описания того, что не видно пользователю. Этим занимается разработчик, и здесь его творческая свобода не должна ничем сковываться. Архитектор всегда должен быть готов -показать пример реализации того свойства, которое он описывает, но ему не следует и пытаться навязывать конкретную реализацию.
      Изложение должно быть точным, полным и очень подробным. Часто пользователь будет обращаться только к одному определению, поэтому каждое из них должно повторять вс0 основные моменты, и все они должны быть согласованы между собой. Это превращает чтение/ руководства в весьма скучное занятие, но здесь^ точность важнее, чем живость изложения.
      Единство "Принципов действия Системы 360" обусловлено тем, что они вышли из-под пера только двух авторов - Джерри Блау и Андриса Падегза. Идеи, в них изложенные, принадлежали примерно десятку людей, но для того, чтобы сохранить соответствие между продуктом и его описанием, превращать эти идеи в текстовые спецификации должны были один или два человека. Чтобы дать какое-нибудь определение, необходимо принять целый ряд мини-решений, которые не требуют подробного обсуждения. Примером такого рода в Системе 360 могут служить детали установления "кода условия" после каждой операции. Нетривиальным, однако, является принцип, согласно которому такие мини-решения должны быть полностью непротиворечивы.
      Приложение к "Принципам действия Системы 3GO", написанное Джерри Блау, я считаю лучшим из всех когда-либо виденных мною руководств. В этом приложении очень точно и тщательно описываются пределы совместимости Системы 360, указывается, к чему следует стремиться, и перечисляются те области внешнего окружения, где архитектура умышленно хранит молчание и где результаты, полученные на разных моделях, могут отличаться друг от друга, где один экземпляр данной модели может отличаться от другого или где, наконец, система может отличаться от себя самой после каких-то технологических изменений. Авторы руководств должны стремиться именно к такому уровню точности, они обязаны определять то, чего нельзя делать, столь же тщательно, как и то, что можно.
      Формальные описания
      Английский язык, как и все другие естественные языки, нельзя считать идеальным средством для таких описаний. Поэтому Создатель руководства сам должен накладывать строгие ограничения на язык с тем, чтобы достичь необходимой точности. Использование формальной системы обозначений представляется очень привлекательным выходом из этого затруднения. В конце концов точность - это основа, смысл существования формальной системы обозначений.
      Давайте рассмотрим сильные и слабые стороны формальных описаний. Как уже отмечалось, формальные описания точны. Они стремятся быть максимально полными; пробелы более заметны, а потому скорее заполняются. Зато они непонятны. Когда речь идет об английской прозе, всегда можно назвать принципы ее организации, указать структуру на различных эта-. пах или уровнях и привести примеры. Несложно перечислить исключения и выявить противоречия. И что важнее всего, можно объяснить, почему это так, а не иначе. Достаточно разработанные формальные описания вызывают изумление своей элегантностью и доверие - своей точностью. Но для того, чтобы их содержание можно было легко уяснить самому и объяснить другим, необходимы пояснения. По этим причинам я считаю, что будущие спецификации должны состоять как из формальных, так и текстовых описаний.
      Старая пословица предупреждает: "Никогда не выходи в море с двумя хронометрами: бери один или три". Ее вполне можно отнести и к проблеме текстовых и формальных описаний. Если у вас есть и то, и другое, то одно должно быть стандартом, а второе - производным описанием, что следует указать ясно. В качестве исходного стандарта можно выбрать любое из них. Алгол-68 имеет в качестве стандарта формальное описание и, кроме того, поясняющее текстовое описание. Стандартное описание PL/I дано текстом, а формальное описание - как производное. Система 360 также имеет текстовое описание в качестве стандарта и рядом - производное формальное описание.
      Существует множество способов представления формальных описаний. Бэкусова - Наурова форма (БНФ), разработанная для описания языков, широко освещена в литературе2). Формальное описание PL/I использует новую систему обозначении абстрактного синтаксиса, и она адекватно описана3). Язык APL, разработанный Айверсоном, применялся для описания машин, в частности, IBM-70904) и Системы 3605).
      Белл и Ныоэлл предложили новую систему для описания конфигураций и архитектуры машин и проиллюстрировали ее на примере нескольких машин, включая PDP-8 фирмы DEC6), IBM-70906) и Системы 3607).
      Почти псе формальные описания воплощают реализацию аппаратуры или системы программного обеспечения, внешние спецификации которой они определяют. Синтаксис можно описать и без этого, но семантику обычно описывают с помощью программы, которая выполняет определяемую операцию. Это, конечно, реализация, и как таковая она диктует архитектурные решения. Необходимо указать, что формальное описание приложимо только к внешним спецификациям, и следует сказать, что они собой представляют.
      Не только формальное описание является реализацией, но и реализация может служить формальным описанием. Именно этот принцип использовался при создании первых совместимых ЭВМ. Новая машина должна соответствовать старой. Какие-то места в руководстве непонятны? "Спросите машину!". Нужно было разработать тестовую программу, определяющую поведение старой машины, и добиться того, чтобы новая машина проходила через этот тест.
      Программы-имитаторы аппаратуры или математического обеспечения могут использоваться точно таким же образом. Это реализация; она работает. Поэтому все вопросы описания можно разрешить путем ее проверки.
      Использование реализации в качестве описания имеет некоторые преимущества. Все вопросы разрешаются однозначно посредством эксперимента. Дискуссии не нужны, потому что ответы получаются быстро. Ответы всегда точны в той степени, которая нужна, ц они по определению верны. Но, кроме преимуществ, такой подход имеет и очень много недостатков. Реализация может вызвать переопределение даже внешних спецификаций. Ошибка в синтаксисе в реализации приводит к любому результату; в "чистой" системе этот результат является лишь указанием на некорректность и ничем больше. В "неряшливой" системе могут появиться самые разнообразные побочные эффекты, которые могут быть использованы программистами. Когда мы предприняли эмуляцию ЭВМ IBM-1401 на Системе 360, то обнаружилось около 30 различных "курьезов", или побочных эффектов, вызываемых, предположительно, ошибочными операциями, которые, однако, стали широко использоваться и должны теперь рассматриваться как часть описания. Реализация, выступающая в качестве описания, предлагает избыточные определения; она говорит не только о том, что машина должна делать, но, в значительной степени, и о том, как она это должна делать.
      Кроме того, реализация будет иногда давать неожиданные и незапланированные ответы на трудные вопросы, это описание de facto оказывается неэлегантным в таких конкретных местах как раз потому, что они в свое время не были продуманы. Их воспроизведение в другой реализации может дорого обойтись. Например, некоторые машины не полностью очищают регистр множимого после умножения. Явление это по своей природе - часть фактического описания, однако его воспроизведение может помешать использованию более быстрого алгоритма умножения.
      Наконец, использование реализации в качестве формального описания таит в себе опасную возможность перепутать, что именно является стандартом:
      текстовое описание или формальное. Это особенно справедливо в отношении программных имитаторов;
      Кроме того, нельзя вносить модификации в реализацию, пока она служит стандартом.
      Прямое внесение
      В распоряжении архитектора систем математического обеспечения есть превосходный метод распространения и внесения определений. Он особенно полезен для установления, если не семантики, то синтаксиса межмодульных сопряжении. Заключается этот метод в задании описания передаваемых параметров или совместно используемой памяти, и в требований, чтобы реализация включала данное описание через операции периода компиляции (макрокоманды или % INCLUDE в PL/I). Кроме того, если обращение ко всему сопряжению осуществляется только по символическим именам, то описание можно изменить путем добавления или введения новых переменных только ретрансляцией используемой программы без ее изменения.
      Конференции и разбирательства
      Нет никакой нужды говорить о том, что совещания необходимы. Кроме сотен частных консультаций, необходимы более формальные встречи. Мы считаем, что полезно их проводить на двух уровнях.
      Первый- это еженедельные совещания всех архитекторов и официальных представителей разработчиков аппаратуры и математического обеспечения. Председательствует на них главный архитектор системы.
      Каждый может вынести на обсуждение какую-нибудь проблему или предложить изменения, но обычно все предложения распространяются в письменной форме перед совещанием. Новая проблема, как правило, какое-то время обсуждается. Причем основное внимание уделяется не принятию решений как таковых, а процессу творческого поиска. Вся группа пытается найти возможные решения проблемы, затем некоторые из этих решений передаются одному или нескольким архитекторам, которые превращают их в строго сформулированные предложения, обосновывающие изменения в документах.
      Далее начинается процесс принятия решений. Предложения внимательно изучаются разработчиками и пользователями, тщательно взвешиваются все "за" и "против". Если согласие достигнуто - отлично. В противном случае решение принимает главный архитектор. Время не тратится впустую, и решения быстро и широко распространяются.
      Решения, принимаемые на еженедельных совещаниях, дают быстрый результат и не тормозят работу. Если кто-либо ими совершенно неудовлетворен, он может нeмeд^eннo апеллировать к руководителю проекта, но такое случается крайне редко.
      Подобные совещания очень плодотворны по нескольким причинам:
      1. Одна и та же группа архитекторов, пользователей и разработчиков встречается еженедельно в течение месяцев. Не нужно тратить время на то, чтобы ввести людей в курс дела.
      2. Группа состоит из людей способных, изобретательных, хорошо разбирающихся в проблеме и глубоко заинтересованных в результатах. Ни один из них не выступает в роли "советчика". Каждый уполномочен принимать на себя обязательства.
      3. Когда возникают проблемы, поиск их решения осуществляется как внутри очевидных границ, так и за их пределами.
      4. Формализм письменных предложений позволяет сосредоточить внимание, стимулировать их решение и набежать противоречий.
      5. Законодательная власть главного архитектора позволяет избежать компромиссов и задержек.
      По прошествии времени некоторые решения устаревают. Отдельные частные способы решения не удовлетворяют того или иного участника. Другие решения вызывают непредвиденные затруднения, и иногда еженедельные совещания не в состоянии их разрешить. Так накапливается груз мелких жалоб, открытых вопросов пли недовольства. Для того, чтобы справиться со всем этим, мы ежегодно осенью проводили сессии "верховного суда", которые длились обычно две недели. (Если бы мне пришлось все начинать сначала, я бы их проводил каждые шесть месяцев.)
      Эти сессии проводились непосредственно перед окончательным принятием главных разделов руководств. На них присутствовала не только вся группа архитекторов, представители разработчиков и пользователей, ответственные за связь с архитекторами, но и руководители групп пользователей, сбыта и реализации. Председательствовал руководитель проекта Системы 360. Повестка дня содержала обычно около 200 пунктов, в большинстве своем мелких, которые были перечислены на плакатах, развешенных по залу. Выслушивались мнения всех сторон и принимались решения. Багодаря чудесам машинного редактирования текстов (и прекрасной организации административных служб) каждый участник находил поутру на своем месте новый вариант руководства, уже содержащий вчерашние решения.
      Эти "осенние фестивали" были ценны не только принимаемыми решениями, но и тем, что они сразу становились общим достоянием. Каждый мог высказаться, выслушать всех остальных и глубже проникнуть в суть взаимосвязей между решениями.
      Совместные реализации
      Архитекторы Системы 360 имели два почти беспрецедентных преимущества: достаточное время для тщательной и неторопливой работы и политическое равенство с разработчиками. Разумные сроки были обусловлены графиком выпуска новой техники; политическое равенство вытекало из факта одновременного ведения нескольких разработок. Необходимость их строгой совместимости служила наилучшей движущей силой проектирования.
      В процессе создания вычислительных машин почти всегда наступает день, когда обнаруживается, что машина и документация по ее использованию не соответствуют друг другу. В последующем столкновении документ обычно терпит поражение, потому что его переделка обходится гораздо дешевле и требует меньше времени. Не так обстоит дело в случае разработки серии моделей. Тогда задержки и затраты, связанные с принятием серии плохих машин, могут перевешивать задержки и затраты на переделку машин для точного соответствия их документации.
      При описании языков программирования следует иметь в виду это обстоятельство. Нужно отдавать себе отчет в том, что раньше или позже, но появятся несколько трансляторов или интерпретаторов, отвечающих различным целям. Описание будет яснее, а дисциплина - строже, если с самого начала ведутся по меньшей мере две реализации.
      Журнал регистрации телефонных звонков
      Как только начинается реализация, возникает бесчисленное множество вопросов, связанных с интерпретацией решений архитектора, независимо от того, насколько точны спецификации. Очевидно, что многие такие вопросы требуют дополнений и разъяснений в самом тексте документа, другие же просто отражают недопонимание.
      Необходимо всячески поощрять практику выяснен ния неясных мест по телефону, когда озадаченный разработчик, вместо того, чтобы действовать наугад, звонит архитектору и получает исчерпывающий ответ. Столь же необходимо осознать, что ответы архитектора на такие вопросы представляют собой вполне официальные и авторитетные заявления, которые следует довести до каждого.
      Очень полезен журнал регистрации телефонных звонков, который ведет архитектор. В нем он регистрирует каждый вопрос и каждый ответ. Каждую неделю журналы нескольких архитекторов объединяются вместе, репродуцируются и распространяются среди пользователей и разработчиков. Хотя этот механизм совсем не формален, но он быстр и понятен.
      Проверка конечного продукта
      Лучший друг руководителя проекта - это его каждодневный противник, независимая организация, проверяющая продукт. Эта группа проверяет соответствие машин и программ их спецификациям и выступает в роли адвоката дьявола, выискивая все почти неуловимые дефекты и несоответствия. Каждой проектной организации нужна такая независимая техническая ревизионная группа, чтобы все было честно.