Компактное программирование

С сайта webkomora.com.ua :

Фредерик П. Брукс

Мифический человеко-месяц
или как создаются программные системы

Посвящения

Посвящение издания 1975 года

Посвящается двоим людям, благодаря которым мои годы в IBM были особенно насыщенными: Томасу Дж. Уотсону Младшему, чье глубокое внимание к людям по-прежнему ощущается в его фирме, и Бобу О. Эвансу, чье смелое руководство превратило работу в приключение.

Посвящение издания 1995 года

Посвящается Нэнси, Божьему дару для меня.

Предисловие к изданию 1995 года

К моему удивлению и удовольствию, "Мифический человеко-месяц" остается популярным через 20 лет после выхода. Тираж превысил 250 000 экземпляров. Меня часто спрашивают, какие из оценок и рекомендаций, изложенных в 1975 году, я по- прежнему считаю верными, а какие претерпели изменения, и в чем именно. Несмотря на то, что в моих лекциях этот вопрос время от времени затрагивается, я давно жду возможности изложить его в печатном виде.

Питер Гордон (Peter Gordon), являющийся сейчас совладельцем издательства Addison-Wesley, терпеливо и с пользой сотрудничает со мной с 1980 года. Он предложил подготовить юбилейное издание. Мы решили не исправлять оригинал, а перепечатать его в неприкосновенности, за исключением обычных опечаток, и дополнить мыслями, возникшими в более позднее время.

В главе 16 перепечатывается статья "Серебряной пули нет: сущность и акциденция в программной инженерии", опубликованная IFIPS (Международная федерация обществ по обработке информации) в 1986 году и явившаяся результатом опыта, полученного мною во время руководства исследованием использования программного обеспечения в военных областях, проводившегося Военным комитетом по науке. Мои соавторы по этому исследованию, а также наш исполнительный секретарь Роберт Л. Патрик, оказали мне неоценимое содействие в моем возвращении к крупным практическим программным проектам. Статья была перепечатана в издании IEEE "Computer" в 1987 году, благодаря которому получила широкую известность.

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

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

Глава 19 собственно и представляет собой попытку пересмотреть изначальные утверждения. Следует предупредить читателя, что излагаемые новые взгляды далеко не в той мере подкреплены "боевым опытом", как это было в первой части книги. Дело в том, что в последнее время я работал в университетской среде, а не в промышленности, и над небольшими, а не крупномасштабными проектами. С 1986 года я занимаюсь только преподавательской деятельностью в области разработки программного обеспечения, но не исследованиями в ней. Моя исследовательская работа больше касается виртуальных сред и их применений.

При подготовке данной ретроспективы я поинтересовался современными взглядами своих друзей, которые практически занимаются разработкой программного обеспечения. В число тех, перед кем я в долгу за готовность поделиться своими взглядами, сделать полезные замечания к первоначальному тексту и усовершенствовать мое образование, входят Барри Бем (Barry Boehm), Кен Брукс (Ken Brooks), Дик Кейс (Dick Case), Джеймс Коггинс (James Coggins), Том Демарко (Tom DeMarco), Джим Маккарти (Jim McCarthy), Дэвид Парнас (David Parnas), Эрл Уилер (Earl Wheeler) и Эдвард Йордон (Edward Yordon). Фэй Уард (Fay Ward) прекрасно выполнила техническую работу, связанную с изданием новых глав.

Я благодарен моим коллегам из Группы по программному обеспечению для военных целей Военного комитета по науке Гордону Беллу (Gordon Bell), Брюсу Бьюкенену (Bruce Buchanan), Рику Хейз-Роту (Rick Hayes-Roth) и особенно Дэвиду Парнасу - за их плодотворные идеи, а Ребеке Бирли (Rebekah Bierly) - за подготовку к печати статьи, опубликованной в данной книге в качестве главы 16. Анализ проблем программирования в категориях "сущность" (essence) и "акциденция" (accident) возникло благодаря Нэнси Гринвуд Брукс, использовавшей такой анализ в статье об обучении игре на скрипке методом Сузуки.

Обычаи издательства Addison-Wesley не позволили мне в предисловии к изданию 1975 года выразить благодарность его сотрудникам за сыгранную ими важную роль. Следует особенно отметить вклад двух человек: Нормана Стентона (Norman Stenton), являвшегося ответственным редактором, и Герберта Боуза (Herbert Boes), бывшего художественным редактором. Боуз создал изящный стиль, особо отмеченный одним из рецензентов: "широкие поля и творческое использование шрифтов и компоновки материала". Что еще важнее, он дал важный совет поместить в начале каждой главы свою картинку. (В то время у меня были только картинки Смоляных ям и Реймского собора.) Чтобы найти все картинки, мне потребовался целый год, но я бесконечно благодарен за совет.

Soli Deo gloria - Богу единому слава! F. P. B., Jr. Чапел Хилл, Северная Каролина Март 1995

Предисловие к первому изданию

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

Мое профессиональное становление в вычислительной технике первоначально было связано с программированием, однако в период 1956-1963 годов, когда разрабатывались автономные управляющие программы и языки высокого уровня, я занимался, в основном, архитектурой компьютеров. Когда в 1964 году я стал менеджером проекта разработки Operating System/360, то обнаружил, что мир программирования совершенно изменился благодаря успехам, достигнутым за несколько последних лет.

Руководство разработкой OS/360 было очень поучительным, хотя и полным расстройств. Команде разработчиков, в том числе сменившему меня Ф. М. Трапнеллу (F. M. Trapnell), можно многим гордиться. Система содержит много отличных решений в конструкции и функционировании, и ей удалось получить широкое распространение. Некоторые идеи, в первую очередь, организация ввода/вывода, независимая от устройств, и управление внешними библиотеками стали техническими новинками, ныне широко используемыми. Сейчас эта система вполне надежна, достаточно производительна и весьма гибка.

Однако проект нельзя назвать вполне успешным. Всякому пользователю OS/360 быстро становится ясно, насколько лучше могла бы быть система. Ошибки проектирования и реализации особенно заметны в управляющей программе, а не в компиляторах языков. Большая часть этих просчетов относится к периоду 1964-65 годов и потому должна быть отнесена на мой счет. Более того, система вышла с задержкой, потребовала больше памяти, чем предполагалось, стоимость разработки в несколько раз превысила запланированную, и первые несколько версий функционировали не слишком удачно.

Покинув в 1965 году IBM и придя в Чэпел Хилл, как это и предполагалось, я возглавил разработку OS/360 и стал анализировать опыт этой разработки, чтобы извлечь уроки технологических решений и администрирования. В частности, я хотел понять, почему столь различным оказался опыт администрирования при разработке аппаратной части System/360, с одной стороны, и создании операционной системы OS/360 - с другой. Эта книга является запоздалым ответом на вопросы Тома Уотсона относительно трудности управления разработкой программ.

В решении этой задачи я получил большую пользу от длительного общения с Р. П. Кейсом (R. P. Case), помощником менеджера проекта в 1964-65 годах, и Ф. М. Трапнеллом, менеджером проекта в 1965-68 годах. Я обсудил свои выводы с менеджерами других крупных программных проектов, в том числе Ф. Дж. Корбато (F. J. Corbato) из МТИ, Джоном Харром (John Harr) и В. Высоцким (V. Vyssotsky) из Bell Telephone Laboratories, Чарльзом Портманом (Charles Portman) из International Computers Limited, А. П. Ершовым из Вычислительного центра Сибирского отделения Академии наук СССР, а также А. М. Пьетрасанта (A. M. Pietrasanta) из IBM.

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

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

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

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

Я глубоко признателен мисс Саре Элизабет Мур (Sara Elizabeth Moore), мистеру Дэвиду Вагнеру (David Wagner) и миссис Ребекке Беррис (Rebecca Burris) за помощь в подготовке данной рукописи, а также профессору Джозефу Слоуну (Joseph C. Sloane) за советы в отношении иллюстраций.

F. P. B., Jr.
Чэпел Хилл, Северная Каролина
Октябрь 1974


Глава 1. Смоляная яма


                        Een Schip op bet strand is een baken in zee.
                        (Корабль на мели - моряку маяк.)

                                              Голландская пословица

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

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

Системный программный продукт

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

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

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

Есть два способа, которыми программу можно превратить в более полезный, но и более дорогой объект. Эти два способа представлены по краям рисунка.

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

PHOTO

Рис. 1.1 Эволюция системного программного продукта

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

Компонент программного комплекса стоит, по крайней мере, втрое дороже, чем автономная программа с теми же функциями. Стоимость может увеличиться, если в системе много компонентов.

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

Радости профессии

Почему заниматься программированием интересно? Какими радостями вознаграждаются те, кто им занимается?

Во-первых, это просто радость, получаемая при создании чего-либо своими руками. Как ребенок радуется, делая куличики из песка, так и взрослый получает удовольствие, создавая какие-либо вещи, особенно если сам их и придумал. Я думаю, что этот восторг - отражение восторга Господа, творящего мир, восторга, проявляющегося в индивидуальности и новизне каждого листочка и каждой снежинки.

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

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

Компьютер с работающей на нем программой обладает доведенным до высшего предела очарованием игорного или музыкального автомата.

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

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

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

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

Печали профессии

Не все, однако, в радость, и если предвидеть присущие этому ремеслуогорчения, то они легче переносятся.

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

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

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

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

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

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

новыми и лучшими идеями. И уничтожение плода вашей мысли уже не только задумано, но и запланировано.

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

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

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

Глава 2. Этот мифический "человеко-месяц"


                    Чтобы приготовить вкусную пищу, требуется время. 
                Если вам пришлось ждать, то лишь потому, что мы хотим 
                лучше обслужить вас и доставить вам удовольствие.
                
                             Меню ресторана "Антуан" в Нью-Орлеане

Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам вместе взятым. Почему эта причина неудач столь распространена?

Во-первых, слабо развиты наши методы оценок. В сущности, они отражают молчаливое и совершенно неверное предположение, что все будет идти хорошо.

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

В-третьих, поскольку менеджеры программных проектов не уверены в своих оценках, им часто недостает вежливого упрямства, как у шеф-повара ресторана "Антуан".

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

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

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

Контроль выполнения графика будет предметом отдельного разговора.

Рассмотрим более подробно остальные аспекты проблемы.

Оптимизм

Все программисты - оптимисты. Возможно, эта современная разновидность колдовства особенно привлекательна для тех, кто верит в хэппи-энды и добрых фей. Возможно, сотни неудач отталкивают всех, кроме тех, кто привык сосредоточиваться на конечной цели. А может быть, дело всего лишь в том, что компьютеры и программисты молоды, а молодости свойствен оптимизм. Как бы то ни было, в результате одно: "На этот раз она точно пойдет!" Или : "Я только что выявил последнюю ошибку!"

Итак, в основе планирования разработки программ лежит ложное допущение, что все будет хорошо, т.е. каждая задача займет столько времени, сколько "должна" занять.

Глубокий оптимизм программистов заслуживает более серьезного изучения. Дороти Сэйерс (Dorothy Cayers) в своей превосходной книге "Разум творца" ("The Mind of the Maker") выделяет в творческой деятельности три стадии: замысел, реализацию, взаимодействие. Соответственно, книга, компьютер или программа сначала возникают как идеальное построение, существующее не во времени и пространстве, а лишь в мозгу своего создателя. Реализация же во времени и пространстве происходит с помощью пера, чернил, бумаги, либо - проводов, кремния и феррита. Творение будет завершено, когда кто-либо прочтет книгу, воспользуется компьютером или запустит программу, тем самым вступив во взаимодействие с разумом их создателя.

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

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

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

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

Следовательно, наш оптимизм не имеет оправдания.

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

PHOTO

Рис. 2.1 Зависимость времени от числа занятых - полностью разделимая задача

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

PHOTO

Рис. 2.2 Зависимость времени от числа занятых - неразделимая задача

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

PHOTO

Рис. 2.3 Зависимость времени от числа занятых - разделимая задача, требующая обмена данными

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

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

PHOTO

Рис. 2.4 Зависимость времени от числа занятых - задача со сложными взаимосвязями

С обменом данными дело обстоит хуже. Если все части задания должны быть отдельно скоординированы между собой, то затраты возрастают как n(n-2)/2.

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

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

Системное тестирование

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

В течение ряда лет при планировании разработки программного обеспечения я пользуюсь следующим эмпирическим правилом:

1/3 - планирование,

1/6 - написание программ,

1/4 - тестирование компонентов и предварительное системное тестирование,

1/4 - системное тестирование при наличии всех компонентов.

Это правило имеет несколько важных различий с общепринятым планированием:

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

2. Половина графика работ, отведенная на отладку законченного кода, значительно выше нормы.

3. Та часть, которую легко оценить, т.е. написание кода, занимает всего одну шестую общего времени.

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

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

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

Робость в оценках

Для программиста, как и для повара, давление со стороны хозяина может определять запланированный срок завершения задачи, но не может определять время ее фактического завершения. Омлет, обещанный через две минуты, может успешно жариться, но если через две минуты он не готов, то у клиента есть две возможности: ждать еще или съесть его сырым. Тот же выбор встает и перед заказчиком программного обеспечения.

У повара есть еще одна возможность: добавить жару. В результате омлет часто оказывается безнадежно испорченным: горелым с одного края и сырым - с другого.

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

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

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

Действия при срыве графика

Что делают, когда важный программный проект начинает отставать от графика? Естественно, добавляют людей. Как показывают рисунки 2.1-2.4, это не всегда помогает.

Рассмотрим пример 3. Предположим, что трудоемкость задачи оценивается в 12 человеко-месяцев, и три человека должны выполнить ее за 4 месяца, причем в конце каждого месяца имеются четыре контрольные точки A, B, C и D, в которых можно произвести измерения (рис. 2.5).

PHOTO

Рис. 2.5

Предположим теперь, что первая контрольная точка была достигнута лишь по истечении двух месяцев. Какие альтернативы имеются у менеджера?

1. Допустим, что необходимо соблюсти срок выполнения задачи, и ошибочно оценена была только первая часть задачи, т.е. рисунок 2.6 верно отражает положение. Значит, остается 9 человеко-месяцев трудозатрат и два месяца, поэтому понадобится 4 человека, и к троим имеющимся нужно добавить еще двоих.


Глава 3. Операционная бригада

Эти исследования выявили большие индивидуальные различия в производительности между лучшими и худшими работниками, часто на порядок величин.
САКМАН, ЭРИКСОН И ГРАНТ

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

Такое наивное представление альтернатив уходит от решения сложной задачи - как создавать большие системы в разумные сроки? Рассмотрим этот вопрос более подробно со всех сторон.

Проблема

Менеджеры программных проектов давно поняли, что хорошие и плохие программисты очень сильно различаются между собой по производительности. Однако реально измеренные величины поразительны. В одном из исследований Сакман (Sackman), Эриксон (Erikson) и Грант (Grant) измеряли производительность труда в группе опытных программистов. Внутри одной лишь этой группы соотношение между лучшими и худшими результатами составило примерно 10:1 по производительности труда и 5:1 по скорости работы программ и требуемой для них памяти! Короче, программист, зарабатывающий 20 тысяч долларов в год, может быть в десять раз продуктивнее программиста, зарабатывающего 10 тысяч долларов. Правда, возможно и обратное. Полученные данные не выявили какой-либо корреляции между стажем работы и производительностью. (Я не уверен, что это всегда справедливо.)

Выше я доказал, что само число разработчиков, действия которых нужно согласовывать, оказывает влияние на стоимость проекта, поскольку значительная часть издержек вызвана необходимостью общения и устранения отрицательных последствий разобщенности (системная отладка). Это также наводит на мысль, что желательно разрабатывать системы возможно меньшим числом людей. Действительно, опыт разработки больших программных систем, как правило, показывает, что подход с позиций грубой силы влечет удорожание, замедленность, неэффективность, а создаваемые в результате системы не являются концептуально целостными. Список, иллюстрирующий это, бесконечен: OS/360, Exec 8, Scop 6600, Multics, TSS, SAGE и другие.

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

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

С другой стороны, исходная команда из 200 человек имела численность, недостаточную для создания действительно крупных систем методом грубой силы.Рассмотрим, к примеру, OS/360. Одно время в ее создании было занято больше 1000 человек - программистов, составителей документации, операторов, клерков, секретарей, менеджеров, вспомогательных групп и т.д. С 1963 по 1966 год на ее проектирование, реализацию и написание документации было затрачено, вероятно, около 5000 человеко-лет. Если бы строго соблюдалась пропорция между количеством занятых и продолжительностью работ, нашей предполагаемой команде из двухсот человек потребовалось бы 25 лет, чтобы довести продукт до сегодняшнего уровня!

В этом и состоит изъян идеи маленькой активной команды: для создания по- настоящему крупных систем ей потребуется слишком много времени. Посмотрим, как разработка OS/360 осуществлялась бы маленькой активной командой, допустим, из 10 человек. Положим, что они в семь раз продуктивнее средних программистов (что далеко от истины). Допустим, что уменьшение объема общения благодаря малочисленности команды позволило еще в семь раз повысить производительность. Допустим, что на протяжении всего проекта работает одна и та же команда. Таким образом, 5000/(10*7*7)=10, т.е. работу в 5000 человеко-лет они выполнят за 10 лет. Будет ли продукт представлять интерес через 10 лет после начала разработки или устареет благодаря стремительному развитию программных технологий?

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

Предложение Миллза

Предложение Харлана Миллза дает свежее и творческое решение2,3. Миллз предложил, чтобы на каждом участке работы была команда разработчиков, организованная наподобие бригады хирургов, а не мясников. Имеется в виду, что не каждый участник группы будет врезаться в задачу, но резать будет один, а остальные оказывать ему всевозможную поддержку, повышая его производительность и плодотворность.

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

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

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

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

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

Два секретаря. Администратору и редактору нужны секретари. Секретарь администратора обрабатывает переписку, связанную с проектом, а также документы, не относящиеся к продукту.

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

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

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

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

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

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

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

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

Как это работает

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

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

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

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

В статье Бейкера сообщается об одной проверке такой концепции бригады, проведенной в ограниченном масштабе. Как и предсказывалось, результаты оказались великолепными.

Масштабирование

До сих пор все было хорошо. Проблема, однако, состоит в том, как создавать продукты, на которые сейчас уходит не 20 или 30, а 5000 человеко-лет. Бригада из 10 человек может быть эффективна вне зависимости от своей организации, если задача целиком находится в ее компетенции. Но как использовать идею операционной бригады в задачах, для выполнения которых привлекаются сотни людей?

Успех при масштабировании обусловливается коренным улучшением концептуального единства каждого участка, ведь количество проектировщиков уменьшилось в семь раз. Поэтому можно привлечь к работе над задачей 200 человек, и необходимость координации умственных усилий потребуется всего для 20 из них - хирургов.

PHOTO

Рис. 3.1 Схема контактов между сотрудниками в бригаде из 10 человек

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

Глава 4. Аристократия, демократия и системное проектирование

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

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

ПУТЕВОДИТЕЛЬ ПО РЕЙМСКОМУ СОБОРУ

Концептуальное единство

У большинства европейских соборов части, построенные разными поколениями строителей, имеют различия в планировке и архитектурном стиле. Более поздние строители испытывали соблазн "улучшить" проект своих предшественников, чтобы отразить новые веяния моды и свои личные вкусы. В итоге мирный норманнский трансепт создает конфликт с примыкающим к нему возносящимся в высь готическим нефом, и результат столь же служит восхвалению славы Господней, сколь и гордыни строителей. Архитектурное единство Реймского собора находится в прямой противоположности с таким смешением стилей. Источником наполняющей зрителя радости служат как цельность конструкции, так и отдельные образцы совершенства. Как сказано в путеводителе, цельность была достигнута благодаря самоотречению восьми поколений строителей собора, пожертвовавших своими идеями ради чистоты общего замысла. То что получилось в результате, служит восхвалению не только славы Господней, но и Его могущества, способного спасти грешных людей от их гордыни.

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

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

- Как достичь концептуальной целостности?

- Не будет ли это требование причиной раскола на элиту, аристократический класс архитекторов - с одной стороны, и толпы плебеев-исполнителей, чьи творческие таланты и идеи подавляются, - с другой?

- Как удержать архитекторов от витания в облаках и разработки несущественных или чрезмерно дорогих спецификаций?

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

Достижение концептуальной целостности

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

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

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

Это обстоятельство часто неправильно понимается. Operating System/360 превозносится своими создателями, как лучшая из когда-либо созданных, поскольку неоспоримо, что в ней больше функций. Функции, а не простота всегда служили критерием превосходства ее создателей. С другой стороны, создатели системы с разделением времени для PDP-10 превозносят ее превосходство ввиду простоты и немногочисленности положенных в основу идей.

Однако по всем меркам ее функциональность ниже по классу, чем OS/360. Если в качестве критерия определена простота использования, становится очевидной несбалансированность этих систем, достигающих цели лишь наполовину.

Однако для некоторого заданного уровня функциональности лучшей оказывается та система, в которой можно работать с наибольшей простотой и непосредственностью. Простота - это еще не все. Язык TRAC, созданный Муером, и Algol 68 достигают простоты, если количественно измерять ее числом отдельных элементарных понятий. Непосредственность, однако, не характерна для них. Чтобы выразить свои намерения, часто требуется сочетать базовые средства сложным и неожиданным образом. Недостаточно изучить базовые элементы и правила их комбинирования, нужно изучить еще идиоматическое использование, целую область знаний о том, как на практике комбинировать элементы. Простота и непосредственность проистекают из концептуальной целостности. Во всех частях должны найти отражение единая философия и единообразные пропорции между желаемыми целями. В каждой части должны также использоваться одинаковый синтаксис и сходные семантические обозначения. Таким образом, простота использования требует единства проекта, концептуальной целостности.

Аристократия и демократия

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

С другой стороны, напряженность графика требует привлечения большого числа работников. Есть два метода разрешения этой дилеммы. Первый состоит в тщательном разделении труда между архитектурой и исполнением. Второй - новый способ организации бригад программистов-исполнителей, обсуждавшийся в предыдущей главе. 31 Отделение разработки архитектуры от реализации является эффективным способом достижения концептуальной целостности при работе над очень большими проектами. Я лично был свидетелем успешного его применения при создании IBM компьютера Stretch и серии продуктов System/360. Но он не сработал при разработке Operating System/360, поскольку недостаточно применялся.

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

Архитектор системы, как и архитектор здания, является представителем пользователя. Его задача - использовать все свои профессиональные и технические знания исключительно в интересах пользователя, а не продавца, изготовителя и т.п.2 Архитектура и разработка должны быть тщательно разделены. Как сказал Блау (Blaauw), "архитектура говорит, что должно произойти, а разработка - как сделать, чтобы это произошло". В качестве простого примера он приводит часы, архитектура которых состоит из циферблата, стрелок и заводной головки. Ребенок, освоивший это архитектуру, с одинаковой легкостью может узнать время и по ручным часам, и по часам на колокольне. Исполнение же и его реализация описывают, что происходит внутри: передача усилий и управление точностью каждым из многих механизмов.

К примеру, в System/360 одна и та же архитектура компьютера совершенно по- разному реализована примерно в девяти моделях. Обратным образом, одна и та же реализация потока данных, памяти и микропрограмм из Model 30 использовалась в разное время в четырех различных архитектурах: System/360, мультиплексном канале с подключением до 224 логически независимых подканалов, селекторном канале и компьютере 1401.

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

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

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

взять кто-то один. Это аристократизм, который не нуждается в извинениях. Ответ отрицательный, поскольку разработка проекта требует не меньше творчества, чем задание внешних спецификаций. Это тоже творческая работа, но другого характера. Разработка проекта для заданной архитектуры требует и допускает столько же творческой деятельности, новых идей, изобретательности, как и проект внешних спецификаций. Практически, коэффициент стоимость/эффективность созданного продукта больше зависит от исполнителя, а простота его использования - от архитектора. Есть масса примеров, подсказанных другими искусствами и ремеслами, которые подводят к мнению, что дисциплина идет на пользу. Действительно, афоризм художника гласит, что "форма освобождает". Самые ужасны строения - это те, бюджет которых был слишком велик для поставленных целей. Творческую активность Баха едва ли могла подавлять необходимость еженедельная необходимость изготавливать кантату определенного вида. Я уверен, что архитектура компьютера Stretch стала бы лучше, если бы на нее наложили более жесткие ограничения; так, ограничения, наложенные бюджетом на System/360 Model 30, по моему мнению, принесли лишь пользу архитектуре Model 75. Аналогично, я считаю, что получение архитектуры извне усиливает, а не подавляет творческую активность группы исполнителей. Они сразу сосредоточиваются на той части задачи, которой никто не занимался, и в результате изобретательность бьет ключом. В не ограничиваемой группе большая часть обдумывания и обсуждения посвящена архитектурным решениям в ущерб реализации. Этот многократно наблюдавшийся мной эффект подтвердил Р. У. Конвей (R. W. Conway), чья группа разработала в Корнельском университете компилятор PL/C для языка PL/I. Он говорит: "В конечном итоге мы решили реализовать язык без изменений и усовершенствований, поскольку обсуждение языка отняло бы у нас все силы."6

Чем заняться разработчику, пока он вынужден ждать?

Очень неприятно совершить ошибку стоимостью в миллион долларов, но зато она надолго запоминается. Я отчетливо помню тот день, когда мы приняли решение о том, как практически организовать составление внешних спецификаций для OS/360. Менеджер по архитектуре, менеджер по реализации управляющей программы и я прорабатывали план, график и разделение обязанностей. У менеджера по архитектуре было 10 хороших специалистов. Он утверждал, что они в состоянии написать спецификации и сделать это должным образом. Это должно было занять 10 месяцев - на три больше, чем отводилось по графику. У менеджера по реализации управляющей программы было 150 человек. Он заявлял, что они могут подготовить спецификации, при этом группа архитекторов выполняла бы координирующие функции. Обещалось, что это будет сделано хорошо и практично, с соблюдением сроков. Более того, если оставить спецификации группе архитекторов, его 150 человек в течение десяти месяцев будут бить баклуши. На это менеджер по архитектуре возразил, что если я сделаю ответственной за написание спецификаций группу управляющей программы, то результата в срок не будет: он все равно задержится на три месяца, но по качеству будет много хуже. Так оно и оказалось в действительности. Он оказался прав в обоих пунктах. Кроме того, из-за отсутствия концептуальной целостности создание и внесение изменений в систему оказались значительно более дорогостоящими, и, по моим оценкам, отладка удлинилась на год. Конечно, многие факторы повлияли на принятие этого ошибочного решения, но определяющими были желание уложиться в график и стремление занять работой этих 150 человек. Пение этих сирен таит смертельные опасности, которые я и хочу сейчас показать.

Когда предлагается, чтобы все внешние спецификации для компьютерной или программной системы были составлены небольшой командой архитекторов, исполнители выдвигают три возражения:

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

- Архитекторы получат все радости творчества и заблокируют изобретательность исполнителей.

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

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

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

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

Глава 5. Эффект второй системы

Adde parvum parvo magnus acervus erit.

[Складывай малое с малым, и получишь большую кучу.]

ОВИДИЙ

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

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

Дисциплина взаимодействия для архитектора

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

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

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

Чтобы успешно справиться с этим, архитектору необходимо:

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

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

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

- не рассчитывать на признательность за сделанные предложения.

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

Самодисциплина - эффект второй системы

Первый проект архитектора стремится к скромности и ясности. Архитектор понимает, что не знает, чем занимается, поэтому он занимается этим со старанием и самоограничением.

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

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

Общая тенденция заключается в перегруженности проекта второй системы идеями и украшательствами, благоразумно отложенными в сторону при работе над первым проектом. В результате получается, говоря словами Овидия, "большая куча". Рассмотрим, например, архитектуру IBM 709, воплощенную позднее в машине 7090. Это - модернизация, вторя система для очень успешной и хорошо скроенной системы 704. Набор команд был настолько богат и изобилен, что регулярно использовалась примерно лишь половина его.

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

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

Operating System/360 была второй системой для большинства своих проектировщиков. Группы проектировщиков пришли после работы над дисковой операционной системой 1410-7010, операционной системой Stretch, системой реального времени Project Mercury и IBSYS для 7090. Едва ли кто-то из них имел опыт работы над двумя предшествующими операционными системами. Поэтому OS/360 является ярким примером эффекта второй системы, аналогом Stretch в искусстве программирования, к которому в полной мере применимы и похвалы, и упреки приведенной критики Стрейчи.

Например, в OS/360 отводится 26 байт для резидентной процедуры преобразования даты, чтобы правильно обрабатывать 31 декабря в високосном году (когда это 366-й день). Это можно было оставить оператору.

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

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

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

Более того, редактор связей требует так много памяти, и сам содержит столько оверлеев, что даже при использовании только для редактирования без управления оверлеями уступает в скорости большинству системных компиляторов. Ирония состоит в том, что назначение редактора связей - избежать повторной компиляции. Как у конькобежца корпус оказывается впереди ног, так и усовершенствования родолжались, пока не вышли далеко за рамки системных принципов.

Другим примером этой тенденции является отладчик TESTRAN. Это совершенный пакетный отладчик, предоставляющий действительно элегантные средства получения мгновенных снимков и дампов памяти. В нем используется понятие управляющих разделов и искусная технология генерации, позволяющие осуществлять избирательную трассировку и получение мгновенных снимков без дополнительных расходов на интерпретацию или рекомпиляцию. Здесь пышным цветом расцвели впечатляющие концепции операционной системы Share Operating System3 для модели 709.

Между тем устарела сама идея пакетной отладки без рекомпиляции. Главный вызов был брошен интерактивным вычислительным системам с интерпретаторами языков программирования и пошаговыми компиляторами. Но даже в системах с пакетной обработкой появление компиляторов с быстрой компиляцией и медленным выполнением сделало более предпочтительной технологию отладки на уровне исходного кода и получения мгновенных снимков. Насколько лучше оказалась бы система, если бы силы, потраченные на проект TESTRAN, были перенаправлены на ускоренное создание лучших средств для интерактивной работы и быстрой компиляции!

Еще один пример - планировщик, предоставляющий действительно отличные возможности для управления потоком фиксированных пакетов заданий. На практике этот планировщик является усовершенствованной, улучшенной и наделенной разными украшениями второй системой, которой предшествовала дисковая операционная система 1410-7010 - система пакетной обработки, не являющаяся многопрограммной, за исключением ввода-вывода, и предназначенной, главным образом, для деловых приложений. В этом качестве планировщик OS/360 хорош. Но на него почти никакого влияния не оказали потребности OS/360 в удаленном вводе заданий, многопрограммности и резидентном размещении интерактивных подсистем. И действительно, проект планировщика затрудняет решение этих задач.

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

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

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

Глава 6. Донести слово

Он сядет здесь и будет распоряжаться: "Сделайте это! Сделайте то!" А дело и с места не сдвинется.

ГАРРИ С. ТРУМЕН. "О ПРЕЗИДЕНТСКОЙ ВЛАСТИ"

Как менеджеру, имея опытных дисциплинированных архитекторов и достаточное число исполнителей, добиться того, чтобы все услышали, поняли и выполнили решения архитектора? Как группе из 10 архитекторов поддерживать концептуальную целостность системы, над которой трудится 1000 человек? Для достижения этого при осуществлении программы проектирования аппаратной части System/360 была разработана целая технология, которая в равной степени

применима для проектов создания программного обеспечения.

Письменные спецификации - руководство

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

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

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

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

Единство "Принципов работы System/360" проистекает из того, что у них было лишь два автора: Джерри Блау и Андрис Падега. Авторами идей являются порядка десяти человек, но если требуется соблюсти согласованность описания и продукта, отливку решений в прозаические спецификации должны осуществлять не более двух человек. Для написания определения требуется принять массу мини-решений, которые не столь важны, чтобы выносить их на всеобщее обсуждение. Для System/360 примером служат подробности того, как после каждой операции устанавливается код условия. Однако задача всеобщей согласованности таких мини-решений не является тривиальной.

Думаю, что лучший виденный мной образец руководства - это написанное Блау приложение к "Принципам работы System/360". В нем тщательно и точно описаны границы совместимости System/360. Дано определение совместимости, предписывается, к чему нужно стремиться, и перечислены те области внешних проявлений, где архитектура намеренно молчит, и где результаты, полученные на разных моделях, могут отличаться между собой, где разные экземпляры одной модели могут дать различные результаты и даже один и тот же экземпляр может давать различия после конструктивных изменений. Это уровень точности, к которому стремятся составители руководств. Они должны одинаково описывать как то, что можно делать, так и то, что делать нельзя.

Формальные определения

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

Рассмотрим достоинства и слабости формальных определений. Как отмечалось, формальные определения являются точными. Они тяготеют к полноте: пробелы заметнее, а потому скорее восстанавливаются. Их недостаток - трудность понимания. На английском языке можно описать структурные принципы, очертить структуры по этапам или по уровням и привести примеры. Легко отметить исключения и подчеркнуть противоположности. Еще важнее, что можно объяснить причины. Предлагавшиеся до сих пор формальные определения вызывали восхищение своей элегантностью и уверенность в их точности. Но они требовали текстуальных пояснений для облегчения изучения своего содержания. По этой причине я полагаю, что в будущем спецификации будут состоять как из формальных, так и из текстовых описаний.

Древнее изречение предупреждает о том, что в море нельзя выходить с двумя хронометрами: нужно взять один или три. То же, очевидно, применимо и к текстовым и формальным определениям. Если имеются оба вида, то один должен быть стандартом, а другой - производным описанием, о чем должно быть прямо указано. Основным стандартом может быть любой из них. В Algol 68 в качестве стандарта выбрано формальное определение, а текстовые определения являются описательными. В PL/I стандартом является текст, а формальное определение - производным. В System/360 также в качестве стандарта принят текст, а производными являются формальные описания.

Есть много средств создания формальных определений. Для определения языков часто используется форма Бэкуса-Наура, по которой есть богатая литература. В формальном описании PL/I используются новые обозначения абстрактного синтаксиса, надлежащим образом описанные.3 APL Иверсона был использован для описания машин, в частности, IBM 70904 и System/360. Белл и Ньюэлл предложили новые нотации для описания как конфигураций, так и машин, и проиллюстрировали их на нескольких машинах, включая DEC PDP-8,6 70906 и System/360.7

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

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

Программная модель аппаратной или программной системы может использоваться точно таким же образом. Это - реализация. Она работает. Поэтому все вопросы, связанные с определением, могут быть решены путем проверки.

Использование реализации в качестве определения имеет некоторые преимущества. Все проблемы можно однозначно решить путем эксперимента. Дискуссий не требуется, поэтому ответ получается быстро. Ответ может быть сколь угодно точным и, по определению, всегда является правильным. С другой стороны, есть значительное количество недостатков. Реализация может переопределять даже внешние спецификации. Даже при ошибочном синтаксисе всегда получается некоторый результат; в контролируемой системе этот результат является указанием на ошибку и ничем больше. В неконтролируемой системе могут возникнуть любые побочные эффекты и быть использованы программистами. Когда мы, например, эмулировали IBM 1401 на System/360, выявилось 30 различных "курьезов" - побочных эффектов предположительно незаконных операций, которые широко использовались и должны были быть признаны частью определения. Реализация в качестве определения возобладала. Она не только говорила о том, что должна делать машина, но и многое сказала о том, как машина не должна была это делать.

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

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

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

Прямое включение

У архитекторов программных систем есть чудесный метод распространения и внедрения определений. Он особенно полезен при установлении если не семантики, то синтаксиса межмодульных интерфейсов. Этот прием состоит в создании объявлений передаваемых параметров или совместно используемой памяти и требовании включения этих объявлений при операциях времени компиляции (макрос или %INCLUDE в PL/I). Если, кроме того, все ссылки на

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

Конференции и суды

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

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

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

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

Плодотворность этих совещаний обусловлена несколькими причинами:

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

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

3. При возникновении проблем решения ищутся как внутри, так и вне очевидных границ.

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

5. Открытое предоставление права принятия решения главному архитектору помогает избежать поиска компромиссов и задержек.

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

Эти сессии проводились накануне важных дат окончательного принятия разделов руководства. Присутствовали не только представители программистов и проектировщиков по архитектуре, но и менеджеры программных, маркетинговых и реализационных проектов. Председательствовал менеджер проекта System/360. Повестка работы включала обычно около 200 пунктов, в основном мелких, перечисленных в развешанных по комнате списках. Заслушивались все стороны и принимались решения. Благодаря чуду компьютерной верстки (и превосходной работе сотрудников) каждое утро каждый участник обнаруживал на своем рабочем месте исправленное руководство, в которое были внесены решения, принятые накануне.

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

Множественные реализации

У архитекторов System/360 было два почти беспрецедентных преимущества: достаточно времени для тщательной работы и такое же политическое влияние, как у проектировщиков. Наличие времени было обеспечено графиком по новой технологии; политическое равенство происходило благодаря одновременному созданию нескольких реализаций. Необходимость их строгой совместимости лучше всего способствовала исполнению спецификаций.

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

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

Журнал регистрации телефонных разговоров

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

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

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

Тестирование продукта

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

Последний анализ в качестве независимого аудитора осуществляет покупатель. В безжалостном свете практического применения станет виден каждый огрех. Группа тестирования продукта как раз заменяет покупателя,

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

Глава 7. Почему не удалось построить Вавилонскую башню?

На всей земле был один язык и одно наречие. Двинувшись с востока, они нашли в земле Сеннаар равнину и поселились там. И сказали друг другу: наделаем кирпичей и обожжем огнем. И стали у них кирпичи вместо камней, а земляная смола вместо извести. И сказали они: построим себе город и башню, высотою до небес, и сделаем себе имя прежде, нежели рассеемся по лицу всей земли. И сошел Господь посмотреть город и башню, которые строили сыны человеческие. И сказал Господь: вот, один народ, и один у всех язык; и вот что они начали делать, и не отстанут они от того, что задумали делать; сойдем же и смешаем там язык их, так чтобы один не понимал речи другого. И рассеял их Господь оттуда по всей земле; и они перестали строить город [и башню].

КНИГА БЫТИЯ 11:1-8

Аудит менеджмента Вавилонского проекта

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

1. Ясность цели? Да, хотя и наивно недостижимой. Проект провалился задолго до того, как столкнулся с эти принципиальным ограничением.

2. Человеческие ресурсы? В большом числе.

3. Материалы? Глина и битум в изобилии имеются в Месопотамии.

4. Достаточно времени? Да, нет никаких указаний на ограничения по времени.

5. Адекватные технологии? Да, пирамидальной или конической структуре присуща устойчивость и хорошее распределение нагрузки сжатия. Очевидно, свойства каменной кладки были хорошо известны. Проект провалился до того, как вышел за пределы технологических ограничений.

Так почему же провалился проект, если все это у них было? Чего у них не хватало? Двух вещей - обмена информацией и вытекающей из него организации. Они не могли разговаривать друг с другом и, как следствие, согласовывать усилия. Когда отказала координация, работа встала. Читая между строк, мы обнаруживаем, что отсутствие обмена информацией привело к спорам, дурному настроению и взаимной ревности. Вскоре кланы начали расходиться, предпочтя обособленность спорам.

Обмен информацией в большом программном проекте

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

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

Как же должны бригады обмениваться между собой информацией? Всеми возможными способами:

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

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

Таким путем устраняются сотни мелких непониманий.

- Рабочая тетрадь. В самом начале нужно завести рабочую тетрадь учета проделанной работы. Эта тема заслуживает отдельного раздела.

Рабочая тетрадь проекта

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

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

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

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

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

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

Механика. Как и во многих задачах управления программными проектами, проблема технических меморандумов усложняется нелинейным образом по мере увеличения объема данных. Если в работе участвуют 10 человек, документы можно просто пронумеровать. Если участвуют 100 человек, часто достаточно нескольких линейных последовательностей. Для 1000 сотрудников, неизбежно разбросанных по нескольким площадкам, возрастает потребность в структурированной рабочей тетради, и, следовательно, возрастает ее объем. Как поступать в этом случае?

Я думаю, мы правильно поступили при работе над проектом OS/360. На необходимости хорошо структурированной рабочей тетради особенно настаивал О.С. Локен, который убедился в ее эффективности при работе над своим предыдущим проектом, - операционной системой 1410-7010.

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

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

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

Наш проект не перешел и шестимесячного рубежа, когда мы столкнулись с другой проблемой. Толщина рабочей тетради составила около полутора метров! Если бы мы сложили в одну стопку требующиеся программистам 100 экземпляров в своих помещениях здания Time-Life в Манхеттене, она бы превысила по высоте само здание. Кроме того, ежедневные исправления имели толщину больше пяти сантиметров и насчитывали около 150 страниц, которые надо было заменить. Поддержка рабочей тетради стала занимать значительную часть ежедневного рабочего времени.

С этого времени мы перешли на микрофиши, что сберегло миллион долларов даже с учетом стоимости устройств для чтения микрофишей в каждом офисе. Мы смогли достичь отличной продолжительности цикла производства микрофишей. Рабочая тетрадь уменьшилась в объеме с 90 дм3 до 5 дм3 и, что более важно, обновления выпускались порциями по сотне страниц, стократно уменьшая сложность замены листов.

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

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

Обратите внимание, что сама рабочая тетрадь остается неизменной. Она по- прежнему остается собранием всей проектной документации, тщательно организованной. Единственное изменение - механизм распределения доступа. Д. С. Энглебарт с коллегами создали такую систему в Стэнфордском исследовательском институте и используют ее для ведения документации по сети ARPA.

Д. Л. Пранас и Университета Карнеги-Мелона предложил еще более радикальное решение. Он полагает, что производительность программиста выше всего, когда он огражден от подробностей конструкции тех частей системы, над которыми он не работает. Это предполагает, что все интерфейсы полностью и точно заданы. Такой проект определенно хорош, но если полагаться на его идеальное осуществление, это приведет к катастрофе. Хорошая информационная система не только должна выявлять ошибки в интерфейсах, но и способствовать их исправлению.

Организация крупного программного проекта

Если над проектом работает n человек, то существует (n2-n)/2 интерфейсов, через которые может происходить обмен данными, и потенциально существует почти 2n групп, внутри которых должно происходить согласование. Цель организации работы состоит в сокращении необходимого объема обмена информацией и согласования. Поэтому создание правильной организационной структуры является решающим направлением решения проблем информационного обмена, рассматривавшихся выше.

Способы, которыми сокращается обмен информацией, - разделение труда и специализация функций. Древовидная организационная структура отражает уменьшение потребности в подробном обмене информацией при использовании разделения труда и специализации.

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

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

1 - задание,

2 - продюсер,

3 - технический директор или архитектор,

4 - график работ,

5 - разделение труда,

6 - определение интерфейсов между разными частями.

Все перечисленное очевидно и обычно, исключая различие между продюсером и техническим директором. Сначала рассмотрим сами эти две функции, а затем их взаимоотношения.

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

А что же технический директор? Он постигает проект, который должен быть реализован, выявляет его составляющие, определяет, как он будет выглядеть внешне, и делает эскиз внутренней структуры. Он обеспечивает единство и концептуальную целостность проекта в целом и таким образом способствует ограничению сложности системы. При возникновении технических проблем он изыскивает их решения или при необходимости изменяет системный проект. Он, согласно прелестному выражению Ала Каппа, является "своим человеком в паршивых делах". Общение его происходит преимущественно внутри команды. Его работа почти исключительно техническая.

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

Возможны три типа отношений, и все они с успехом встречаются на практике.

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

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

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

Директор может быть начальником, а продюсер - его правой рукой. Роберт Хайнлайн ярко описывает такую организацию в "Человеке, продавшем Луну".

Костер закрыл лицо руками, затем взглянул вверх:

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

Гарриман очень мягко сказал:

- Не отчаивайся, Боб. Ты ведь недосыпал последнее время, правда? Вот что я скажу: мы перехитрим Фергюсона. Я возьму твой стол на несколько дней и построю организацию, которая оградит тебя от таких вещей. Я хочу, чтобы твои мозги были заняты векторами реакции, эффективностью топлива и сложностями проекта, а не контрактами по грузовикам. - Гарриман подошел к двери, выглянул наружу и заметил человека, который был, возможно, старшим клерком.

- Эй, вы! Подойдите сюда!

Человек показался озадаченным, встал и, подойдя к двери, спросил:

- Да?

- Я хочу, чтобы этот стол в углу и все, что на нем, были перенесены в пустую комнату на этом этаже, и немедленно.

Он проследил, как Костер и второй его стол переехали в другую комнату, убедился, что телефон в новом помещении отключен, и, подумав, заставил перенести туда диван.

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

Часа через три он позвал Баркли, чтобы познакомить его с Костером.

Главный инженер спал, сидя за столом, положив голову на руки. Гарриман хотел выйти, но Костер проснулся.

Прошу прощения, - сказал он, краснея, - я, наверное, задремал.

- Для этого я притащил тебе диван, - сказал Гарриман, - на нем удобнее.

Боб, познакомься с Джоком Беркли. Это твой новый раб. Ты остаешься главным инженером и неоспоримым начальником. Джок будет Главным лордом Все Остальное. С этого момента тебе абсолютно не о чем беспокоиться - исключая такую мелочь, как лунный корабль.

Они пожали руки.

- Хочу просить об одной вещи, мистер Костер, - сказал Беркли с серьезностью, - передавайте мне все, что сочтете необходимым - ваша сторона техническая, - но Бога ради, записывайте все, чтобы я был в курсе. Я хочу, чтобы вам на стол поставили выключатель, который будет управлять опечатанным магнитофоном на моем столе.

Отлично! - Гарриману показалось, что Костер помолодел.

- И если вам понадобится что-либо, не относящееся к технике, не занимайтесь этим сами. Нажмите выключатель и свистните. Все будет сделано. - Беркли взглянул на Гарримана. - Хозяин говорит, что собирается поговорить с вами о настоящей работе. Я вас покину и займусь делами. - Он вышел. Гарриман сел. Костер последовал его примеру и сказал:

- Уф! Так лучше?

Мне понравился этот Беркли.

- Это хорошо. Теперь это твой двойник. Не беспокойся: он работал у меня раньше. Ты почувствуешь себя, как в хорошей больнице.2

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

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

Глава 8. Объявляя удар

Практика - лучший учитель.

ПУБЛИЙ

Опыт - дорогой учитель, но для глупцов иного нет.

АЛЬМАНАХ БЕДНОГО РИЧАРДСА

(Бедный Ричардc - образ необразованного, но здравомыслящего доморощенного философа, созданный Бенджамином Франклином, издававшим в 1732-1757 годах ежегодный альманах и использовавшим этот псевдоним (примеч. перев.).)

Сколько времени потребует задача системного программирования? Сколько сил понадобится? Как можно это оценить?

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

Во-вторых, нужно учитывать, что оценки, полученные при создании отдельных небольших программ, нельзя применять для больших системных продуктов. К примеру, для программы, насчитывающей 3200 слов, Сакман, Эриксон и Грант оценивают суммарное время написания программ и отладки для одного программиста в 178 часов, что экстраполируется до 35800 операторов в год. Вдвое меньшая программа потребовала меньше четверти указанного времени, что при экстраполяции дает производительность, близкую уже к 80000 операторам в год. Необходимо добавить затраты времени на планирование, составление документации, тестирование, системную интеграцию и обучение. Линейная экстраполяция данных, относящихся к коротким задачам, бессмысленна. Если экстраполировать время, за которое можно пробежать стометровку, то окажется, что можно пробежать милю менее чем за три минуты.

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

Показанные на рис. 8.1 данные вызывают грустные чувства. График демонстрирует результаты, полученные в исследовании, проведенном Нанусом (Nanus) и Фарром (Farr)2 в System Development Corporation. В нем выявляется зависимость с показателем степени 1,5:

Объем работы = (константа) Ч (количество команд)1,5.

В другом исследовании, проведенном в этой компании, о котором сообщает Вайнвурм (Weinwurm)3, также получен показатель, близкий к 1,5.

Есть несколько исследований относительно производительности труда программиста, в которых предложен ряд технологий оценивания. Есть обзор опубликованных данных, подготовленный Моурином (Morin).4 Я приведу здесь лишь несколько наиболее показательных результатов.

PHOTO
Рис. 8.1 Затраты на программирование как функция размера программы

Данные Портмана

Чарльз Портман (Charles Portman), менеджер отдела программирования ICL - Computer Equipment Organization (Northwest) в Манчестере, предлагает свое понимание проблемы, которое может оказаться полезным.

Он обнаружил, что его команды программистов отстают от графиков примерно наполовину, т.е. каждое задание выполняется примерно вдвое дольше, чем предполагалось. При этом оценки очень тщательно проводились группами опытных экспертов, оценивавших в человеко-часах трудоемкость нескольких сотен подзадач с помощью диаграмм ПЕРТ. Когда выявлялось отставание от графика, он просил вести подробные ежедневные журналы использования времени. Из них выяснилось, что ошибка оценок полностью объясняется тем, что его команды использовали на программирование и отладку лишь 50 процентов рабочего времени. Остальное время терялось из-за отказов машины, на небольшие срочные посторонние задания, совещания, писание бумаг, дела фирмы, болезни, личное время и т.д. Короче оценки исходили из нереалистичного предположения о том, какая часть рабочего времени отводится непосредственно работе.

Данные Арона

Джоэл Арон (Joel Aron), менеджер IBM по системным технологиям в Гейтерсберге, штат Мэриленд, изучал эффективность труда программистов во время работы над девятью крупными системами (крупная соответствует более чем 25 программистам и 30000 операторов).7 Он классифицирует такие системы в соответствии с интенсивностью взаимодействия между программистами (и частями системы) и обнаруживает следующие величины производительности:

Очень слабое взаимодействие 10000 инструкций на человека в год

Некоторое взаимодействие 5000 инструкций на человека в год

Существенное взаимодействие 1500 инструкций на человека в год

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

Данные Харра

Джон Харр (John Harr), менеджер по программированию Electronic Switching System, входящей в состав Bell Telephone Laboratories, сообщил о своем собственном опыте и других известных ему данных в докладе на Объединенной конференции по компьютерам весной 1969 года. Эти данные приведены на рисунках 8.2, 8.3 и 8.4.

Наиболее поучителен и содержит больше данных рисунок 8.2. Первые два задания являются, по преимуществу, управляющими программами, а два вторых - языковыми трансляторами. Производительность измеряется в количестве отлаженных слов за человеко-год. При этом учитывается время программирования, отладки и системного тестирования. Неизвестно, учтены ли затраты на планирование, поддержку машины, составление документации и т.п.

PHOTO
Рис. 8.2 Сводка по четырем важнейшим программным проектам, осуществленным в ESS

Производительность разбивается на два класса: для управляющих программ составляет около 600 слов на человека за год, для трансляторов - около 2200.

Обратите внимание, что все четыре программы приблизительно одного размера, различие состоит в размере рабочих групп, продолжительности работы и количестве модулей. Что является причиной, а что - следствием? Была ли сложность причиной того, что для управляющих программ требовалось больше людей? Или же большее число модулей и человеко-месяцев обусловлено большим числом людей, привлеченных к работе? Была ли большая продолжительность выполнения вызвана сложностью проблем или многочисленностью занятых людей? Трудно сказать с уверенностью. Конечно, управляющие программы были более сложными. Если оставить в стороне эти неопределенности, то цифры описывают реальную производительность при создании больших систем, и потому представляют ценность.

На рисунках 8.3 и 8.4 показаны некоторые интересные данные о фактической скорости программирования и отладки в сравнении с прогнозом.

Данные OS/360

Опыт OS/360 подтверждает данные Харра, хотя данные по OS/360 не столь подробны. В группах разработки управляющей программы производительность составила 600-800 отлаженных команд в год на человека. В группах разработки трансляторов производительность достигла 2000-3000 отлаженных команд в год на человека. При этом учитывается планирование, тестирование компонентов, системное тестирование и некоторые затраты на поддержку. Насколько я могу судить, эти данные согласуются с результатами Харра.

PHOTO
Рис. 8.3 Предсказанная и фактическая скорость программирования
PHOTO
Рис. 8.4 Предсказанная и фактическая скорость отладки

Данные Арона, Харра и OS/360 дружно подтверждают резкие различия в производительности в зависимости от сложности и трудности самой задачи. В работе оценивания сложности я придерживаюсь той линии, что компиляторы втрое хуже обычных пакетных прикладных программ, а операционные системы втрое хуже компиляторов.

Данные Корбато

Данные Харра и OS/360 относятся к программированию на языке ассемблера. Есть немного публикаций относительно производительности системного программирования с использованием языков высокого уровня. Корбато (Corbato) из проекта MAC Массачусетского технологического института сообщает о средней производительности 1200 строк отлаженных операторов PL/I на человека в год при разработке операционной системы MULTICS (от 1 до 2 миллионов слов).

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

Но Корбато указывает количество строк за год на человека, а не слов! Каждому оператору в его системе соответствует от трех до пяти слов кода, написанного вручную! Из этого можно сделать два важных вывода:

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

- При использовании подходящего языка высокого уровня производительность можно повысить в пять раз.

Глава 9. Два в одном

Автору стоит присмотреться к Ною и... поучиться на примере Ковчега, как в очень маленькое пространство втиснуть очень много.

СИДНЕЙ СМИТ, "ЭДИНБУРГСКОЕ РЕВЮ"

Размер программы как стоимость

Какова стоимость программы? Если не считать времени выполнения, то помять, занимаемая программой, составляет главные издержки. Это верно даже для собственных разработок, когда пользователь платит автору существенно меньше, чем стоит разработка. Возьмем интерактивную систему IBM APL. Плата за ее использование составляет $400 в месяц. При работе она требует не меньше 160 Кбайт памяти. У машины Model 165 ежемесячная аренда 1 Кбайта памяти стоит около $12. Если пользоваться программой круглосуточно, то месячная плата составит $400 за пользование программой и $1920 за память. Если пользоваться системой APL лишь четыре часа в день, то месячная плата составит $400 за пользование программой и $320 за использование памяти.

Нередко можно встретить человека, выражающего ужас по поводу того, что в машине, имеющей 2 Мбайт памяти, под операционную систему может быть отведено 400 Кбайт. Это столь же глупо, как ругать Боинг-747 за то, что он стоит 27 миллионов долларов. Надо же спросить: "А что она делает?" Какую, собственно, простоту в использовании и производительность (посредством эффективного использования системы) получаешь за потраченные деньги? Нельзя ли вложенные в аренду памяти $4800 в месяц израсходовать с большей пользой - на другие аппаратные средства, программистов, прикладные программы?

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

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

Управление размером

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

Все же при работе над OS/360 пришлось извлечь несколько горьких уроков, несмотря на то, что все описанные меры были приняты.

Прежде всего, недостаточно установить размер памяти, нужно взвесить размер со всех сторон. Большинство прежних операционных систем размещалось на магнитных лентах, и большое время поиска на ленте не располагало к частой загрузке программных сегментов. OS/360 располагалась на диске, как и ее непосредственные предшественники - операционная система Stretch и дисковая операционная системы 1410-7010. Ее создатели получили свободу легкого обращения к диску. Первоначально это обернулось катастрофой для производительности.

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

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

К счастью, вскоре настал день, когда заработала система моделирования технических характеристик OS/360. Первые результаты показали наличие серьезных проблем. Моделирование компиляции с Fortran H на машине Model 65 с барабанами дало результат пять операторов в минуту! Анализ показал, что все модели управляющей программы делали множество обращений к диску. Даже интенсивно используемые модули супервизора часто обращались к диску, и результат по звуку весьма напоминал шелест перелистываемой книги.

Первая мораль ясна: планировать нужно как размер резидентной части, так и общий размер. Помимо планирования этих размеров нужно планировать и количество обращений к диску для обратной записи.

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

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

Поэтому второй вывод тоже совершенно ясен: при задании размера модуля нужно точно определить, что он должен делать.

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

Технологии сбережения памяти

Никакое распределение ресурсов памяти и контроль не сделают программу маленькой. Для этого требуется изобретательность и мастерство.

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

Если система проектируется для работы с памятью разного объема, возникает другой важный вопрос. Диапазон приспособляемости нельзя сделать произвольно широким - даже при разбиении программы на очень мелкие модули. В

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

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

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

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

Представление - суть программирования

За мастерством стоит изобретательность, благодаря которой появляются экономичные и быстрые программы. Почти всегда это является результатом стратегического прорыва, а не тактического умения. Иногда таким стратегическим прорывом является алгоритм, как, например, быстрое преобразование Фурье, предложенное Кули и Тьюки, или замена n2 сравнений на n log n при сортировке.

Гораздо чаще стратегический прорыв происходит в результате представления данных или таблиц. Здесь заключена сердцевина программы. Покажите мне блок- схемы, не показывая таблиц, и я останусь в заблуждении. Покажите мне ваши таблицы, и блок-схемы, скорей всего, не понадобятся: они будут очевидны.

Примеры мощи, которой обладает представление, легко умножить. Я вспоминаю одного молодого человека, занимавшегося созданием усовершенствованного консольного интерпретатора для IBM 650. Ему удалось вместить его в поразительно малое пространство благодаря разработке интерпретатора для интерпретатора и пониманию того, что взаимодействие человека с машиной происходит медленно и редко, а память дорога. Элегантный маленький компилятор с Fortran фирмы Digitek использует особое очень плотное представление кода самого компилятора, благодаря чему не требуется внешней памяти. Время, которое тратится на распаковку кода, десятикратно окупается за счет отсутствия ввода-вывода. (Упражнения в конце главы 6 книги Брукса и Иверсона "Автоматическая обработка данных"1 включает подборку таких примеров, как и многие упражнения у Кнута.2)

Программист, ломающий голову по поводу нехватки памяти, часто поступит лучше всего, оставив в покое свой код, вернувшись назад и хорошенько посмотрев свои данные. Представление - суть программирования.

Глава 10. Документарная гипотеза

Гипотеза:

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

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

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

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

Документы для проекта разработки компьютера

Предположим, что разрабатывается компьютер. Какие важнейшие документы должны быть разработаны?

Цели. Здесь описывается, какие потребности нужно удовлетворить, а также задачи, пожелания, ограничения и приоритеты.

Спецификации. Это руководство по компьютеру плюс спецификации технических характеристик. Это один из первых документов, составляемых для нового продукта, и завершается он последним.

График.

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

Организационная структура.

Пространственное расположение.

Оценка, прогноз, цены. Они находятся в циклической взаимосвязи, что определяет успех или провал проекта:

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

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

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

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

Документы для факультета в университете

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

Цели.

Описание курса.

Требования к соискателю степени.

Предложения по исследовательской работе (и планы, при наличии финансирования).

Расписание занятий и назначение преподавателей.

Бюджет.

Помещения.

Назначение руководителей для аспирантов.

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

Документы для программного проекта

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

Что: цели. Здесь определяется, какие потребности должны быть удовлетворены, а также задачи, пожелания, ограничения и приоритеты.

Что: спецификации продукта. Начинается как предложение, а кончается как руководство и внутренняя документация. Важнейшей частью являются спецификации скорости и памяти.

Когда: график.

По какой цене: бюджет.

Где: расположение помещений.

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

Зачем нужны формальные документы?

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

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

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

Я не разделяю выдвигаемых продавцами видений "всеохватывающей информационной системы для управления", в которой администратор вводит в компьютер запрос с клавиатуры, и на экране вспыхивает нужный ему ответ. Есть много фундаментальных причин, по которым этого не произойдет. Одна причина заключается в том, что только маленькая часть, возможно 20 процентов, рабочего времени администратора занята задачами, которые требуют сведений, отсутствующих в его памяти. А все остальное время - это общение: слушать, отчитываться, обучать, убеждать, советовать, ободрять. Но для той доли, для которой действительно нужны данные, необходимы несколько важных документов, которые удовлетворяют большинство нужд.

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


На сайт webkomora.com.ua :
Обзор
Посвящения
Глава 1. Смоляная яма
Глава 2. Этот мифический "человеко-месяц"
Глава 3. Операционная бригада
Глава 4. Аристократия, демократия и системное проектирование
Глава 5. Эффект второй системы
Глава 6. Донести слово
Глава 7. Почему не удалось построить Вавилонскую башню?
Глава 8. Объявляя удар
Глава 9. Два в одном
Глава 10. Документарная гипотеза
Глава 11. Планируйте на выброс
Глава 12. Острый инструмент
Глава 13. Целое и части
Глава 14. Назревание катастрофы
Глава 15. Обратная сторона
Глава 16. Серебряной пули нет - сущность и акциденция в программной инженнерии
Глава 17. Новый выстрел "Серебряной пули нет"
Глава 18. Заявления "Мифического человеко-месяца": правда или ложь?
Глава 19 "Мифический человеко-месяц" двадцать лет спустя
Примечания и ссылки

Возврат на главную страницу
Hosted by uCoz