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

        ѓлава 8. ЋбъЯвлЯЯ удар
     <i>Џрактика - лучший учитель.
     Џ“Ѓ‹€‰
     Ћпыт - дорогой учитель, но длЯ глупцов иного нет.
     Ђ‹њЊЂЌЂ• Ѓ…„ЌЋѓЋ  ђ€—Ђђ„‘Ђ</i>(Ѓедный ђичард  -  образ необразованного,  но
здравомыслЯщего  доморощенного философа, созданный  Ѓенджамином  ”ранклином,
издававшим в  1732  - 1757  годах ежегодный  альманах и  использовавшим этот
псевдоним (<i>примеч. перев.</i>).)
     ‘колько  времени потребует задача системного  программированиЯ? ‘колько
сил понадобитсЯ? Љак можно это оценить?
     ђанее  Я предложил соотношениЯ,  которые  можно применЯть  длЯ  времени
планированиЯ,  написаниЯ программ, тестированиЯ компонентов  и  тестированиЯ
системы.  ‚о-первых, нужно  сказать, что  <i>нельзЯ</i> делать  оценку всей задачи,
оцениваЯ только  часть, относЯщуюсЯ к написанию  программ, а  затем применЯЯ
соотношениЯ. Ќаписание программ составлЯет лишь одну шестую часть задачи или
около того, и ошибки при его оценивании или в соотношениЯх могут привести  к
смехотворным результатам.
     ‚о-вторых,   нужно  учитывать,  что  оценки,  полученные  при  создании
отдельных   небольших  программ,  нельзЯ  применЯть  длЯ  больших  системных
продуктов.  Љ  примеру, длЯ  программы,  насчитывающей  3200  слов,  ‘акман,
ќриксон и  ѓрант оценивают суммарное времЯ написаниЯ программ и отладки  длЯ
одного программиста в 178 часов, что экстраполируетсЯ до 35800  операторов в
год. ‚двое меньшаЯ программа потребовала меньше четверти указанного времени,
что  при   экстраполЯции  дает  производительность,   близкую  уже  к  80000
операторам в  год.1  Ќеобходимо  добавить  затраты времени  на планирование,
составление  документации,  тестирование, системную интеграцию  и  обучение.
‹инейнаЯ экстраполЯциЯ данных, относЯщихсЯ к коротким задачам, бессмысленна.
…сли  экстраполировать  времЯ,  за  которое можно пробежать стометровку,  то
окажетсЯ, что можно пробежать милю менее чем за три минуты.
     Џрежде чем отказатьсЯ  от этих  данных,  отметим,  что и длЯ не  совсем
сравнимых  задач  они  показывают,  что  объем работы  растет  как степеннаЯ
функциЯ  размера,   <i>даже</i>  без  учета  процесса   отмена  информацией  (кроме
программиста с собственной памЯтью).
     Џоказанные  на  рис.  8.1  данные  вызывают  грустные  чувства.  ѓрафик
демонстрирует  результаты,  полученные  в исследовании, проведенном  Ќанусом
(Nanus) и ”арром (Farr)2 в System Development Corporation. ‚  нем выЯвлЯетсЯ
зависимость с показателем степени 1,5:
     Ћбъем работы = (константа) — (количество команд)1,5.
     ‚ другом  исследовании, проведенном в этой компании, о котором сообщает
‚айнвурм (Weinwurm)3, также получен показатель, близкий к 1,5.
     …сть  несколько   исследований  относительно  производительности  труда
программиста,  в  которых  предложен рЯд  технологий оцениваниЯ.  …сть обзор
опубликованных  данных,  подготовленный Њоурином  (Morin).4 џ  приведу здесь
лишь несколько наиболее показательных результатов.

     <img src=mithsoftware_pic8_1.png>

     <b>ђис. 8.1</b> ‡атраты на программирование как функциЯ размера программы
     „анные Џортмана
     —арльз Џортман (Charles Portman), менеджер отдела программированиЯ ICL
- Computer Equipment  Organization (Northwest) в Њанчестере, предлагает свое
понимание проблемы, которое может оказатьсЯ полезным.
     Ћн  обнаружил,  что  его  команды  программистов  отстают  от  графиков
примерно наполовину, т.е. каждое задание  выполнЯетсЯ примерно вдвое дольше,
чем предполагалось.  Џри  этом оценки  очень тщательно проводились  группами
опытных  экспертов,  оценивавших  в человеко-часах  трудоемкость  нескольких
сотен  подзадач  с помощью диаграмм  Џ…ђ’.  Љогда выЯвлЯлось  отставание  от
графика, он просил вести подробные ежедневные журналы использованиЯ времени.
€з них  выЯснилось,  что ошибка  оценок полностью объЯснЯетсЯ  тем, что  его
команды  использовали  на  программирование  и  отладку  лишь  50  процентов
рабочего  времени.  Ћстальное  времЯ  терЯлось  из-за   отказов  машины,  на
небольшие срочные посторонние заданиЯ, совещаниЯ, писание бумаг, дела фирмы,
болезни,  личное времЯ  и  т.д.  Љороче оценки  исходили из  нереалистичного
предположениЯ о том, какаЯ часть рабочего времени отводитсЯ  непосредственно
работе.6
     „анные Ђрона
     „жоэл  Ђрон  (Joel  Aron), менеджер IBM  по  системным  технологиЯм  в
ѓейтерсберге, штат  Њэриленд,  изучал эффективность  труда  программистов во
времЯ работы над девЯтью крупными системами (<i>крупнаЯ</i> соответствует более чем
25 программистам  и 30000 операторов).7  Ћн  классифицирует такие системы  в
соответствии с интенсивностью взаимодействиЯ между программистами (и частЯми
системы) и обнаруживает следующие величины производительности:
     Ћчень слабое взаимодействие 10000 инструкций на человека в год
     Ќекоторое взаимодействие 5000 инструкций на человека в год
     ‘ущественное взаимодействие 1500 инструкций на человека в год
     —еловеко-год  здесь  не учитывает  поддержку  и системное тестирование,
только  разработку и программирование. Џри введении поправки с коэффициентом
два  с  целью  учета системного тестированиЯ эти цифры  близко соответствуют
данным •арра.
     „анные •арра
     „жон  •арр  (John  Harr),  менеджер  по  программированию  Electronic
Switching System, входЯщей в  состав Bell Telephone  Laboratories, сообщил о
своем  собственном  опыте  и  других  известных  ему  данных  в  докладе  на
Ћбъединенной  конференции  по  компьютерам  весной  1969  года.8 ќти  данные
приведены на рисунках 8.2, 8.3 и 8.4.
     Ќаиболее  поучителен  и содержит  больше данных рисунок 8.2. Џервые два
заданиЯ ЯвлЯютсЯ, по  преимуществу, управлЯющими программами, а два вторых -
Языковыми   транслЯторами.   Џроизводительность   измерЯетсЯ  в   количестве
отлаженных   слов   за   человеко-год.    Џри    этом   учитываетсЯ    времЯ
программированиЯ, отладки  и системного тестированиЯ. Ќеизвестно, учтены  ли
затраты на планирование, поддержку машины, составление документации и т.п.

     <img src=mithsoftware_pic8_2.png>

     <b>ђис.  8.2</b>   ‘водка   по   четырем   важнейшим   программным   проектам,
осуществленным в ESS
     Џроизводительность разбиваетсЯ на два класса: длЯ  управлЯющих программ
составлЯет около 600 слов на человека за год, длЯ транслЯторов - около 2200.
Ћбратите внимание,  что все  четыре программы приблизительно одного размера,
различие  состоит  в  размере  рабочих  групп,  продолжительности  работы  и
количестве модулей. —то  ЯвлЯетсЯ  причиной,  а что -  следствием?  Ѓыла  ли
сложность причиной того, что длЯ  управлЯющих  программ  требовалось  больше
людей? €ли же  большее число  модулей и человеко-месЯцев обусловлено большим
числом  людей,  привлеченных  к  работе?  Ѓыла ли  большаЯ продолжительность
выполнениЯ вызвана сложностью  проблем или  многочисленностью занЯтых людей?
’рудно  сказать  с уверенностью. Љонечно,  управлЯющие  программы были более
сложными. …сли оставить в стороне эти  неопределенности, то цифры  описывают
реальную   производительность  при   создании  больших   систем,  и   потому
представлЯют ценность.
     Ќа  рисунках   8.3  и  8.4  показаны  некоторые  интересные  данные   о
фактической скорости программированиЯ и отладки в сравнении с прогнозом.
     „анные OS/360
     Ћпыт OS/360 подтверждает данные •арра, хотЯ  данные по OS/360 не столь
подробны.  ‚  группах  разработки  управлЯющей программы  производительность
составила 600-800 отлаженных команд в год  на человека. ‚ группах разработки
транслЯторов производительность достигла 2000-3000  отлаженных  команд в год
на  человека. Џри этом учитываетсЯ планирование,  тестирование  компонентов,
системное  тестирование  и  некоторые затраты на поддержку. Ќасколько Я могу
судить, эти данные согласуютсЯ с результатами •арра.

     <img src=mithsoftware_pic8_3.png>

     <b>ђис. 8.3</b> ЏредсказаннаЯ и фактическаЯ скорость программированиЯ

     <img src=mithsoftware_pic8_4.png>

     <b>ђис. 8.4</b> ЏредсказаннаЯ и фактическаЯ скорость отладки
     „анные  Ђрона, •арра  и OS/360 дружно  подтверждают  резкие различиЯ  в
производительности в  зависимости от сложности и трудности  самой  задачи. ‚
работе оцениваниЯ сложности Я придерживаюсь той линии, что компилЯторы втрое
хуже обычных пакетных прикладных программ, а операционные системы втрое хуже
компилЯторов.9
     „анные Љорбато
     „анные  •арра  и  OS/360   относЯтсЯ  к  программированию  на   Языке
ассемблера.   …сть   немного   публикаций  относительно   производительности
системного программированиЯ с использованием Языков высокого уровнЯ. Љорбато
(Corbato) из проекта MAC Њассачусетского технологического института сообщает
о  средней  производительности  1200  строк  отлаженных  операторов  PL/I на
человека  в  год при  разработке  операционной  системы  MULTICS (от  1 до 2
миллионов слов).10
     ќто число очень вдохновлЯет. Љак у других проектов, MULTICS включает  в
себЯ  управлЯющие  программы  и  Языковые   транслЯторы.  ђезультатом  также
ЯвлЯетсЯ  системный продукт,  отлаженный и документированный. „анные кажутсЯ
сравнимыми  в  отношении  видов  исполненной  работы.  Ђ  производительность
повышаетсЯ   до   средней   величины   между   управлЯющими  программами   и
транслЯторами в других проектах.
     Ќо  Љорбато указывает количество <i>строк</i> за  год на человека, а не  <i>слов</i>!
Љаждому оператору в его системе соответствует  от  трех  до пЯти  слов кода,
написанного вручную! €з этого можно сделать два важных вывода:
     - Џроизводительность, измереннаЯ в элементарных  операциЯх, оказываетсЯ
постоЯнной, что кажетсЯ разумным,  если  учитывать,  сколько  времени  нужно
думать над оператором, и сколько ошибок может в нем быть.11
     -    Џри    использовании    подходЯщего    Языка    высокого    уровнЯ
производительность можно повысить в пЯть раз.12

        ѓлава 9. „ва в  одном
     <i>Ђвтору стоит присмотретьсЯ к Ќою и...  поучитьсЯ на
примере Љовчега, как в очень маленькое пространство втиснуть очень много.
     ‘€„Ќ…‰ ‘Њ€’, "ќ„€ЌЃ“ђѓ‘ЉЋ… ђ…‚ћ"</i>
     <b>ђазмер программы как стоимость</b>
     Љакова стоимость  программы?  …сли не  считать  времени выполнениЯ, то
помЯть,  занимаемаЯ программой, составлЯет главные  издержки. ќто верно даже
длЯ собственных разработок,  когда  пользователь  платит  автору существенно
меньше,  чем стоит разработка. ‚озьмем интерактивную систему IBM  APL. Џлата
за ее  использование составлЯет  $400  в месЯц. Џри  работе она  требует  не
меньше  160  Љбайт памЯти.  “ машины  Model 165 ежемесЯчнаЯ  аренда 1 Љбайта
памЯти  стоит около  $12.  …сли  пользоватьсЯ программой  круглосуточно,  то
месЯчнаЯ плата составит $400 за пользование  программой  и $1920 за  памЯть.
…сли пользоватьсЯ  системой APL лишь  четыре часа в  день, то месЯчнаЯ плата
составит $400 за пользование программой и $320 за использование памЯти.
     Ќередко можно встретить человека,  выражающего ужас по поводу того, что
в машине,  имеющей  2 Њбайт  памЯти, под  операционную  систему  может  быть
отведено 400 Љбайт.  ќто столь же  глупо, как ругать Ѓоинг-747 за то, что он
стоит 27 миллионов долларов.  Ќадо же спросить:  "Ђ что  она делает?" Љакую,
собственно,  простоту  в  использовании  и  производительность  (посредством
эффективного использованиЯ системы) получаешь за  потраченные деньги? ЌельзЯ
ли вложенные в аренду памЯти $4800 в месЯц израсходовать с большей пользой -
на другие аппаратные средства, программистов, прикладные программы?
     Џроектировщик   системы  отводит   часть   всех   аппаратных   ресурсов
программам, резидентно находЯщимсЯ в памЯти,  если считает, что пользователю
это  нужнее, чем сумматоры,  диски  и  т.д.  ЌельзЯ критиковать  программную
систему  за   размер   <i>как  таковой</i>,  и   в  то  же   времЯ  последовательно
пропагандировать тесную интеграцию проектированиЯ аппаратного и программного
обеспечениЯ.
     Џоскольку размер  определЯет значительную  долю  того, во что обходитсЯ
пользователю  системный программный продукт, изготовитель должен планировать
размер, контролировать  его и  разрабатывать технологии, уменьшающие размер,
подобно  тому,  как  изготовитель  аппаратной   части  планирует  количество
деталей,  контролирует  его  и  разрабатывает методы  сокращениЯ  количества
деталей.  Љак и  длЯ  всЯкой  цены,  плох  не большой  размер как таковой, а
размер, не вызываемый необходимостью.
     “правление размером
     „лЯ  менеджера   проекта   управление   размером   ЯвлЯетсЯ  отчасти
технической,  отчасти административной задачей. —тобы устанавливать  размеры
предлагаемых систем,  необходимо изучать  пользователей и  используемые  ими
приложениЯ.  ‡атем системы  должны разлагатьсЯ  на  компоненты,  длЯ которых
определЯютсЯ проектные размеры.  Џоскольку варьировать соотношением скорости
и  размера  можно  лишь достаточно  большими  скачками, планирование размера
ЯвлЯетсЯ непростым делом, требующим знаниЯ возможных компромиссов длЯ каждой
части. Ћпытный  менеджер сделает  себе также "заначку", которую можно  будет
использовать в процессе работы.
     ‚се же при работе над OS/360 пришлось извлечь несколько горьких уроков,
несмотрЯ на то, что все описанные меры были принЯты.
     Џрежде всего,  недостаточно  установить размер  памЯти, нужно  взвесить
размер со всех сторон.  Ѓольшинство прежних  операционных систем размещалось
на магнитных лентах, и большое времЯ поиска на ленте не располагало к частой
загрузке программных  сегментов. OS/360  располагалась на  диске,  как  и ее
непосредственные предшественники - операционнаЯ система  Stretch  и дисковаЯ
операционнаЯ  системы  1410-7010.  …е  создатели  получили  свободу  легкого
обращениЯ   к   диску.   Џервоначально  это   обернулось   катастрофой   длЯ
производительности.
     Џри   определении  размеров  памЯти  компонентов   мы   не   установили
одновременно  бюджетов  доступа.  Љак   и  следовало  ожидать,  программист,
выходивший за рамки  определенной ему памЯти, разбивал программу на оверлеи.
‚ результате и суммарный размер увеличивалсЯ, и выполнение замедлЯлось. •уже
то, что наша система  административного контролЯ  не смогла  это обнаружить.
Љаждый программист  сообщал,  сколько  памЯти он использовал, и  так  как он
укладывалсЯ в задание, никто не беспокоилсЯ.
     Љ счастью,  вскоре настал день, когда заработала  система моделированиЯ
технических   характеристик   OS/360.  Џервые  результаты  показали  наличие
серьезных проблем. Њоделирование компилЯции с Fortran H на машине Model 65 с
барабанами дало результат пЯть операторов  в минуту! Ђнализ показал, что все
модели управлЯющей  программы  делали  множество  обращений  к  диску.  „аже
интенсивно  используемые  модули  супервизора  часто  обращались к диску,  и
результат по звуку весьма напоминал шелест перелистываемой книги.
     ЏерваЯ мораль Ясна: планировать нужно как размер резидентной части, так
и  общий  размер.  Џомимо  планированиЯ  этих размеров нужно  планировать  и
количество обращений к диску длЯ обратной записи.
     ‚торой урок был аналогичен. ђесурсы  памЯти устанавливались прежде, чем
длЯ каждого модулЯ было определено точное распределение памЯти  длЯ функций.
‚ результате каждый программист, не укладывавшийсЯ в  размеры, искал, что из
его  кода  можно  выкинуть  через  забор  в  памЯть  соседу. Џоэтому  буфера
управлЯющей программы стали  частью  памЯти пользователЯ. —то  хуже,  так же
поступали  все   управлЯющие   блоки,  и   в   результате   были   полностью
скомпрометированы безопасность и защита системы.
     Џоэтому второй вывод  тоже совершенно Ясен:  при задании размера модулЯ
нужно точно определить, что он должен делать.
     €  третий,  более серьезный урок, который нужно извлечь из этого опыта.
Џроект был  слишком велик,  а общение между менеджерами недостаточным, чтобы
многочисленные участники могли  почувствовать себЯ добывающими зачетные очки
длЯ команды, а  не  создателЯми  программных продуктов. Љаждый оптимизировал
свой  личный  участок,  чтобы  решить  поставленные   задачи,  и   мало  кто
задумывалсЯ над  тем,  как это отразитсЯ на  заказчике. ЏотерЯ  ориентации и
свЯзи представлЯют собой главную опасность  длЯ  больших проектов. ‚ течение
всей   разработки  системные  архитекторы  должны   поддерживать  постоЯнную
бдительность  длЯ  обеспечениЯ постоЯнной целостности  системы. Ћднако такаЯ
стратегиЯ  зависит от  позиции самих  разработчиков.  …два  ли не главнейшей
функцией менеджера  программного  проекта  должно  быть  воспитание  позиции
заботы об общей системе, ориентировки на пользователЯ.
     ’ехнологии сбережениЯ памЯти
     Ќикакое  распределение ресурсов памЯти и контроль не сделают программу
маленькой. „лЯ этого требуетсЯ изобретательность и мастерство.
     Ћчевидно,  что чем больше  функций, тем больше требуетсЯ памЯти при том
же  самом  быстродействии.  Џоэтому  первой областью,  где  нужно  приложить
мастерство,  ЯвлЯетсЯ  нахождение  компромисса   между  функциональностью  и
размером.  ‡десь мы сразу сталкиваемсЯ с  важной стратегической проблемой. ‚
какой  мере этот выбор  можно  предоставить пользователю? Њожно  разработать
программу со многими факультативными функциЯми, каждаЯ  из  которых  требует
памЯти.  Њожно сконструировать  генератор,  просматривающий список  опций  и
соответствующим  образом  адаптирующий  программу.  Ќо  цельнаЯ   программа,
соответствующаЯ каждому отдельному списку опций, занЯла  бы  меньше  памЯти.
ќто как в автомобиле: если  подсветка  карты, прикуриватель и часы  входЯт в
прейскурант как единаЯ статьЯ,  их стоимость окажетсЯ ниже, чем если порознь
выбирать  каждый из  предметов.  Џоэтому  проектировщику  следует определить
степень детализации опций пользователЯ.
     …сли  система  проектируетсЯ  длЯ  работы  с  памЯтью  разного  объема,
возникает другой важный  вопрос. „иапазон  приспособлЯемости нельзЯ  сделать
произвольно широким - даже при разбиении программы на очень мелкие модули. ‚
маленькой  системе  большинство  модулей перегружаетсЯ.  ‡начительнаЯ  часть
резидентной памЯти маленькой системы должна быть отведена длЯ  временной или
страничной  памЯти,  в  которую   загружаютсЯ  другие   части.   …е   размер
ограничивает  размер  каждого модулЯ. Ђ  разбиение  функций на мелкие модули
влечет потери и производительность, и памЯти. Џоэтому в большой системе, где
временнаЯ  памЯть в  двадцать  раз  больше,  она  лишь  позволЯет  уменьшить
количество  обращений.  €з-за маленьких  размеров модулей  система  все-таки
терЯет  в скорости и расходовании  памЯти.  Џо  этой  причине  эффективность
системы, которую можно построить их модулей маленькой системы, ограничена.
     ‚торой областью  приложениЯ мастерства ЯвлЯетсЯ нахождение  компромисса
между  памЯтью  и быстродействием. „лЯ отдельной функции  увеличение  памЯти
влечет за собой рост быстродействиЯ,  что  справедливо в удивительно широком
диапазоне величин. ќтот факт делает возможным установление ресурсов памЯти.
     —тобы  облегчить  своей  команде  поиск  правильного соотношениЯ  между
памЯтью  и производительностью, менеджер может сделать две  вещи. ‚о-первых,
организовать обучение технике программированиЯ,  а не просто  полагатьсЯ  на
природный ум и предшествующий опыт. ќто особенно важно, если машина или Язык
новые.  Ћсобенности их  эффективного  использованиЯ  нужно  быстро изучить и
сделать общим достоЯнием, возможно, присуждаЯ особые призы за освоение новой
техники.
     ‚о-вторых,  нужно  понЯть,  что  у программированиЯ есть  технологиЯ  и
компоненты нужно собирать из готовых частей. ‚ каждом проекте должен иметьсЯ
набор  хороших  процедур  или  макросов  длЯ  обработки  очередей,   поиска,
хешированиЯ  и  сортировки,  причем  не  менее  чем в двух  вариантах: одном
быстром,  другом  экономЯщем  памЯть.  ђазработка  такой технологии ЯвлЯетсЯ
важной задачей  реализации, которую можно  решать параллельно  с разработкой
системной архитектуры.
     Џредставление - суть программированиЯ
     ‡а мастерством стоит изобретательность,  благодарЯ  которой поЯвлЯютсЯ
экономичные  и  быстрые программы. Џочти  всегда  это  ЯвлЯетсЯ  результатом
стратегического   прорыва,   а   не   тактического  умениЯ.   €ногда   таким
стратегическим   прорывом  ЯвлЯетсЯ   алгоритм,   как,   например,   быстрое
преобразование ”урье, предложенное Љули и  ’ьюки, или замена <i>n</i>2 сравнений на
<i>n</i> log <i>n</i> при сортировке.
     ѓораздо    чаще   стратегический   прорыв   происходит   в   результате
представлениЯ  данных  или  таблиц.  ‡десь  заключена сердцевина  программы.
Џокажите мне блок- схемы, не показываЯ таблиц, и Я  останусь  в заблуждении.
Џокажите  мне ваши таблицы, и блок-схемы, скорей всего, не понадобЯтсЯ:  они
будут очевидны.
     Џримеры   мощи,  которой  обладает  представление,  легко  умножить.  џ
вспоминаю    одного    молодого     человека,    занимавшегосЯ     созданием
усовершенствованного консольного интерпретатора длЯ  IBM  650.  …му  удалось
вместить  его  в   поразительно  малое  пространство   благодарЯ  разработке
интерпретатора  длЯ интерпретатора  и  пониманию  того,  что  взаимодействие
человека с  машиной происходит медленно и редко, а памЯть дорога. ќлегантный
маленький компилЯтор с Fortran фирмы Digitek использует особое очень плотное
представление кода самого компилЯтора,  благодарЯ чему не требуетсЯ  внешней
памЯти. ‚ремЯ, которое  тратитсЯ на распаковку кода, десЯтикратно  окупаетсЯ
за счет отсутствиЯ ввода-вывода. (“пражнениЯ в конце главы  6 книги Ѓрукса и
€версона  "ЂвтоматическаЯ   обработка   данных"1  включает  подборку   таких
примеров, как и многие упражнениЯ у Љнута.2)
     Џрограммист, ломающий голову по поводу нехватки памЯти,  часто поступит
лучше  всего,  оставив  в  покое  свой  код,  вернувшись  назад и хорошенько
посмотрев свои данные. Џредставление - суть программированиЯ.

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

     <img src=mithsoftware_pic10.png>

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

        ѓлава  11.  Џланируйте  на  выброс
     <i>‚  этом  мире  нет  ничего  постоЯннее
непостоЯнства.
     ‘‚€”’
     ђазумно взЯть  метод и испытать его. Џри  неудаче  честно признайтесь в
этом и попробуйте другой метод. Ќо главное, делайте что-нибудь.
     ”ђЂЌЉ‹€Ќ „. ђ“‡‚…‹њ’</i>
     <b>Ћпытные заводы и масштабирование</b>
     €нженеры-химики  давно понЯли, что процесс,  успешно осуществлЯемый в
лаборатории, нельзЯ одним  махом  перенести в  заводские  условиЯ. Ќеобходим
промежуточный шаг, создание <i>опытного завода</i>, чтобы получить опыт наращиваниЯ
количеств веществ  и функционированиЯ  в  незащищенных  средах.  Љ  примеру,
лабораторный процесс  опреснениЯ  воды  следует проверить на опытном  заводе
мощностью 50  тысЯч литров  в  день,  прежде чем  использовать  в  городской
системе водоснабжениЯ мощностью 10 млн. литров в день.
     ђазработчики программных систем тоже получили этот урок, но, похоже, до
сих  пор его  не  усвоили.  ‚  одном  проекте за  другим  разрабатывают  рЯд
алгоритмов  и  затем начинают  создавать  поставлЯемое  клиенту  программное
обеспечение по графику, требующему поставки первой же сборки.
     ‚  большинстве проектов  первой  построенной  системой  с  трудом можно
пользоватьсЯ. Ћна может быть слишком медленной, слишком большой, неудобной в
использовании,  а то и все  вместе. Ќе  остаетсЯ  другой альтернативы, кроме
как, поумнев,  начать сначала и  построить перепроектированную  программу, в
которой  эти  проблемы решены. Ѓраковка  и перепроектирование могут делатьсЯ
длЯ всей системы сразу или по частЯм. Ќо весь опыт разработки больших систем
показывает, что  будет  сделано.2 ‚  тех случаЯх,  когда  используютсЯ новые
системные  концепции  и новые технологии,  приходитсЯ  создавать систему  на
выброс,  поскольку даже самое  лучшее планирование не столь всеведуще, чтобы
попасть в цель с первого раза.
     Џоэтому проблема не в том,  создавать или  нет опытную систему, которую
придетсЯ  выбросить.  ‚ы все равно это сделаете. ‚опрос  единственно  в том,
планировать  ли заранее разработку системы  на выброс или  обещать  клиентам
поставку системы, которую придетсЯ  выбросить. …сли смотреть под этим углом,
ответ  становитсЯ намного проще.  Џоставка  хлама клиенту позволЯет выиграть
времЯ,   но   происходит   это  ценой   мучений   пользователЯ,   отвлечений
разработчиков  во времЯ  перепроектированиЯ  и  дурной  репутации  продукта,
которую  даже   самой  удачно  перепроектированной  программе  будет  трудно
победить.
     Џоэтому <i>планируйте выбросить первую версию - вам все равно придетсЯ это
сделать</i>.
     ЏостоЯнны только изменениЯ
     Џосле уЯснениЯ того, что  опытную  систему  нужно  создавать, а потом
выбросить,  и  что перепроектирование  с новыми  идеЯми  неизбежно,  полезно
обратитьсЯ лицом к изменению  как  Явлению природы. Џервый  шаг -  признание
того,  что  изменение  -  это образ  жизни,  а  не  постороннее  и  досадное
исключение. Љосгроув мудро указал, что программист поставлЯет удовлетворение
потребности пользователЯ, а не какой- то осЯзаемый продукт. € в то времЯ как
программы  создаютсЯ, тестируютсЯ и  используютсЯ, менЯютсЯ  как фактические
потребности пользователЯ, так и понимание им своих потребностей.3
     Љонечно, это  справедливо  и в отношении потребностей,  удовлетворЯемых
физическими  продуктами,   будь   то  автомобили  или  компьютеры.  Ќо  само
существование  осЯзаемого  продукта определЯет  запросы  пользователЯ  и  их
квантование. Џодатливость  и  неосЯзаемость программного продукта  побуждают
его создателей к бесконечному изменению требований.
     џ далек от того, чтобы считать,  будто все изменениЯ целей и требований
клиента можно  или  необходимо  учитывать в  проекте. Ћчевидно,  должен быть
установленный  порог, который  должен подниматьсЯ все  выше  и выше  по ходу
разработки, иначе ни один продукт никогда не будет создан.
     ’ем  не  менее  некоторые  изменениЯ  в  задачах  неизбежны,  и   лучше
подготовитьсЯ  к  ним  заранее,  чем  предполагать,  что  их  не  возникнет.
Ќеизбежны  не только  изменениЯ  в целЯх,  но  также  изменениЯ  в стратегии
разработки и  технологии.  ЉонцепциЯ  "работы на  мусорный  Ящик" есть  лишь
признание того факта, что по мере приобретениЯ опыта менЯетсЯ проект.4
     Џланируйте внесение изменений в систему
     ‘пособы проектированиЯ  системы с  учетом  будущих  изменений  хорошо
известны и широко обсуждаютсЯ в литературе - возможно, шире обсуждаютсЯ, чем
применЯютсЯ. Ћни включают в себЯ тщательное разбиение на модули, интенсивное
использование  подпрограмм,   точное  и   полное   определение  межмодульных
интерфейсов  и  полную  их  документацию.  Њенее  очевидно,  что  при  любой
возможности  необходимо использовать стандартные последовательности вызова и
технологии табличного управлениЯ.
     Ћчень   важно   использовать  Языки   высокого  уровнЯ   и   технологии
самодокументированиЯ,  чтобы уменьшить число  ошибок,  вызываемых изменений.
Њощную   поддержку  при  внесении  изменений   оказывают   операции  времени
компилЯции по включению стандартных объЯвлений.
     ‚ажным приемом ЯвлЯетсЯ квантование изменений.  Љаждый  продукт  должен
иметь нумерованные версии, и каждаЯ версиЯ должна иметь свой график  работ и
дату фиксации, после которой изменениЯ включаютсЯ уже в следующую версию.
     Џланируйте организационную структуру длЯ внесениЯ изменений
     Љосгроув рекомендует ко всем планам, вехам и графикам относитьсЯ как к
пробам, чтобы облегчить изменениЯ. ‡десь он заходит слишком далеко - сегоднЯ
группы программистов  терпЯт  неудачи  обычно  из-за  слишком слабого, а  не
слишком сильного административного