        ”редерик Џ.Ѓрукс. Њифический человеко-месЯц или как создатсЯ программные системы

---------------------------------------------------------------
     <b>THE MYTHICAL MAN-MONTH
     (Essays on Software Engineering)</b>
     ADDISON-WESLEY PUBLISHING COMPANY READING 1975

     Copyright  (c)   1975  by  Acldison-Wesley   Publishing  Company,  Inc.
Philippines;  Copyright  1975  by  Addison-Wesley Publishing  Company,  Inc.
Copvrisht (c) 1972 by Frederick P. Brooks, Jr.
     OCR, formating: Jek <jek_bask@ngs.ru>, Alex Buloichik
---------------------------------------------------------------


     ЏосвЯщение изданиЯ 1975 года
     <i>ЏосвЯщаетсЯ  двоим людЯм,  благодарЯ  которым  мои годы  в  IBM  были
особенно насыщенными: ’омасу  „ж.  “отсону Њладшему, чье глубокое внимание к
людЯм  по-прежнему  ощущаетсЯ в  его фирме,  и Ѓобу  Ћ.  ќвансу, чье  смелое
руководство превратило работу в приключение.</i>
     <b>ЏосвЯщение изданиЯ 1995 года</b>
     <i>ЏосвЯщаетсЯ Ќэнси, Ѓожьему дару длЯ менЯ.</i>
     Џредисловие к изданию 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.  <i>—апел  •илл,
‘евернаЯ Љаролина
     Њарт 1995</i>
     <i>Џредисловие к первому изданию</i>
     ‚о   многих  отношениЯх   управление  большим  проектом   разработки
программного обеспечениЯ  аналогично любому  другому  крупному начинанию - в
большей  мере, чем обычно считают программисты. Ћднако во  многих отношениЯх
имеет отличиЯ -  в  большей  мере,  чем обычно предполагают профессиональные
менеджеры. €дет процесс  накоплениЯ профессиональных знаний в  этой области.
‘остоЯлось   несколько  конференций,  заседаний   на   конференциЯх   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.
     <i>—эпел •илл, ‘евернаЯ Љаролина
     ЋктЯбрь 1974</i>


        ѓлава 1. ‘молЯнаЯ Яма
     <i>Een Schip op bet strand is een baken in zee.
     [Љорабль на мели - морЯку маЯк.]
     ѓЋ‹‹ЂЌ„‘ЉЂџ ЏЋ‘‹Ћ‚€–Ђ</i>
     ‘амаЯ ЯркаЯ сцена  доисторических времен - борьба огромных животных со
смертью  в смолЯных  Ямах. ‚оображение представлЯет динозавров,  мамонтов  и
саблезубых тигров, пытающихсЯ высвободитьсЯ из смолы. —ем отчаЯнней  борьба,
тем  сильнее затЯгивает  смола,  и как бы ни  был  силен или  ловок зверь, в
конечном итоге ему уготована гибель.
     ’акой  смолЯной  Ямой  в  последнее десЯтилетие  было  программирование
больших  систем: в ней сгинул не  один  большой и сильный  зверь. Џо большей
части это происходило  в  области систем, где мало кому удалось  реализовать
спецификации, уложитьсЯ в  график  и  бюджет.  Ѓольшие  и малые, массивные и
жилистые - одна  за  другой эти команды  увЯзли в  смоле. Љазалось,  ничто в
отдельности  не  вызывает  трудностей - одну лапу всегда можно вытащить.  Ќо
накопление действующих одновременно и взаимовлиЯющих  факторов все  более  и
более   замедлЯет  движение.  ‚ызывает   удивление  неприЯтность   возникшей
проблемы, и распознать ее сущность  нелегко. Ќо  нужно это сделать,  если мы
собираемсЯ решить ее.
     Џоэтому   начнем   с   определениЯ    того,   что    такое    системное
программирование, и какие радости и печали оно таит.
     ‘истемный программный продукт
     ‚ремЯ  от   времени   можно   прочесть  в  газете  о   том,   как  в
переоборудованном гараже пара программистов сделала замечательную программу,
оставившую позади  разработки  больших команд. €  каждый  программист охотно
верит в  эти сказки, поскольку знает, что  может создать <i>любую</i> программу  со
скоростью, значительно превышающей  те 1000  операторов в год,  которые,  по
сообщениЯм, пишут программисты в промышленных бригадах.
     Џочему  же до  сих пор  все профессиональные  бригады программистов  не
заменены одержимыми  дуэтами  из  гаражей?  Ќужно  посмотреть  на  то,  <i>что</i>,
собственно, производитсЯ.
     ‚ левом  верхнем  углу рисунка 1.1  находитсЯ  <i>программа</i>. Ћна  ЯвлЯетсЯ
завершенным продуктом, пригодным длЯ  запуска своим  автором на  системе, на
которой была разработана. ‚ гаражах обычно производитсЯ <i>такой</i> продукт, и это
- тот  объект, посредством  которого  отдельный  программист  оценивает свою
производительность.
     …сть два способа, которыми программу можно превратить в более полезный,
но и более дорогой объект. ќти два способа представлены по краЯм рисунка.
     Џри   перемещении   вниз   через   горизонтальную   границу   программа
превращаетсЯ  в  <i>программный продукт</i>.  ќто программа, которую любой  человек
может  запускать,   тестировать,   исправлЯть   и   развивать.   Ћна   может
использоватьсЯ в различных операционных средах и со многими наборами данных.
—тобы стать общеупотребительным программным продуктом, программа должна быть
написана в  обобщенном стиле.  ‚ частности,  диапазон и  вид входных  данных
должны  быть  настолько  обобщенными,   насколько  это  допускаетсЯ  базовым
алгоритмом.  ‡атем  программу  нужно  тщательно  протестировать,  чтобы быть
уверенным   в  ее   надежности.  „лЯ  этого  нужно  подготовить  достаточное
количество контрольных примеров длЯ проверки  диапазона допустимых  значений
входных  данных   и  определениЯ  его  границ,   обработать  эти  примеры  и
зафиксировать  результаты. Ќаконец, развитие программы в программный продукт
требует  созданиЯ подробной документации,  с помощью  которой каждый мог  бы
использовать  ее,  делать исправлениЯ  и расширЯть. џ пользуюсь практическим
правилом, согласно  которому программный  продукт  стоит,  по меньшей  мере,
втрое дороже, чем просто отлаженнаЯ программа с такой же функциональностью.

     <img src=mithsoftware_pic1_1.png>

     <b>ђис. 1.1</b> ќволюциЯ системного программного продукта
     Џри  пересечении вертикальной  границы программа становитсЯ компонентом
<i>программного комплекса</i>. Џоследний представлЯет собой набор взаимодействующих
программ, согласованных по функциЯм и форматам,  и вкупе составлЯющих полное
средство  длЯ   решениЯ  больших  задач.  —тобы  стать  частью  программного
комплекса,  синтаксис  и   семантика  ввода   и  вывода   программы   должны
удовлетворЯть точно  определенным интерфейсам.  Џрограмма должна  быть также
спроектирована  таким образом, чтобы использовать заранее оговоренный бюджет
ресурсов  -  объем  памЯти,  устройства  ввода/вывода,  процессорное  времЯ.
Ќаконец,  программу  нужно   протестировать  вместе  с   прочими  системными
компонентами во всех сочетаниЯх, которые могут встретитьсЯ. ќто тестирование
может оказатьсЯ большим  по объему, поскольку количество тестируемых случаев
растет экспоненциально.  Ћно также  занимает много времени, так  как скрытые
ошибки выЯвлЯютсЯ при неожиданных  взаимодействиЯх отлаживаемых компонентов.
Љомпонент  программного комплекса стоит,  по крайней мере, втрое дороже, чем
автономнаЯ программа  с теми же функциЯми. ‘тоимость может увеличитьсЯ, если
в системе много компонентов.
     ‚  правом  нижнем  углу рисунка  1.1  находитсЯ  <i>системный  программный
продукт</i>.  Ћт  обычной  программы он  отличаетсЯ во всех  перечисленных  выше
отношениЯх.  €   стоит,  соответственно,   в   десЯть  раз  дороже.  Ќо  это
действительно полезный  объект, который ЯвлЯетсЯ целью большинства системных
программных проектов.
     ђадости профессии
     Џочему  заниматьсЯ  программированием  интересно?   Љакими  радостЯми
вознаграждаютсЯ те, кто им занимаетсЯ?
     ‚о-первых, это просто радость, получаемаЯ при создании чего-либо своими
руками. Љак  ребенок  радуетсЯ, делаЯ  куличики  из  песка,  так и  взрослый
получает  удовольствие, создаваЯ  какие-либо  вещи, особенно если  сам  их и
придумал. џ думаю, что этот  восторг - отражение восторга ѓоспода, творЯщего
мир, восторга, проЯвлЯющегосЯ в индивидуальности и новизне  каждого листочка
и каждой снежинки.
     ‚о-вторых, это удовольствие создавать  вещи, которые могут быть полезны
другим людЯм. ѓлубоко в  душе мы испытываем потребность в том,  чтобы другие
использовали  результаты  нашего  труда  и  считали  их  полезными.  ‚  этом
отношении программнаЯ  система  по  своей сути - то же,  что и изготовленнаЯ
ребенком подставка длЯ карандашей "папе в подарок".
     ‚-третьих,  это  очарование  созданиЯ  сложных  головоломных  объектов,
состоЯщих из взаимодействующих движущихсЯ частей и наблюдениЯ за их работой,
круг  за кругом демонстрирующей результаты изначально заложенных  принципов.
Љомпьютер с работающей  на нем программой  обладает  доведенным  до  высшего
предела очарованием игорного или музыкального автомата.
     ‚-четвертых,  это радость, получаемаЯ от  неизменного узнаваниЯ нового,
проистекающего из неповторимой природы  задачи. ‚  том  или  ином  отношении
задача всегда  ставитсЯ  по-новому,  и тот,  кто  ее  решает, получает новые
знаниЯ - либо практические, либо теоретические, либо те и другие вместе.
     Ќаконец, наслаждение доставлЯет  работа со столь податливым материалом.
Џрограммист, подобно  поэту, работает почти непосредственно с чистой мыслью.
Ћн строит свои замки в воздухе и из воздуха, творЯ силой воображениЯ. ’рудно
найти другой материал,  используемый  в творчестве, который столь  же гибок,
прост длЯ  шлифовки  или переработки и доступен  длЯ воплощениЯ  грандиозных
замыслов. (Љак мы позднее увидим, такаЯ податливость таит свои проблемы.)
     Ћднако  программнаЯ конструкциЯ,  в  отличие  от  поэтических творений,
реальна,  в том смысле,  что  она движетсЯ  и  работает,  производЯ  видимые
результаты, которые  отделимы от самой конструкции. Ћна печатает результаты,
рисует картинки, производит  звуки, приводит в движение рычаги. ‚ наше времЯ
осуществилось  волшебство  мифа  и  легенды.  ‘  клавиатуры вводитсЯ  верное
заклинание, и экран монитора  оживает, показываЯ то, чего  никогда не было и
не могло быть.
     ’аким  образом,  программирование  доставлЯет  удовольствие,  поскольку
отвечает  глубокой  внутренней  потребности  в  творчестве  и  удовлетворЯет
чувственные потребности, которые есть у всех нас.
     Џечали профессии
     Ќе  все, однако,  в радость,  и если предвидеть присущие этому ремеслу
огорчениЯ, то они легче переносЯтсЯ.
     ‚о-первых, необходима безошибочнаЯ точность  действий. ‚ этом отношении
компьютер также  напоминает  волшебство. Ћдин неверный  знак,  одна  пауза в
заклинании, и чудо не состоЯлось. —еловеку несвойственно совершенство, и оно
ЯвлЯетсЯ необходимым лишь  в  немногих сферах его деЯтельности. Њне кажетсЯ,
что  при  освоении  программированиЯ труднее  всего привыкнуть к  требованию
совершенства.1
     Љроме  того, постановка задач,  обеспечение  ресурсами и предоставление
информации  осуществлЯетсЯ  другими  людьми.  ђедко  удаетсЯ  контролировать
условиЯ работы и  даже ее цели. Ќа Языке администрированиЯ это означает, что
полномочиЯ  ниже ответственности. ‚прочем, похоже,  что в любой  работе, где
должен  быть  получен  результат, формальнаЯ  власть никогда не соизмерима с
ответственностью. Ќа практике  фактическаЯ (в противоположность  формальной)
власть приобретаетсЯ в результате успешного выполнениЯ задач.
     ‡ависимость от других имеет особенно неприЯтную системному программисту
сторону. Ћн находитсЯ в зависимости от  программ, написанных другими людьми,
и эти программы зачастую  плохо спроектированы, слабо написаны,  получены  в
неполном  виде  (без  исходного  текста  и  контрольных  примеров)  и  плохо
документированы.  Џоэтому  программисту приходитсЯ тратить  многие  часы  на
изучение  и  исправление  вещей, которые,  в  идеале, должны  быть  полными,
доступными и годными к использованию.
     ‘ледующий  "минус" свЯзан с тем,  разработка  грандиозных  идей  -  это
удовольствие, а поиск паршивых маленьких "жучков" - это всего лишь работа. ‚
каждом творческом деле  бывают ужасные периоды однообразного и  кропотливого
труда, и программирование не ЯвлЯетсЯ исключением.
     „алее  оказываетсЯ,  что  при  отладке  программы  сходимость  ЯвлЯетсЯ
линейной, если не хуже,  хотЯ  можно было  предполагать  некое  квадратичное
приближение к окончанию. ‚ итоге отладка продолжаетсЯ долго, причем на поиск
последних более  сложных  ошибок  уходит больше  времени, чем  на  отыскание
первых.
     ЏоследнЯЯ горесть, а часто  и  последнЯЯ  каплЯ, - то,  что продукт, на
который было положено столько  труда,  оказываетсЯ  устаревшим в  момент его
завершениЯ (или даже раньше). Љоллеги и конкуренты уже  с пылом работают над
новыми  и лучшими  идеЯми.  € уничтожение  плода  вашей мысли уже  не только
задумано, но и запланировано.
     Ќа  самом деле  положение обычно лучше, чем кажетсЯ. ‚ то времЯ как ваш
продукт уже завершен, этот новый и лучший  продукт, как правило, отсутствует
на рынке, о нем  лишь много разговоров,  и длЯ  его  разработки  потребуютсЯ
месЯцы.  ЌастоЯщий   тигр  не  пара   бумажному,   если  требуетсЯ  реальное
использование. ђеальное существование имеет преимущества.
     Љонечно,  технологическаЯ  основа  разработки <i>всегда</i>  развиваетсЯ.  Љак
только  разработка  проекта  закончена, он  становитсЯ  устаревшим в  смысле
заложенных  в   нем  концепций.  Ќо  длЯ   осуществлениЯ  реального  проекта
необходимо разбиение  на стадии  и уровни.  ‘удить о том, ЯвлЯетсЯ  ли некаЯ
реализациЯ устаревшей,  можно лишь  сравниваЯ  ее  с  другими  существующими
реализациЯми, а  не с нереализованными идеЯми.  ’рудность и цель  состоЯт  в
том, чтобы найти реальные решениЯ длЯ реальных задач в установленные  сроки,
используЯ имеющиесЯ ресурсы.
     ’аково  программирование  -  и  смолЯнаЯ Яма,  в  которой увЯзли многие
проекты, и  творчество со своими радостЯми  и печалЯми.  „лЯ  многих радости
значат гораздо больше, чем печали. „лЯ них и  написана эта книга  в  попытке
проложить какие-то мостки через это болото.

        ѓлава 2. ќтот мифический "человеко-месЯц"
     <i>—тобы приготовить вкусную пищу,
требуетсЯ времЯ. …сли вам пришлось ждать, то лишь потому, что мы хотим лучше
обслужить вас и доставить вам удовольствие.
     Њ…Ќћ ђ…‘’ЋђЂЌЂ "ЂЌ’“ЂЌ" ‚Ќњћ-Ћђ‹…ЂЌ…</i>
     Џрограммные  проекты  чаще проваливаютсЯ из-за  нехватки  календарного
времени,  чем  по всем остальным причинам  вместе взЯтым. Џочему эта причина
неудач столь распространена?
     ‚о-первых, слабо развиты наши методы оценок. ‚  сущности,  они отражают
молчаливое и совершенно неверное предположение, что все будет идти хорошо.
     ‚о-вторых,  наши методы оценки  ошибочно  путают достигнутый прогресс с
затраченными усилиЯми,  неЯвно  допускаЯ,  что скорость  выполнениЯ  проекта
пропорциональна количеству занЯтых в нем сотрудников.
     ‚-третьих, поскольку  менеджеры программных проектов не уверены в своих
оценках, им часто недостает вежливого  упрЯмства, как у шеф-повара ресторана
"Ђнтуан".
     ‚-четвертых,  выполнение  графика  работ слабо контролируетсЯ.  ’иповые
опробованные  в других инженерных дисциплинах методы  считаютсЯ радикальными
нововведениЯми при разработке программного обеспечениЯ.
     ‚-пЯтых,   при  обнаружении  отставаниЯ   от  графика   естественной  и
общепринЯтой  реакцией  ЯвлЯетсЯ  увеличение  числа  разработчиков. ќто  все
равно, что тушить пламЯ бензином.  ‚ результате дела  идут значительно хуже.
—ем сильнее пламЯ, тем больше нужно бензина, и в итоге  этот путь приводит к
катастрофе.
     Љонтроль  выполнениЯ  графика  будет  предметом  отдельного  разговора.
ђассмотрим более подробно остальные аспекты проблемы.
     Ћптимизм
     ‚се программисты - оптимисты. ‚озможно, эта современнаЯ разновидность
колдовства особенно привлекательна длЯ тех, кто верит в хэппи-энды и  добрых
фей.  ‚озможно,  сотни  неудач  отталкивают  всех,  кроме  тех,  кто  привык
сосредоточиватьсЯ на конечной цели. Ђ может быть, дело всего лишь в том, что
компьютеры и программисты молоды,  а молодости свойствен оптимизм. Љак бы то
ни  было, в результате одно: "Ќа этот раз она точно пойдет!" €ли : "џ только
что выЯвил последнюю ошибку!"
     €так, в основе планированиЯ разработки программ лежит ложное допущение,
что <i>все будет  хорошо</i>,  т.е.  <i>каждаЯ задача займет столько времени,  сколько
"должна" занЯть</i>.
     ѓлубокий оптимизм программистов  заслуживает более серьезного изучениЯ.
„ороти  ‘эйерс  (Dorothy Cayers) в своей превосходной  книге  "ђазум творца"
("The  Mind  of the  Maker") выделЯет в творческой деЯтельности  три стадии:
замысел,  реализацию,  взаимодействие.  ‘оответственно, книга, компьютер или
программа сначала  возникают как  идеальное  построение, существующее не  во
времени и  пространстве,  а лишь  в мозгу своего создателЯ. ђеализациЯ же во
времени  и пространстве происходит  с помощью пера, чернил,  бумаги, либо  -
проводов,  кремниЯ и  феррита.  ’ворение  будет  завершено,  когда  кто-либо
прочтет  книгу, воспользуетсЯ компьютером или запустит программу, тем  самым
вступив во взаимодействие с разумом их создателЯ.
     ќто описание  используемое  ‘эйерс длЯ  освещениЯ  не только творческой
деЯтельности человека, но  и  христианского  догмата ’роицы,  поможет нам  в
нашей текущей задаче.  „лЯ  человека,  который что-то создает,  неполнота  и
противоречивость  идей  выЯвлЯютсЯ только  при  их  реализации.  Џоэтому длЯ
теоретика  изложение  на  бумаге, экспериментирование, изготовление ЯвлЯетсЯ
неотъемлемыми частЯми творческого процесса.
     ‚о  многих  видах творческой деЯтельность материал  с трудом  поддаетсЯ
обработке.  „ерево  колетсЯ,  краски пачкаютсЯ, электрические цепи "звенЯт".
ќти физические ограничениЯ сужают круг идей, которые могут быть  выражены, а
также создают неожиданные трудности при реализации.
     ђеализациЯ, таким образом, требует сил  и времени как из-за физического
материала, так  и ввиду неадекватности основополагающих  идей. Ѓольшую часть
затруднений  при реализации  мы склонны объЯснЯть  недостатками  физического
материала,  поскольку он  "чужд"  нам  -  в отличие  от  идей,  которыми  мы
гордимсЯ.
     Џри  создании  же  программ  мы  имеем  дело  с  чрезмерно   податливым
материалом.  Џрограммист  осуществлЯет  свои  построениЯ  на основе  чистого
мышлениЯ - понЯтий и очень гибких их представлений. Џоскольку материал столь
податлив,  мы не ожидаем  трудностей при  реализации, отсюда и  наш глубокий
оптимизм.  €з-за  ошибочности  наших  идей  возникают  ошибки в  программах.
‘ледовательно, наш оптимизм не имеет оправданиЯ.
     „лЯ  отдельной  задачи  допущение,  что все  буде хорошо,  оказывает на
график работ  вероЯтностный эффект. ‚се  может действительно идти по  плану,
поскольку есть некоторое распределение вероЯтности длЯ возможной задержки  и
существует конечнаЯ вероЯтность того,  что задержки не будет. Ћднако большой
программный  проект  состоит из множества задач, часть из которых может быть
начата только после окончаниЯ других. ‚ероЯтность того, что все задачи будут
завершены в срок, бесконечно мала. —еловеко-месЯц ‚тораЯ ошибка  рассуждений
заключена  в   самой  единице  измерениЯ,  используемой   при  оценивании  и
планировании:   человеко-месЯц.  ‘тоимость   действительно   измерЯетсЯ  как
произведениЯ  числа   занЯтых  на  количество  затраченных  месЯцев.  Ќо  не
достигнутый результат.  Џоэтому  <i>использование человеко-месЯца  как  единицы
измерениЯ объема работы ЯвлЯетсЯ опасным заблуждением.</i>

     <img src=mithsoftware_pic2_1.png>

     <b>ђис. 2.1</b>  ‡ависимость времени от числа занЯтых -  полностью  разделимаЯ
задача
     —исло  занЯтых и число месЯцев  ЯвлЯютсЯ  взаимозаменЯемыми  величинами
лишь тогда, когда задачу  можно распределить среди  рЯда работников, которые
<i>не имеют между собой взаимосвЯзи</i>  (рис. 2.1).  ќто верно, когда жнут пшеницу
или собирают хлопок, но в системном программировании это далеко не так.

     <img src=mithsoftware_pic2_2.png>

     <b>ђис. 2.2</b> ‡ависимость времени от числа занЯтых - неразделимаЯ задача
     …сли задачу нельзЯ  разбить на  части, поскольку существуют ограничениЯ
на последовательность  выполнениЯ этапов, то увеличение затрат  не оказывает
влиЯниЯ на график (рис.  2.2). —тобы родить ребенка требуетсЯ девЯть месЯцев
независимо от  того,  сколько  женщин  привлечено  к решению  данной задачи.
Њногие задачи программированиЯ относЯтсЯ  к этому типу, поскольку отладка по
своей сути носит последовательный характер.

     <img src=mithsoftware_pic2_3.png>

     <b>ђис.  2.3</b> ‡ависимость  времени от  числа  занЯтых  - разделимаЯ задача,
требующаЯ обмена данными
     „лЯ  задач, которые  могут  быть разбиты на  части,  но требуют  обмена
данными между подзадачами, затраты на обмен данными должны  быть добавлены к
общему объему  необходимых  работ. Џоэтому  достижимый  наилучший  результат
оказываетсЯ  несколько  хуже,  чем  простое  соответствие  числа  занЯтых  и
количества месЯцев (рис. 2.3).
     „ополнительнаЯ  нагрузка  состоит  из двух частей - обучениЯ  и  обмена
данными.  Љаждого работника нужно обучить  технологии, целЯм проекта,  общей
стратегии  и  плану  работы. ќто обучение нельзЯ  разбить  на части, поэтому
даннаЯ часть затрат изменЯетсЯ линейно в зависимости от числа занЯтых.

     <img src=mithsoftware_pic2_4.png>

     <b>ђис.  2.4</b>  ‡ависимость времени от  числа  занЯтых -  задача со сложными
взаимосвЯзЯми
     ‘ обменом данными дело обстоит хуже. …сли все части заданиЯ должны быть
отдельно скоординированы  между  собой,  то затраты возрастают как <i>n(n-2)/2</i>.
„лЯ трех работников требуетсЯ втрое больше попарного общениЯ, чем длЯ  двух,
длЯ  четырех  -  вшестеро.  …сли  помимо  этого  возникает  необходимость  в
совещаниЯх трех, четырех и т.д. работников длЯ совместного решениЯ вопросов,
положение становитсЯ еще хуже. „ополнительные затраты на обмен данными могут
полностью  обесценить  результат  дроблениЯ исходной  задачи  и  привести  к
положению, описываемому рисунком 2.4.
     Џоскольку  создание программного  продукта  ЯвлЯетсЯ по  сути системным
проектом - практикой сложных взаимосвЯзей, затраты на обмен данными велики и
быстро начинают преобладать над сокращением сроков, достигаемым в результате
разбиениЯ  задачи  на  более  мелкие  подзадачи.  ‚  этом случае привлечение
дополнительных работников не сокращает, а удлинЯет график работ.
     ‘истемное тестирование
     €з всех элементов графика  работ  наибольшему  воздействию со стороны
ограничений  на последовательность  выполнениЯ  действий  подвержены отладка
компонентов и системное тестирование. Љроме того, затраты времени зависЯт от
количества  выЯвленных   ошибок  и   от   того,  насколько   они  "скрытые".
’еоретически, ошибок  быть  не  должно.  €з-за  своего  оптимизма мы  обычно
склонны  недооценивать   действительное   количество   ошибок.   Џоэтому   в
программировании  придерживатьсЯ графиков  работ  обычно  труднее всего  при
отладке.
     ‚ течение рЯда лет при планировании разработки программного обеспечениЯ
Я пользуюсь следующим эмпирическим правилом:
     1/3 - планирование,
     1/6 - написание программ,
     1/4   -   тестирование   компонентов   и   предварительное    системное
тестирование,
     1/4 - системное тестирование при наличии всех компонентов.
     ќто   правило  имеет   несколько   важных   различий   с   общепринЯтым
планированием:
     1. Ќа  планирование отводитсЯ  больше времени, чем  обычно. € все равно
этого   времени  едва  достаточно  длЯ   разработки  подробных   и  надежных
технических условий  и  недостаточно длЯ  проведениЯ исследовательских работ
или поиска новейших технологий.
     2. <i>Џоловина</i> графика работ,  отведеннаЯ  на отладку  законченного  кода,
значительно выше нормы.
     3. ’а часть, которую легко оценить, т.е. написание кода, занимает всего
одну шестую общего времени.
     €зучаЯ проекты, график которых  был составлен традиционным  образом,  Я
обнаружил,  что  немногие  из них отводили по  графику  половину  времени на
отладку,  но  на  практике  в  большинстве случаев  тратили на  нее половину
фактического времени. Њногие проекты укладывались  в график на всех  этапах,
исключаЯ системное тестирование.2
     Ћсобенно  катастрофические  последствиЯ  может иметь недостаток времени
длЯ  системного тестированиЯ. Џоскольку задержка происходит в конечной части
графика, никто не подозревает о том, что  график находитсЯ под угрозой срыва
вплоть  до  днЯ  сдачи  продукта. Џлохие  вести,  полученные  поздно  и  без
предупреждениЯ, обескураживают клиентов и менеджеров.
     Ѓолее того, задержка на этом этапе имеет  особенно тЯжелые материальные
и   психологические   последствиЯ.   Џроект   осуществлЯетсЯ   при    полной
укомплектованности  работниками  и  максимальных  финансовых  издержках. —то
важнее, программное обеспечение  должно обеспечить поддержку другой  деловой
активности (поставки компьютеров, запуска новых производственных мощностей и
т.п.), и свЯзанные с  задержкой вторичные издержки очень высоки. Ќа практике
эти вторичные издержки могут быть выше, чем все прочие. Џоэтому очень  важно
в изначальном  графике  работ  отвести  достаточно  времени  длЯ  системного
тестированиЯ.
     ђобость в оценках
     „лЯ программиста, как и длЯ повара, давление со стороны  хозЯина  может
определЯть  запланированный срок  завершениЯ задачи, но  не может определЯть
времЯ  ее фактического  завершениЯ. Ћмлет, обещанный через две минуты, может
успешно жаритьсЯ, но если  через  две минуты он не готов,  то у клиента есть
две возможности: ждать еще или съесть его сырым. ’от же выбор встает и перед
заказчиком программного обеспечениЯ.
     “ повара  есть еще одна  возможность: добавить жару. ‚ результате омлет
часто оказываетсЯ безнадежно испорченным:  горелым с одного краЯ и сырым - с
другого.
     џ не думаю, что у менеджеров программных продуктов меньше храбрости или
твердости, чем у поваров  или  других менеджеров  в инженерных областЯх.  Ќо
липовые графики,  нацеленные  на желательную хозЯину дату, встречаютсЯ здесь
значительно чаще,  чем в  любых  других  инженерных областЯх. Ћчень  тЯжело,
рискуЯ потерЯть  рабочее место, с энергией  и любезностью  отстаивать  срок,
который  определен  без применениЯ  каких-либо  количественных  методов  при
недостатке данных и подкреплен, в основном, интуицией менеджера.
     Ћчевидно,  необходимо сделать две  вещи. Њы должны  получить  и сделать
общедоступными численные данные, характеризующие производительность, частоту
программных ошибок, методы оценки  и т.д. ‚сЯ отрасль может  только выиграть
от опубликованиЯ таких данных.
     Џока  методы оцениваниЯ  не  получат более прочной  основы,  менеджерам
остаетсЯ только мужатьсЯ и защищать свои прогнозы, утверждаЯ, что полагатьсЯ
на их слабую интуицию все же лучше, чем основыватьсЯ на одних желаниЯх.
     „ействиЯ при срыве графика
     —то  делают,  когда важный программный  проект начинает  отставать  от
графика? …стественно, добавлЯют людей. Љак показывают рисунки  2.1-2.4,  это
не всегда помогает.
     ђассмотрим пример.3 Џредположим, что трудоемкость задачи  оцениваетсЯ в
12 человеко-месЯцев, и три  человека должны выполнить ее за 4 месЯца, причем
в конце каждого  месЯца имеютсЯ  четыре контрольные  точки A,  B, C  и  D, в
которых можно произвести измерениЯ (рис. 2.5).

     <img src=mithsoftware_pic2_5.png>

     ђис. 2.5
     Џредположим  теперь, что перваЯ контрольнаЯ точка была достигнута лишь
по истечении двух месЯцев. Љакие альтернативы имеютсЯ у менеджера?
     1. „опустим, что необходимо соблюсти срок выполнениЯ задачи, и ошибочно
оценена  была только перваЯ часть задачи,  т.е.  рисунок 2.6 верно  отражает
положение.  ‡начит, остаетсЯ  9 человеко-месЯцев  трудозатрат  и два месЯца,
поэтому  понадобитсЯ 4Ѕ человека,  и к троим имеющимсЯ  нужно  добавить  еще
двоих.

     <img src=mithsoftware_pic2_6.png>

     ђис. 2.6
     2.   „опустим,  что  необходимо  соблюсти  срок  выполнениЯ  задачи,  и
одинаково занижена была  всЯ  оценка , т.е.  положение соответствует рисунку
2.7. ‡начит, остаетсЯ 18 человеко-месЯцев трудозатрат и два  месЯца, поэтому
понадобитсЯ 9 человек. Љ троим имеющимсЯ нужно добавить еще шестерых.

     <img src=mithsoftware_pic2_7.png>

     ђис. 2.7
     3. €зменить график.  Њне  нравитсЯ замечание, сделанное Џ. ”аггом  (P.
Fagg), опытным инженером по  вычислительной  технике: "Њаленьких задержек не
бывает". ќто означает, что  в новом графике должно  быть достаточно времени,
чтобы работа была исполнена тщательно и  полностью,  и не пришлось бы  вновь
переделывать график.
     4. ‘ократить задачу. Ќа практике этим всегда и кончаетсЯ, когда команда
обнаруживает,  что не  укладываетсЯ в  график.  Љогда очень высоки вторичные
издержки,  это единственное,  что можно сделать.  Њенеджеру  предоставлЯетсЯ
возможность официально и аккуратно сократить задачу,  изменить  график, либо
наблюдать, как  задача молча урезаетсЯ  при  поспешном  изменении проекта  и
неполном тестировании.
     ‚ первых двух случаЯх настаивать на том, чтобы задача в неизменном виде
была выполнена за четыре месЯца, чревато катастрофой. ђассмотрим, к примеру,
восстановительный   эффект  первой   альтернативы  (рис.  2.8).  „вое  новых
работников,  какими бы знающими они ни были, и  как бы быстро не удалось  их
найти, должны изучить задачу с помощью одного из опытных разработчиков. …сли
длЯ этого потребуетсЯ месЯц, то <i>3 человеко-месЯца будут потрачены на работу,
котораЯ  не учитываетсЯ  в исходной оценке</i>.  Љроме  того,  задача,  разбитаЯ
первоначально на три  потока, должна быть теперь перекроена на  пЯть частей.
Џоэтому часть  уже сделанной работы будет потерЯна, а системное тестирование
нужно будет продлить. ‚ результате в конце третьего  месЯца останетсЯ работы
существенно больше, чем  на  7  человеко-месЯцев,  а  в распорЯжении будет 5
подготовленных человек  и один  месЯц.  ‘огласно рисунку 2.8  продукт  будет
запаздывать так же,  как если бы ни  одного человека  не было добавлено (см.
рис. 2.6).
     …сли рассчитывать управитьсЯ за четыре  месЯца  с учетом только времени
обучениЯ,  но  не  перераспределениЯ  задач  и   дополнительного  системного
тестированиЯ, то  в конце  второго  месЯца  потребуетсЯ добавить  4, а не  2
человека.  —тобы  компенсировать   воздействие  перераспределениЯ   задач  и
системного тестированиЯ, потребуютсЯ еще новые люди. ’еперь, однако, команда
состоит  не  из  3,  а, по крайней  мере, 7  человек, и  такие вопросы,  как
организациЯ  команды и распределение  задач  приобретают  новый качественный
уровень.
     Ћбратите  внимание, что  к концу третьего  месЯца  дело выглЯдит весьма
мрачно.  ЌесмотрЯ  на   все   административные   усилиЯ  контрольнаЯ  точка,
намеченнаЯ  на  1 марта, не достигнута.  ‚озникает сильный соблазн повторить
цикл, добавив еще людей. ќто безумное решение.

     <img src=mithsoftware_pic2_8.png>

     ђис. 2.8
     ‚  предшествующих