Реферат: Фредерик П. Брукс

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


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


Frederick P. Brooks

THE MYTHICAL MAN-MONTH

(Essays on Software Engineering)

ADDISON-WESLEY PUBLISHING COMPANY READING 1975
Оглавление
Мифический человеко-месяц или как создаются программные системы 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 11. Планируйте на выброс 42

Глава 12. Острый инструмент 46

Глава 13. Целое и части 51

Глава 14. Назревание катастрофы 55

Глава 15. Обратная сторона 59

Глава 16. Серебряной пули нет - сущность и акциденция в программной инженнерии 66

Глава 17. Новый выстрел "Серебряной пули нет" 78

Глава 18. Заявления "Мифического человеко-месяца": правда или ложь? 87

Глава 19 "Мифический человеко-месяц" двадцать лет спустя 97

Примечания и ссылки 113


^ Посвящение издания 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), Джеймс Коггинс (JamesCoggins), Том Демарко (Tom DeMarco), Джим Маккарти (Jim McCarthy), ДэвидПарнас (David Parnas), Эрл Уилер (Earl Wheeler) и Эдвард Йордон (EdwardYordon). Фэй Уард (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, Чарльзом Портманом (CharlesPortman) из International Computers Limited, А. П. Ершовым изВычислительного центра Сибирского отделения Академии наук СССР, а также А.М. Пьетрасанта (A. M. Pietrasanta) из IBM.

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

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

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

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

Я глубоко признателен мисс Саре Элизабет Мур (Sara Elizabeth Moore),мистеру Дэвиду Вагнеру (David Wagner) и миссис Ребекке Беррис (RebeccaBurris) за помощь в подготовке данной рукописи, а также профессору ДжозефуСлоуну (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 - системное тестирование при наличии всех компонентов.

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

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

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

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

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

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

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

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

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

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

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

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



Рис. 2.5

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

Допусти