Мифический человеко-месяц или как создаются программные системы
Шрифт:
Мое профессиональное становление в вычислительной технике первоначально было связано с программированием, однако в период 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 находится программа. Она является завершенным продуктом, пригодным для запуска своим автором на системе, на которой была разработана. В гаражах обычно производится такой продукт, и это — тот объект, посредством которого отдельный программист оценивает свою производительность.
Есть два способа, которыми программу можно превратить в более полезный, но и более дорогой объект. Эти два способа представлены по краям рисунка.