Фредерик Брукс Мифический человеко-месяц или как создаются программные системы
Фредерик БРУКС
Мифический человеко-месяц или как создаются программные системы
Посвящение издания 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 находится программа. Она является завершенным продуктом, пригодным для запуска своим автором на системе, на которой была разработана. В гаражах обычно производится такой продукт, и это — тот объект, посредством которого отдельный программист оценивает свою производительность.
Есть два способа, которыми программу можно превратить в более полезный, но и более дорогой объект. Эти два способа представлены по краям рисунка.
При перемещении вниз через горизонтальную границу программа превращается в программный продукт. Это программа, которую любой человек может запускать, тестировать, исправлять и развивать. Она может использоваться в различных операционных средах и со многими наборами данных. Чтобы стать общеупотребительным программным продуктом, программа должна быть написана в обобщенном стиле. В частности, диапазон и вид входных данных должны быть настолько обобщенными, насколько это допускается базовым алгоритмом. Затем программу нужно тщательно протестировать, чтобы быть уверенным в ее надежности. Для этого нужно подготовить достаточное количество контрольных примеров для проверки диапазона допустимых значений входных данных и определения его границ, обработать эти примеры и зафиксировать результаты. Наконец, развитие программы в программный продукт требует создания подробной документации, с помощью которой каждый мог бы использовать ее, делать исправления и расширять. Я пользуюсь практическим правилом, согласно которому программный продукт стоит, по меньшей мере, втрое дороже, чем просто отлаженная программа с такой же функциональностью.
Рис. 1.1 Эволюция системного программного продукта
При пересечении вертикальной границы программа становится компонентом программного комплекса. Последний представляет собой набор взаимодействующих программ, согласованных по функциям и форматам, и вкупе составляющих полное средство для решения больших задач. Чтобы стать частью программного комплекса, синтаксис и семантика ввода и вывода программы должны удовлетворять точно определенным интерфейсам. Программа должна быть также спроектирована таким образом, чтобы использовать заранее оговоренный бюджет ресурсов — объем памяти, устройства ввода/вывода, процессорное время. Наконец, программу нужно протестировать вместе с прочими системными компонентами во всех сочетаниях, которые могут встретиться. Это тестирование может оказаться большим по объему, поскольку количество тестируемых случаев растет экспоненциально. Оно также занимает много времени, так как скрытые ошибки выявляются при неожиданных взаимодействиях отлаживаемых компонентов. Компонент программного комплекса стоит, по крайней мере, втрое дороже, чем автономная программа с теми же функциями. Стоимость может увеличиться, если в системе много компонентов.
В правом нижнем углу рисунка 1.1 находится системный программный продукт. От обычной программы он отличается во всех перечисленных выше отношениях. И стоит, соответственно, в десять раз дороже. Но это действительно полезный объект, который является целью большинства системных программных проектов.
Радости профессии
Почему заниматься программированием интересно? Какими радостями вознаграждаются те, кто им занимается?
Во-первых, это просто радость, получаемая при создании чего-либо своими руками. Как ребенок радуется, делая куличики из песка, так и взрослый получает удовольствие, создавая какие-либо вещи, особенно если сам их и придумал. Я думаю, что этот восторг — отражение восторга Господа, творящего мир, восторга, проявляющегося в индивидуальности и новизне каждого листочка и каждой снежинки.
Во-вторых, это удовольствие создавать вещи, которые могут быть полезны другим людям. Глубоко в душе мы испытываем потребность в том, чтобы другие использовали результаты нашего труда и считали их полезными. В этом отношении программная система по своей сути — то же, что и изготовленная ребенком подставка для карандашей «папе в подарок».
В-третьих, это очарование создания сложных головоломных объектов, состоящих из взаимодействующих движущихся частей и наблюдения за их работой, круг за кругом демонстрирующей результаты изначально заложенных принципов. Компьютер с работающей на нем программой обладает доведенным до высшего предела очарованием игорного или музыкального автомата.
В-четвертых, это радость, получаемая от неизменного узнавания нового, проистекающего из неповторимой природы задачи. В том или ином отношении задача всегда ставится по-новому, и тот, кто ее решает, получает новые знания — либо практические, либо теоретические, либо те и другие вместе.
Наконец, наслаждение доставляет работа со столь податливым материалом. Программист, подобно поэту, работает почти непосредственно с чистой мыслью. Он строит свои замки в воздухе и из воздуха, творя силой воображения. Трудно найти другой материал, используемый в творчестве, который столь же гибок, прост для шлифовки или переработки и доступен для воплощения грандиозных замыслов. (Как мы позднее увидим, такая податливость таит свои проблемы.)
Однако программная конструкция, в отличие от поэтических творений, реальна, в том смысле, что она движется и работает, производя видимые результаты, которые отделимы от самой конструкции. Она печатает результаты, рисует картинки, производит звуки, приводит в движение рычаги. В наше время осуществилось волшебство мифа и легенды. С клавиатуры вводится верное заклинание, и экран монитора оживает, показывая то, чего никогда не было и не могло быть.
Таким образом, программирование доставляет удовольствие, поскольку отвечает глубокой внутренней потребности в творчестве и удовлетворяет чувственные потребности, которые есть у всех нас.
Печали профессии
Не все, однако, в радость, и если предвидеть присущие этому ремеслу огорчения, то они легче переносятся.
Во-первых, необходима безошибочная точность действий. В этом отношении компьютер также напоминает волшебство. Один неверный знак, одна пауза в заклинании, и чудо не состоялось. Человеку несвойственно совершенство, и оно является необходимым лишь в немногих сферах его деятельности. Мне кажется, что при освоении программирования труднее всего привыкнуть к требованию совершенства.[1]
Кроме того, постановка задач, обеспечение ресурсами и предоставление информации осуществляется другими людьми. Редко удается контролировать условия работы и даже ее цели. На языке администрирования это означает, что полномочия ниже ответственности. Впрочем, похоже, что в любой работе, где должен быть получен результат, формальная власть никогда не соизмерима с ответственностью. На практике фактическая (в противоположность формальной) власть приобретается в результате успешного выполнения задач.
Зависимость от других имеет особенно неприятную системному программисту сторону. Он находится в зависимости от программ, написанных другими людьми, и эти программы зачастую плохо спроектированы, слабо написаны, получены в неполном виде (без исходного текста и контрольных примеров) и плохо документированы. Поэтому программисту приходится тратить многие часы на изучение и исправление вещей, которые, в идеале, должны быть полными, доступными и годными к использованию.
Следующий «минус» связан с тем, разработка грандиозных идей — это удовольствие, а поиск паршивых маленьких «жучков» — это всего лишь работа. В каждом творческом деле бывают ужасные периоды однообразного и кропотливого труда, и программирование не является исключением.
Далее оказывается, что при отладке программы сходимость является линейной, если не хуже, хотя можно было предполагать некое квадратичное приближение к окончанию. В итоге отладка продолжается долго, причем на поиск последних более сложных ошибок уходит больше времени, чем на отыскание первых.
Последняя горесть, а часто и последняя капля, — то, что продукт, на который было положено столько труда, оказывается устаревшим в момент его завершения (или даже раньше). Коллеги и конкуренты уже с пылом работают над новыми и лучшими идеями. И уничтожение плода вашей мысли уже не только задумано, но и запланировано.
На самом деле положение обычно лучше, чем кажется. В то время как ваш продукт уже завершен, этот новый и лучший продукт, как правило, отсутствует на рынке, о нем лишь много разговоров, и для его разработки потребуются месяцы. Настоящий тигр не пара бумажному, если требуется реальное использование. Реальное существование имеет преимущества.
Конечно, технологическая основа разработки всегда развивается. Как только разработка проекта закончена, он становится устаревшим в смысле заложенных в нем концепций. Но для осуществления реального проекта необходимо разбиение на стадии и уровни. Судить о том, является ли некая реализация устаревшей, можно лишь сравнивая ее с другими существующими реализациями, а не с нереализованными идеями. Трудность и цель состоят в том, чтобы найти реальные решения для реальных задач в установленные сроки, используя имеющиеся ресурсы.
Таково программирование — и смоляная яма, в которой увязли многие проекты, и творчество со своими радостями и печалями. Для многих радости значат гораздо больше, чем печали. Для них и написана эта книга в попытке проложить какие-то мостки через это болото.
Глава 2 Этот мифический «человеко-месяц»
Чтобы приготовить вкусную пищу, требуется время. Если вам пришлось ждать, то лишь потому, что мы хотим лучше обслужить вас и доставить вам удовольствие.
МЕНЮ РЕСТОРАНА «АНТУАН» В НЬЮ-ОРЛЕАНЕ
Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам вместе взятым. Почему эта причина неудач столь распространена?
Во-первых, слабо развиты наши методы оценок. В сущности, они отражают молчаливое и совершенно неверное предположение, что все будет идти хорошо.
Во-вторых, наши методы оценки ошибочно путают достигнутый прогресс с затраченными усилиями, неявно допуская, что скорость выполнения проекта пропорциональна количеству занятых в нем сотрудников.
В-третьих, поскольку менеджеры программных проектов не уверены в своих оценках, им часто недостает вежливого упрямства, как у шеф-повара ресторана «Антуан».
В-четвертых, выполнение графика работ слабо контролируется. Типовые опробованные в других инженерных дисциплинах методы считаются радикальными нововведениями при разработке программного обеспечения.
В-пятых, при обнаружении отставания от графика естественной и общепринятой реакцией является увеличение числа разработчиков. Это все равно, что тушить пламя бензином. В результате дела идут значительно хуже. Чем сильнее пламя, тем больше нужно бензина, и в итоге этот путь приводит к катастрофе.
Контроль выполнения графика будет предметом отдельного разговора. Рассмотрим более подробно остальные аспекты проблемы.
Оптимизм
Все программисты — оптимисты. Возможно, эта современная разновидность колдовства особенно привлекательна для тех, кто верит в хэппи-энды и добрых фей. Возможно, сотни неудач отталкивают всех, кроме тех, кто привык сосредоточиваться на конечной цели. А может быть, дело всего лишь в том, что компьютеры и программисты молоды, а молодости свойствен оптимизм. Как бы то ни было, в результате одно: «На этот раз она точно пойдет!» Или : «Я только что выявил последнюю ошибку!»
Итак, в основе планирования разработки программ лежит ложное допущение, что все будет хорошо, т.е. каждая задача займет столько времени, сколько «должна» занять.
Глубокий оптимизм программистов заслуживает более серьезного изучения. Дороти Сэйерс (Dorothy Cayers) в своей превосходной книге «Разум творца» (“The Mind of the Maker”) выделяет в творческой деятельности три стадии: замысел, реализацию, взаимодействие. Соответственно, книга, компьютер или программа сначала возникают как идеальное построение, существующее не во времени и пространстве, а лишь в мозгу своего создателя. Реализация же во времени и пространстве происходит с помощью пера, чернил, бумаги, либо — проводов, кремния и феррита. Творение будет завершено, когда кто-либо прочтет книгу, воспользуется компьютером или запустит программу, тем самым вступив во взаимодействие с разумом их создателя.
Это описание используемое Сэйерс для освещения не только творческой деятельности человека, но и христианского догмата Троицы, поможет нам в нашей текущей задаче. Для человека, который что-то создает, неполнота и противоречивость идей выявляются только при их реализации. Поэтому для теоретика изложение на бумаге, экспериментирование, изготовление является неотъемлемыми частями творческого процесса.
Во многих видах творческой деятельность материал с трудом поддается обработке. Дерево колется, краски пачкаются, электрические цепи «звенят». Эти физические ограничения сужают круг идей, которые могут быть выражены, а также создают неожиданные трудности при реализации.
Реализация, таким образом, требует сил и времени как из-за физического материала, так и ввиду неадекватности основополагающих идей. Большую часть затруднений при реализации мы склонны объяснять недостатками физического материала, поскольку он «чужд» нам — в отличие от идей, которыми мы гордимся.
При создании же программ мы имеем дело с чрезмерно податливым материалом. Программист осуществляет свои построения на основе чистого мышления — понятий и очень гибких их представлений. Поскольку материал столь податлив, мы не ожидаем трудностей при реализации, отсюда и наш глубокий оптимизм. Из-за ошибочности наших идей возникают ошибки в программах. Следовательно, наш оптимизм не имеет оправдания.
Для отдельной задачи допущение, что все буде хорошо, оказывает на график работ вероятностный эффект. Все может действительно идти по плану, поскольку есть некоторое распределение вероятности для возможной задержки и существует конечная вероятность того, что задержки не будет. Однако большой программный проект состоит из множества задач, часть из которых может быть начата только после окончания других. Вероятность того, что все задачи будут завершены в срок, бесконечно мала.
Человеко-месяц
Вторая ошибка рассуждений заключена в самой единице измерения, используемой при оценивании и планировании: человеко-месяц. Стоимость действительно измеряется как произведения числа занятых на количество затраченных месяцев. Но не достигнутый результат. Поэтому использование человеко-месяца как единицы измерения объема работы является опасным заблуждением.
Рис. 2.1 Зависимость времени от числа занятых — полностью разделимая задача
Число занятых и число месяцев являются взаимозаменяемыми величинами лишь тогда, когда задачу можно распределить среди ряда работников, которые не имеют между собой взаимосвязи (рис. 2.1). Это верно, когда жнут пшеницу или собирают хлопок, но в системном программировании это далеко не так.
Рис. 2.2 Зависимость времени от числа занятых — неразделимая задача
Если задачу нельзя разбить на части, поскольку существуют ограничения на последовательность выполнения этапов, то увеличение затрат не оказывает влияния на график (рис. 2.2). Чтобы родить ребенка требуется девять месяцев независимо от того, сколько женщин привлечено к решению данной задачи. Многие задачи программирования относятся к этому типу, поскольку отладка по своей сути носит последовательный характер.
Рис. 2.3 Зависимость времени от числа занятых — разделимая задача, требующая обмена данными
Для задач, которые могут быть разбиты на части, но требуют обмена данными между подзадачами, затраты на обмен данными должны быть добавлены к общему объему необходимых работ. Поэтому достижимый наилучший результат оказывается несколько хуже, чем простое соответствие числа занятых и количества месяцев (рис. 2.3).
Дополнительная нагрузка состоит из двух частей — обучения и обмена данными. Каждого работника нужно обучить технологии, целям проекта, общей стратегии и плану работы. Это обучение нельзя разбить на части, поэтому данная часть затрат изменяется линейно в зависимости от числа занятых.
Рис. 2.4 Зависимость времени от числа занятых — задача со сложными взаимосвязями
С обменом данными дело обстоит хуже. Если все части задания должны быть отдельно скоординированы между собой, то затраты возрастают как n(n-2)/2. Для трех работников требуется втрое больше попарного общения, чем для двух, для четырех — вшестеро. Если помимо этого возникает необходимость в совещаниях трех, четырех и т.д. работников для совместного решения вопросов, положение становится еще хуже. Дополнительные затраты на обмен данными могут полностью обесценить результат дробления исходной задачи и привести к положению, описываемому рисунком 2.4.
Поскольку создание программного продукта является по сути системным проектом — практикой сложных взаимосвязей, затраты на обмен данными велики и быстро начинают преобладать над сокращением сроков, достигаемым в результате разбиения задачи на более мелкие подзадачи. В этом случае привлечение дополнительных работников не сокращает, а удлиняет график работ.
Системное тестирование
Из всех элементов графика работ наибольшему воздействию со стороны ограничений на последовательность выполнения действий подвержены отладка компонентов и системное тестирование. Кроме того, затраты времени зависят от количества выявленных ошибок и от того, насколько они «скрытые». Теоретически, ошибок быть не должно. Из-за своего оптимизма мы обычно склонны недооценивать действительное количество ошибок. Поэтому в программировании придерживаться графиков работ обычно труднее всего при отладке.
В течение ряда лет при планировании разработки программного обеспечения я пользуюсь следующим эмпирическим правилом:
1/3 — планирование,
1/6 — написание программ,
1/4 — тестирование компонентов и предварительное системное тестирование,
1/4 — системное тестирование при наличии всех компонентов.
Это правило имеет несколько важных различий с общепринятым планированием:
1. На планирование отводится больше времени, чем обычно. И все равно этого времени едва достаточно для разработки подробных и надежных технических условий и недостаточно для проведения исследовательских работ или поиска новейших технологий.
2. Половина графика работ, отведенная на отладку законченного кода, значительно выше нормы.
3. Та часть, которую легко оценить, т.е. написание кода, занимает всего одну шестую общего времени.
Изучая проекты, график которых был составлен традиционным образом, я обнаружил, что немногие из них отводили по графику половину времени на отладку, но на практике в большинстве случаев тратили на нее половину фактического времени. Многие проекты укладывались в график на всех этапах, исключая системное тестирование.[2]
Особенно катастрофические последствия может иметь недостаток времени для системного тестирования. Поскольку задержка происходит в конечной части графика, никто не подозревает о том, что график находится под угрозой срыва вплоть до дня сдачи продукта. Плохие вести, полученные поздно и без предупреждения, обескураживают клиентов и менеджеров.
Более того, задержка на этом этапе имеет особенно тяжелые материальные и психологические последствия. Проект осуществляется при полной
укомплектованности работниками и максимальных финансовых издержках. Что важнее, программное обеспечение должно обеспечить поддержку другой деловой активности (поставки компьютеров, запуска новых производственных мощностей и т.п.), и связанные с задержкой вторичные издержки очень высоки. На практике эти вторичные издержки могут быть выше, чем все прочие. Поэтому очень важно в изначальном графике работ отвести достаточно времени для системного тестирования.
Робость в оценках
Для программиста, как и для повара, давление со стороны хозяина может определять запланированный срок завершения задачи, но не может определять время ее фактического завершения. Омлет, обещанный через две минуты, может успешно жариться, но если через две минуты он не готов, то у клиента есть две возможности: ждать еще или съесть его сырым. Тот же выбор встает и перед заказчиком программного обеспечения.
У повара есть еще одна возможность: добавить жару. В результате омлет часто оказывается безнадежно испорченным: горелым с одного края и сырым — с другого.
Я не думаю, что у менеджеров программных продуктов меньше храбрости или твердости, чем у поваров или других менеджеров в инженерных областях. Но липовые графики, нацеленные на желательную хозяину дату, встречаются здесь значительно чаще, чем в любых других инженерных областях. Очень тяжело, рискуя потерять рабочее место, с энергией и любезностью отстаивать срок, который определен без применения каких-либо количественных методов при недостатке данных и подкреплен, в основном, интуицией менеджера.
Очевидно, необходимо сделать две вещи. Мы должны получить и сделать общедоступными численные данные, характеризующие производительность, частоту программных ошибок, методы оценки и т.д. Вся отрасль может только выиграть от опубликования таких данных.
Пока методы оценивания не получат более прочной основы, менеджерам остается только мужаться и защищать свои прогнозы, утверждая, что полагаться на их слабую интуицию все же лучше, чем основываться на одних желаниях.
Действия при срыве графика
Что делают, когда важный программный проект начинает отставать от графика? Естественно, добавляют людей. Как показывают рисунки 2.1-2.4, это не всегда помогает.
Рассмотрим пример.[3] Предположим, что трудоемкость задачи оценивается в 12 человеко-месяцев, и три человека должны выполнить ее за 4 месяца, причем в конце каждого месяца имеются четыре контрольные точки A, B, C и D, в которых можно произвести измерения (рис. 2.5).
Рис. 2.5
Предположим теперь, что первая контрольная точка была достигнута лишь по истечении двух месяцев. Какие альтернативы имеются у менеджера?
1. Допустим, что необходимо соблюсти срок выполнения задачи, и ошибочно оценена была только первая часть задачи, т.е. рисунок 2.6 верно отражает положение. Значит, остается 9 человеко-месяцев трудозатрат и два месяца, поэтому понадобится 4Ѕ человека, и к троим имеющимся нужно добавить еще двоих.
Рис. 2.6
2. Допустим, что необходимо соблюсти срок выполнения задачи, и одинаково занижена была вся оценка, т.е. положение соответствует рисунку 2.7. Значит, остается 18 человеко-месяцев трудозатрат и два месяца, поэтому понадобится 9 человек. К троим имеющимся нужно добавить еще шестерых.
Рис. 2.7
3. Изменить график. Мне нравится замечание, сделанное П. Фаггом (P. Fagg), опытным инженером по вычислительной технике: «Маленьких задержек не бывает». Это означает, что в новом графике должно быть достаточно времени, чтобы работа была исполнена тщательно и полностью, и не пришлось бы вновь переделывать график.
4. Сократить задачу. На практике этим всегда и кончается, когда команда обнаруживает, что не укладывается в график. Когда очень высоки вторичные издержки, это единственное, что можно сделать. Менеджеру предоставляется возможность официально и аккуратно сократить задачу, изменить график, либо наблюдать, как задача молча урезается при поспешном изменении проекта и неполном тестировании.
В первых двух случаях настаивать на том, чтобы задача в неизменном виде была выполнена за четыре месяца, чревато катастрофой. Рассмотрим, к примеру, восстановительный эффект первой альтернативы (рис. 2.8). Двое новых работников, какими бы знающими они ни были, и как бы быстро не удалось их найти, должны изучить задачу с помощью одного из опытных разработчиков. Если для этого потребуется месяц, то 3 человеко-месяца будут потрачены на работу, которая не учитывается в исходной оценке. Кроме того, задача, разбитая первоначально на три потока, должна быть теперь перекроена на пять частей. Поэтому часть уже сделанной работы будет потеряна, а системное тестирование нужно будет продлить. В результате в конце третьего месяца останется работы существенно больше, чем на 7 человеко-месяцев, а в распоряжении будет 5 подготовленных человек и один месяц. Согласно рисунку 2.8 продукт будет запаздывать так же, как если бы ни одного человека не было добавлено (см. рис. 2.6).
Если рассчитывать управиться за четыре месяца с учетом только времени обучения, но не перераспределения задач и дополнительного системного тестирования, то в конце второго месяца потребуется добавить 4, а не 2 человека. Чтобы компенсировать воздействие перераспределения задач и системного тестирования, потребуются еще новые люди. Теперь, однако, команда состоит не из 3, а, по крайней мере, 7 человек, и такие вопросы, как организация команды и распределение задач приобретают новый качественный уровень.
Обратите внимание, что к концу третьего месяца дело выглядит весьма мрачно. Несмотря на все административные усилия контрольная точка, намеченная на 1 марта, не достигнута. Возникает сильный соблазн повторить цикл, добавив еще людей. Это безумное решение.
Рис. 2.8
В предшествующих рассуждениях предполагалось, что только первая контрольная точка была неверно рассчитана. Если 1 марта сделать консервативное предположение, что весь график был излишне оптимистичен, как отражено на рисунке 2.7, требуется добавить 6 человек к исходной задаче. Расчет воздействия обучения, перераспределения задач и системного тестирования предоставляется сделать читателю в качестве упражнения. Нет сомнений, что при попытке уложиться в срок в итоге получится худший продукт, чем при изменении графика и сохранении первоначальных троих человек без усиления.
Крайне упрощая, сформулируем Закон Брукса:
Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
Это развенчивает миф о человеко-месяце. Продолжительность осуществления проекта зависит от ограничений, накладываемых последовательностью работ. Максимальное количество разработчиков зависит от числа независимых подзадач. Эти две величины позволяют получить график работ, в котором будет меньше занятых разработчиков и больше месяцев. (Единственная опасность заключается в возможном устаревании продукта.) Нельзя, однако, составить работающие графики, в которых занято больше людей и требуется меньше времени. Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам вместе взятым.
Глава 3 Операционная бригада
Эти исследования выявили большие индивидуальные различия в производительности между лучшими и худшими работниками, часто на порядок величин.
САКМАН, ЭРИКСОН И ГРАНТ[1]
На встречах компьютерных специалистов можно постоянно слышать утверждения молодых менеджеров программных проектов, что им предпочтительней небольшие деятельные команды первоклассных специалистов, чем проекты, в которых участвуют сотни программистов, что подразумевает их средний уровень. И всем нам тоже.
Такое наивное представление альтернатив уходит от решения сложной задачи — как создавать большие системы в разумные сроки? Рассмотрим этот вопрос более подробно со всех сторон.
Проблема
Менеджеры программных проектов давно поняли, что хорошие и плохие программисты очень сильно различаются между собой по производительности. Однако реально измеренные величины поразительны. В одном из исследований Сакман (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.
В статье Бейкера [3] сообщается об одной проверке такой концепции бригады, проведенной в ограниченном масштабе. Как и предсказывалось, результаты оказались великолепными.
Масштабирование
До сих пор все было хорошо. Проблема, однако, состоит в том, как создавать продукты, на которые сейчас уходит не 20 или 30, а 5000 человеко-лет. Бригада из 10 человек может быть эффективна вне зависимости от своей организации, если задача целиком находится в ее компетенции. Но как использовать идею операционной бригады в задачах, для выполнения которых привлекаются сотни людей?
Успех при масштабировании обусловливается коренным улучшением концептуального единства каждого участка, ведь количество проектировщиков уменьшилось в семь раз. Поэтому можно привлечь к работе над задачей 200 человек, и необходимость координации умственных усилий потребуется всего для 20 из них — хирургов.
Рис. 3.1 Схема контактов между сотрудниками в бригаде из 10 человек
Однако задача координации требует использования особых методов, обсуждаемых в последующих главах. Пока достаточно сказать, что вся система в целом должна обладать концептуальным единством, и необходим системный архитектор, чтобы проектировать ее целиком, в нисходящем направлении. Для того чтобы этой работой можно было управлять, необходимо провести строгое разграничение архитектуры и воплощения, и системный архитектор должен добросовестно посвятить себя разработке архитектуры. Опыт показывает, что такое распределение ролей и такие методы осуществимы и оказываются весьма результативными.
Глава 4 Аристократия, демократия и системное проектирование
Этот величественный храм является выдающимся произведением искусства. В принципах, которые он излагает, нет ни сухости, ни беспорядка…
Это вершина стиля, труд художников, которые поняли и восприняли все достижения своих предшественников, в совершенстве владея техникой своего века, но пользовались ей, избегая нескромного показа или необоснованной демонстрации мастерства.
Несомненно, замысел общего плана здания принадлежит д’Орбе, и те, кто его сменил, придерживались этого плана, по крайней мере, в существенных чертах. Это одна из причин удивительной гармоничности и единства здания.
ПУТЕВОДИТЕЛЬ ПО РЕЙМСКОМУ СОБОРУ[1]
Концептуальное единство
У большинства европейских соборов части, построенные разными поколениями строителей, имеют различия в планировке и архитектурном стиле. Более поздние строители испытывали соблазн «улучшить» проект своих предшественников, чтобы отразить новые веяния моды и свои личные вкусы. В итоге мирный норманнский трансепт создает конфликт с примыкающим к нему возносящимся в высь готическим нефом, и результат столь же служит восхвалению славы Господней, сколь и гордыни строителей.
Архитектурное единство Реймского собора находится в прямой противоположности с таким смешением стилей. Источником наполняющей зрителя радости служат как цельность конструкции, так и отдельные образцы совершенства. Как сказано в путеводителе, цельность была достигнута благодаря самоотречению восьми поколений строителей собора, пожертвовавших своими идеями ради чистоты общего замысла. То что получилось в результате, служит восхвалению не только славы Господней, но и Его могущества, способного спасти грешных людей от их гордыни.
Хотя на создание программных систем не уходят века, в большинстве своем они демонстрируют меньшую согласованность концепций, чем в любом соборе. Обычно это происходит не оттого, что главные проектировщики сменяют друг друга, а потому, что проект расщепляется на ряд задач, выполняемых разными разработчиками.
Я убежден, что концептуальная целостность является важнейшей характеристикой системного проекта. Лучше убрать из системы отдельные необычные возможности и усовершенствования и реализовать единый набор конструктивных идей, чем оснастить ее многими хорошими, но невзаимосвязанными и несогласованными идеями. В этой и двух последующих главах мы изучим следствия этой концепции для проектирования программных систем:
• Как достичь концептуальной целостности?
• Не будет ли это требование причиной раскола на элиту, аристократический класс архитекторов — с одной стороны, и толпы плебеев-исполнителей, чьи творческие таланты и идеи подавляются, — с другой?
• Как удержать архитекторов от витания в облаках и разработки несущественных или чрезмерно дорогих спецификаций?
• Как добиться того, чтобы любая мелочь из созданной архитектором спецификации дошла до исполнителя, была им правильно понята и точно внедрена в продукт?
Достижение концептуальной целостности
Назначение системы программирования — облегчить использование компьютера. Для этого поставляются языки и различные средства, являющиеся, по сути, программами, вызываемыми и управляемыми возможностями языка. Но эти средства стоят денег: объем внешнего описания системы программирования в десять-двадцать раз больше описания собственно вычислительной системы. Пользователю оказывается значительно проще задать любую выбранную функцию, но выбор очень велик, и нужно помнить значительно больше вариантов и форматов.
Использование облегчается, только если выигрыш времени при задании функции превышает время, потраченное на обучение, запоминание и поиск руководств. Современные системы программирования дают такой выигрыш, но похоже, что в последние годы отношение выигрыша к затратам уменьшилось в результате добавления все более и более сложных функций. Я часто вспоминаю, как легко было использовать IBM 650, даже без ассемблера или вообще каких-либо программ.
Поскольку целью проектирования является простота использования, окончательную оценку проекта системы дает достигнутое отношение функциональности к сложности концепций. Ни функциональность, ни простота в отдельности не являются признаками хорошего проекта.
Это обстоятельство часто неправильно понимается. Operating System/360 превозносится своими создателями, как лучшая из когда-либо созданных, поскольку неоспоримо, что в ней больше функций. Функции, а не простота всегда служили критерием превосходства ее создателей. С другой стороны, создатели системы с разделением времени для PDP-10 превозносят ее превосходство ввиду простоты и немногочисленности положенных в основу идей. Однако по всем меркам ее функциональность ниже по классу, чем OS/360. Если в качестве критерия определена простота использования, становится очевидной несбалансированность этих систем, достигающих цели лишь наполовину.
Однако для некоторого заданного уровня функциональности лучшей оказывается та система, в которой можно работать с наибольшей простотой и непосредственностью. Простота — это еще не все. Язык TRAC, созданный Муером, и Algol 68 достигают простоты, если количественно измерять ее числом отдельных элементарных понятий. Непосредственность, однако, не характерна для них. Чтобы выразить свои намерения, часто требуется сочетать базовые средства сложным и неожиданным образом. Недостаточно изучить базовые элементы и правила их комбинирования, нужно изучить еще идиоматическое использование, целую область знаний о том, как на практике комбинировать элементы. Простота и непосредственность проистекают из концептуальной целостности. Во всех частях должны найти отражение единая философия и единообразные пропорции между желаемыми целями. В каждой части должны также использоваться одинаковый синтаксис и сходные семантические обозначения. Таким образом, простота использования требует единства проекта, концептуальной целостности.
Аристократия и демократия
Концептуальная целостность, в свою очередь, требует, чтобы проект исходил от одного разработчика, или небольшого числа их, действующих согласованно и в унисон.
С другой стороны, напряженность графика требует привлечения большого числа работников. Есть два метода разрешения этой дилеммы. Первый состоит в тщательном разделении труда между архитектурой и исполнением. Второй — новый способ организации бригад программистов-исполнителей, обсуждавшийся в предыдущей главе.
Отделение разработки архитектуры от реализации является эффективным способом достижения концептуальной целостности при работе над очень большими проектами. Я лично был свидетелем успешного его применения при создании IBM компьютера Stretch и серии продуктов System/360. Но он не сработал при разработке Operating System/360, поскольку недостаточно применялся.
Под архитектурой системы я понимаю полную и подробную спецификацию интерфейса пользователя. Для компьютера это руководство по программированию. Для компилятора это руководство по языку. Для управляющей программы это руководство по одному или нескольким языкам, используемым для вызова ее функций. Для системы в целом — это набор всех руководств, к которым должен обращаться пользователь при работе.
Архитектор системы, как и архитектор здания, является представителем пользователя. Его задача — использовать все свои профессиональные и технические знания исключительно в интересах пользователя, а не продавца, изготовителя и т.п.[2]
Архитектура и разработка должны быть тщательно разделены. Как сказал Блау (Blaauw), «архитектура говорит, что должно произойти, а разработка — как сделать, чтобы это произошло».[3]В качестве простого примера он приводит часы, архитектура которых состоит из циферблата, стрелок и заводной головки. Ребенок, освоивший это архитектуру, с одинаковой легкостью может узнать время и по ручным часам, и по часам на колокольне. Исполнение же и его реализация описывают, что происходит внутри: передача усилий и управление точностью каждым из многих механизмов.
К примеру, в System/360 одна и та же архитектура компьютера совершенно по-разному реализована примерно в девяти моделях. Обратным образом, одна и та же реализация потока данных, памяти и микропрограмм из Model 30 использовалась в разное время в четырех различных архитектурах: System/360, мультиплексном канале с подключением до 224 логически независимых подканалов, селекторном канале и компьютере 1401.[4]
Такие же различия можно проводить в отношении систем программирования. Существует стандарт для Fortran IV. Это архитектура, используемая во многих компиляторах. В рамках этой архитектуры возможны разные реализации: текст в оперативной памяти или компилятор, быстрая или оптимизирующая, синтаксическая или ad hoc. Аналогично, любой язык ассемблера или язык управления заданиями допускает многие реализации ассемблера или планировщика.
Теперь мы можем заняться весьма чувствительным вопросом борьбы аристократии и демократии. Не стали ли архитекторы новой аристократией, интеллектуальной элитой, призванной разъяснить бедным безгласным исполнителям, что они должны делать? Не захватила ли эта элита всю творческую деятельность, сделав исполнителей лишь зубчиками в механизме? Не окажется ли, что более совершенный продукт можно получить, используя идеи всей бригады и исповедуя философию демократии, а не ограничивая круг разработчиков несколькими лицами?
Проще всего ответить на последний вопрос. Я, разумеется, не стану утверждать, что хорошие архитектурные идеи могут возникать только у архитекторов. Часто свежая идея исходит от исполнителя или пользователя. Однако весь личный опыт убеждает меня, и я пытался это показать, что простоту пользования системой определяет ее концептуальная целостность. Достойные внимания функции и идеи, которые не объединяются с основными концепциями системы, лучше оставить в стороне. Если таких важных, но несовместимых идей появляется слишком много, выкидывают всю система и начинают разработку целостной системы сначала, основывая ее на иных основополагающих концепциях.
Что касается обвинений в аристократизме, то ответ и положительный, и отрицательный. Положительный, потому что действительно должно быть несколько архитекторов, чьи результаты живут дольше, чем отдельные реализации, и архитектор находится в фокусе сил, которые он в конечном итоге должен использовать в интересах пользователя. Если вы хотите, чтобы система обладала концептуальной целостностью, то руководство концепциями должен взять кто-то один. Это аристократизм, который не нуждается в извинениях.
Ответ отрицательный, поскольку разработка проекта требует не меньше творчества, чем задание внешних спецификаций. Это тоже творческая работа, но другого характера. Разработка проекта для заданной архитектуры требует и допускает столько же творческой деятельности, новых идей, изобретательности, как и проект внешних спецификаций. Практически, коэффициент стоимость/эффективность созданного продукта больше зависит от исполнителя, а простота его использования — от архитектора.
Есть масса примеров, подсказанных другими искусствами и ремеслами, которые подводят к мнению, что дисциплина идет на пользу. Действительно, афоризм художника гласит, что «форма освобождает». Самые ужасны строения — это те, бюджет которых был слишком велик для поставленных целей. Творческую активность Баха едва ли могла подавлять необходимость еженедельная необходимость изготавливать кантату определенного вида. Я уверен, что архитектура компьютера Stretch стала бы лучше, если бы на нее наложили более жесткие ограничения; так, ограничения, наложенные бюджетом на System/360 Model 30, по моему мнению, принесли лишь пользу архитектуре Model 75.
Аналогично, я считаю, что получение архитектуры извне усиливает, а не подавляет творческую активность группы исполнителей. Они сразу сосредоточиваются на той части задачи, которой никто не занимался, и в результате изобретательность бьет ключом. В не ограничиваемой группе большая часть обдумывания и обсуждения посвящена архитектурным решениям в ущерб реализации.[5]
Этот многократно наблюдавшийся мной эффект подтвердил Р. У. Конвей (R. W. Conway), чья группа разработала в Корнельском университете компилятор PL/C для языка PL/I. Он говорит: «В конечном итоге мы решили реализовать язык без изменений и усовершенствований, поскольку обсуждение языка отняло бы у нас все силы.»[6]
Чем заняться разработчику, пока он вынужден ждать?
Очень неприятно совершить ошибку стоимостью в миллион долларов, но зато она надолго запоминается. Я отчетливо помню тот день, когда мы приняли решение о том, как практически организовать составление внешних спецификаций для OS/360. Менеджер по архитектуре, менеджер по реализации управляющей программы и я прорабатывали план, график и разделение обязанностей.
У менеджера по архитектуре было 10 хороших специалистов. Он утверждал, что они в состоянии написать спецификации и сделать это должным образом. Это должно было занять 10 месяцев — на три больше, чем отводилось по графику.
У менеджера по реализации управляющей программы было 150 человек. Он заявлял, что они могут подготовить спецификации, при этом группа архитекторов выполняла бы координирующие функции. Обещалось, что это будет сделано хорошо и практично, с соблюдением сроков. Более того, если оставить спецификации группе архитекторов, его 150 человек в течение десяти месяцев будут бить баклуши.
На это менеджер по архитектуре возразил, что если я сделаю ответственной за написание спецификаций группу управляющей программы, то результата в срок не будет: он все равно задержится на три месяца, но по качеству будет много хуже. Так оно и оказалось в действительности. Он оказался прав в обоих пунктах. Кроме того, из-за отсутствия концептуальной целостности создание и внесение изменений в систему оказались значительно более дорогостоящими, и, по моим оценкам, отладка удлинилась на год.
Конечно, многие факторы повлияли на принятие этого ошибочного решения, но определяющими были желание уложиться в график и стремление занять работой этих 150 человек. Пение этих сирен таит смертельные опасности, которые я и хочу сейчас показать.
Когда предлагается, чтобы все внешние спецификации для компьютерной или программной системы были составлены небольшой командой архитекторов, исполнители выдвигают три возражения:
• Спецификации будут перегружены функциями и не будут учитывать практических затрат на реализацию.
• Архитекторы получат все радости творчества и заблокируют изобретательность исполнителей.
• Многочисленным исполнителям придется ожидать в праздности, пока спецификации пройдут через узкое горлышко команды архитекторов.
Первое возражение отражает реальную опасность и будет рассмотрено в следующей главе. Остальные два являются чистым заблуждением. Как мы видели выше, разработка также является в высшей степени творческой деятельностью. Возможность проявить творчество и изобретательность при разработке незначительно ограничивается необходимостью работать в рамках заданных внешних спецификаций, и такая дисциплина может даже усилить степень творчества. Это, несомненно, верно для проекта в целом.
Последнее возражение касается планирования временных рамок и этапов. Проще всего воздержаться от найма исполнителей до завершения работы над спецификациями. Когда воздвигается здание, так и поступают.
Однако при создании компьютерных систем темпы выше, и желательно уплотнить график работ. В какой мере разработка спецификаций и разработка могут перекрываться?
Как отмечает Блау, всю программу создания составляют три отдельные стадии: архитектура, разработка и реализация. Оказывается, что на практике их можно начинать параллельно и продолжать одновременно.
Например, при проектировании компьютеров проектировщик может приступать к работе, имея относительно общие допущения в отношении руководства пользователя, несколько более ясные идеи относительно технологии и вполне определенные задачи по стоимости и рабочим характеристикам. Он может начать проектирование потоков данных, управляющих последовательностей, общих идей компоновки и т.д. Он разрабатывает или адаптирует необходимый инструментарий, особенно систему ведения учета, в том числе систему автоматизации проектирования.
В то же время на уровне реализации нужно спроектировать, усовершенствовать и описать микросхемы, платы, кабели, каркасы, блоки питания и устройства памяти. Эта работа протекает параллельно с архитектурой и разработкой.
То же самое справедливо при создании программных систем. Задолго до завершения внешних спецификаций проектировщик может найти себе достаточно работы. Он может приступить к делу, основываясь на грубом приближении функциональности системы, которая в конечном итоге будет воплощена во внешних спецификациях. У него должны быть ясно определенные цели в отношении памяти и временных параметров. Он должен изучить конфигурацию системы, на которой будет выполняться его продукт. Затем он может начать определение границ модулей, структур таблиц, расчленения на проходы или стадии алгоритмов и всевозможных инструментальных средств. Некоторое время он должен также посвятить общению с архитектором.
В то же время достаточно работы и на уровне реализации. У программирования своя технология. Если машина новая, много труда требуют соглашения по подпрограммам, технология работы с супервизором, алгоритмы поиска и сортировки.[7]
Концептуальная целостность требует, чтобы система отражала единую философию, и технические условия, в том виде, в котором они будут видны пользователю, проистекали от малого числа авторов. Это не означает, что спроектированная таким образом система создается дольше, поскольку используется действительное
разделение труда на архитектуру, разработку и реализацию. Опыт показывает обратное: цельная система продвигается быстрее и требует меньше времени для отладки. В результате широко распространенное горизонтальное разделение труда значительно сокращается за счет вертикального разделения, что влечет резкое уменьшение обмена информацией и улучшение концептуальной целостности.
Глава 5 Эффект второй системы
Adde parvum parvo magnus acervus erit. (Складывай малое с малым, и получишь большую кучу.)
ОВИДИЙ
Если ответственность за спецификацию функций отделить от ответственности за быстрое создание недорогого продукта, то чем сдержать изобретательский энтузиазм архитектора?
Принципиальное решение — обеспечение всестороннего, тщательного и доброжелательно обмена информацией между архитектором и разработчиком. Однако имеются и более тонкие решения, которые заслуживают внимания.
Дисциплина взаимодействия для архитектора
Архитектор, строящий здание, действует в рамках сметы, используя методы оценки, которые в последующем подтверждаются или корректируются заявками подрядчиков. Часто случается, что все предложения выходят за рамки сметы. Тогда архитектор пересматривает свои оценки в сторону увеличения сметы, а проект — в сторону сокращения, и цикл повторяется. Иногда он предлагает подрядчикам способы удешевления реализации его проекта в сравнении с избранными ими способами.
Сходные процессы происходят с архитектором компьютерных или программных систем. Однако у него есть то преимущество, что предложения подрядчика можно получить на ранних стадиях проектирования, часто — в любой момент. Недостатком обычно является то, что работа идет с единственным подрядчиком, который может менять цену в зависимости от степени своей удовлетворенности проектом. На практике, процесс общения, начатый на ранних этапах и продолжающийся непрерывно, может дать архитектору верную оценку стоимости, а разработчику — уверенность в проекте, не снимая при этом четкого разграничения сфер ответственности.
У архитектора, когда он сталкивается с неприемлемо высокой стоимостью, есть два выхода: сократить проект или воздействовать на стоимость, предлагая более дешевые способы реализации. Второй способ неизбежно вызывает эмоции, ведь архитектор оспаривает то, как строитель справляется со своим делом. Чтобы успешно справиться с этим, архитектору необходимо:
• помнить, что ответственность за изобретательность и творчество, проявляемые при реализации, несет строитель, поэтому архитектор предлагает, а не требует;
• всегда быть готовым предложить некоторый способ реализации своих замыслов и быть готовым согласиться с любым другим способом, позволяющим решить задачу не хуже;
• выдвигая такие предложения, действовать без шума и огласки;
• не рассчитывать на признательность за сделанные предложения.
Обычно разработчик парирует предложением изменений в архитектуре. Часто он прав — реализация какой-нибудь малосущественной детали может оказаться неожиданно дорогостоящей.
Самодисциплина — эффект второй системы
Первый проект архитектора стремится к скромности и ясности. Архитектор понимает, что не знает, чем занимается, поэтому он занимается этим со старанием и самоограничением.
При работе над первым проектом ему постоянно приходят в голову то одни, то другие «украшения». Они откладываются в сторону для использования «в следующий раз». В конце концов, первая система закончена, и архитектор, с твердой уверенностью в себе и продемонстрированным освоением этого класса систем, готов к созданию нового проекта.
Эта вторая система таит наибольшие опасности для проектировщика. При работе над третьей и последующими системами закрепляется полученный ранее опыт в отношении общих характеристик таких систем, а различия между ними выявляют те части опыта, которые носят частный характер и не могут быть обобщены.
Общая тенденция заключается в перегруженности проекта второй системы идеями и украшательствами, благоразумно отложенными в сторону при работе над первым проектом. В результате получается, говоря словами Овидия, «большая куча». Рассмотрим, например, архитектуру IBM 709, воплощенную позднее в машине 7090. Это — модернизация, вторя система для очень успешной и хорошо скроенной системы 704. Набор команд был настолько богат и изобилен, что регулярно использовалась примерно лишь половина его.
Рассмотрим в качестве более сильного примера архитектуру, разработку и даже реализацию компьютера Stretch, которые дали выход сдерживающимся изобретательским стремлениям многих людей, для большинства которых это было вторая система. Вот что пишет в своем обзоре Стрейчи (Strachey):
У меня создалось впечатление, что некоторым образом Stretch являет собой окончание определенного направления разработок. Как и некоторые ранние компьютерные программы, эта система чрезвычайно изобретательна, чрезвычайно сложна и очень эффективна, но в то же время является сырой, расточительной и неизящной, оставляя ощущение, что эти вещи можно делать лучшим образом.[1]
Operating System/360 была второй системой для большинства своих проектировщиков. Группы проектировщиков пришли после работы над дисковой операционной системой 1410-7010, операционной системой Stretch, системой реального времени Project Mercury и IBSYS для 7090. Едва ли кто-то из них имел опыт работы над двумя предшествующими операционными системами. Поэтому OS/360 является ярким примером эффекта второй системы, аналогом Stretch в искусстве программирования, к которому в полной мере применимы и похвалы, и упреки приведенной критики Стрейчи.
Например, в OS/360 отводится 26 байт для резидентной процедуры преобразования даты, чтобы правильно обрабатывать 31 декабря в високосном году (когда это 366-й день). Это можно было оставить оператору.
Эффект второй системы имеет и другое проявление, кроме простого украшательства функциями. Это — склонность к усовершенствованию методов, само существование которых стало анахронизмом благодаря изменениям в базовых принципах системы. OS/360 содержит многочисленные примеры, подтверждающие это.
