 критикуЯ
продукты, не удовлетворЯющие этому интерфейсу.
     ќто  отличительный пример  технологии,  рекомендованной в главе  6  длЯ
достижениЯ  единообразиЯ  путем  поощрениЯ  других  сторон   непосредственно
включать в  свои  продукты имеющийсЯ  код вместо  разработки  новых программ
согласно имеющимсЯ спецификациЯм.
     <b>‘удьба WIMP: устаревание.</b> ЌесмотрЯ на все достоинства, по моему мнению,
интерфейс WIMP через поколение  станет достоЯнием истории. “казание курсором
останетсЯ   способом   заданиЯ   существительных   при   управлении   нашими
компьютерами.  „лЯ  выражениЯ  глаголов станет  использоватьсЯ  речь.  ’акие
инструменты,   как  Voice  Navigator   длЯ  Њаков  и  Dragon   длЯ  PC,  уже
предоставлЯют такую возможность.
     Ќе разрабатывайте программ на выброс, каскаднаЯ модель неверна!
     ‚  главе  11 даетсЯ радикальный  совет: "планируйте выбросить  первую
программу,  вам  все  равно  придетсЯ  это  сделать".  ‘ейчас  Я  считаю это
ошибочным  -  не  в силу  чрезмерного  радикализма,  но  в  силу  чрезмерной
упрощенности.
     ‘амой  большой  ошибкой  этой  концепции  ЯвлЯетсЯ  косвенное  принЯтие
классической  последовательности  -  в   виде  каскада   -  модели  созданиЯ
программы.   ќта  модель  происходит   от  структуры  диаграммы  ѓранта  длЯ
поэтапного  процесса,  которую часто  изображают,  как  на  рисунке  19.1. ‚
классической  статье 1970 года  ‚интон  ђойс (Winton Royce) усовершенствовал
последовательную модель путем:
     - добавлениЯ некоторой обратной свЯзи с предшествующими этапами;
     -    ограничениЯ     обратной     свЯзи     только    непосредственными
предшественниками,  чтобы  исключить  вызываемые  ими издержки  и задержки в
выполнении графика.
     Ћн  предвосхитил  "Њ—-Њ",  рекомендовав  разработчикам  "делать  работу
дважды"8. ѓлава 11 - не единственнаЯ, на которую  повлиЯла каскаднаЯ модель.
Ћна проходит  через всю книгу, начинаЯ с правила планированиЯ в главе 2. ќто
практическое правило отводит 1/3 времени на планирование, 1/6 - на написание
программ,  1/4   -  на  тестирование  компонентов   и  1/4  -  на  системное
тестирование.

     <img src=mithsoftware_pic19_1.png>

     <b>ђис. 19.1</b> ЉаскаднаЯ модель созданиЯ программы
     Ћсновное заблуждение  каскадной  модели состоит  в  предположениЯх, что
проект  проходит через весь процесс  <i>один</i> раз, архитектура хороша и проста в
использовании,   проект  осуществлениЯ   разумен,   а  ошибки  в  реализации
устранЯютсЯ по мере тестированиЯ. €ными словами, каскаднаЯ модель исходит из
того,  что  все  ошибки  будут  сосредоточены  в  реализации,  а  потому  их
устранение  происходит  равномерно  во  времЯ  тестированиЯ  компонентов   и
системы.
     "Џланируйте на выброс" действительно резко нападает на это заблуждение.
Ћшибка  не в диагнозе,  а  в  лекарстве.  ‘ейчас Я  предположил,  что первую
систему можно отбросить  или перепроектировать не  всю целиком, а по частЯм.
•орошо,  если  это  так, но  при  этом  не затрагиваетсЯ  корень проблемы. ‚
каскадной  модели  системное тестирование, а  следовательно  и  тестирование
пользователем,  отодвигаетсЯ  в  конец процесса созданиЯ программы.  Џоэтому
есть шанс  обнаружить крайние неудобства  длЯ пользователЯ, или неприемлемые
технические   характеристики,   или   опасную   уЯзвимость  к  ошибкам   или
злонамеренным действиЯм пользователЯ лишь в самом конце разработки. €зучение
спецификаций  при  альфа-тестировании  нацелено на раннее обнаружение  таких
ошибок, но ничто не может заменить непосредственных пользователей.
     ‚торым недостатком каскадной модели ЯвлЯетсЯ предположение, что система
строитсЯ сразу всЯ  целиком  длЯ  тестированиЯ с начала до конца после того,
как  завершены все проектные разработки, большаЯ часть написаниЯ  программ и
значительнаЯ часть тестированиЯ компонентов.
     Љ   несчастью,  каскаднаЯ  модель,   это   преобладавшее  в  1975  году
представление  о  программных  проектах,  была  включена  в  DOD-STD-2167  -
спецификацию   Њинистерства  обороны   длЯ  любого   военного   программного
обеспечениЯ. Џо этой причине она  просуществовала долгое  времЯ  после того,
как большаЯ часть думающих практиков осознала ее неадекватность и отказалась
от нее. Љ счастью, в ЊЋ позднее понЯли истину.9
     <b>Ќеобходимо   двигатьсЯ   против  течениЯ.</b>  Ћпыт   и  идеи   из   каждой
расположенной  ниже  по  течению  части  процесса  созданиЯ  программы,  как
энергичный  лосось, должны прыгать  вверх  по  течению,  иногда  сразу через
несколько этапов, и воздействовать на деЯтельность наверху.
     Џроектные    разработки    покажут,   что   некоторые   предусмотренные
архитектурой  возможности  ухудшают  технические  характеристики,  и  потому
архитектура  должна   быть  переработана.  Џрограммирование  при  реализации
выЯвит,  что некоторые функции  непомерно  увеличивают  требованиЯ к памЯти,
поэтому нужно внести изменениЯ в архитектуру и разработку.
     Џоэтому вполне может потребоватьсЯ осуществить несколько итераций цикла
архитектура-разработка, прежде чем начать какую-либо программную реализацию.
     <b>Њодель пошагового созданиЯ лучше: последовательное уточнение
     Џостроение каркаса с начала  до  конца.</b>  ѓарлан Њиллз  (Harlan  Mills),
работающий  в  системе с разделением времени, давно уже  рекомендует строить
основной  цикл  опроса  системы реального  времени  с  вызовами  подпрограмм
(<i>заглушками</i>)  длЯ  всех  функций  (рис. 19.2),  но  пустыми  подпрограммами.
Ћткомпилируйте его, протестируйте, и он будет идти цикл за циклом, буквально
ничего не делаЯ, но делаЯ это без ошибок.10

     <img src=mithsoftware_pic19_2.png>

     ђис. 19.2
     Ќа следующем шаге мы  навешиваем модуль ввода (возможно, примитивный) и
модуль  вывода.  Voila!  ђаботающаЯ  система,  делающаЯ   нечто,   возможно,
неинтересное. ’еперь, функциЯ за функцией, мы  строим и добавлЯем модули. <i>Ќа
каждом  шаге  мы  имеем работающую  систему</i>. Џри  достаточном трудолюбии  на
каждом шаге  мы имеем отлаженную,  протестированную систему. (Џо мере  роста
системы растет и тЯжесть  повторного тестированиЯ всех новых модулей по всем
прежним контрольным примерам.)
     Џосле  того  как на примитивном  уровне  каждаЯ  функциЯ  работает,  мы
улучшаем или переписываем один модуль за другим, пошагово <i>наращиваЯ</i> систему.
€ногда длЯ надежности мы переписываем исходный  движущий цикл, а возможно, и
его интерфейсы с модулЯми.
     Џоскольку в любой момент времени у нас есть работающаЯ система:
     - можно очень рано начать тестирование пользователЯми;
     -  можно  принЯть  стратегию  разработки  в  соответствии  с  бюджетом,
полностью защищающую от перерасхода времени или  средств (возможно,  за счет
сокращениЯ функциональности).
     ‚ течение 22  лет  Я  преподавал  в лаборатории  программной  инженерии
“ниверситета  штата ‘евернаЯ  Љаролина, иногда вместе с „эвидом Џарнасом. Ќа
этих занЯтиЯх  бригады,  обычно  состоЯвшие из  четырех  человек, в  течение
одного  семестра  должны   были  построить  некоторую  реальную   прикладную
программную  систему. Џримерно  посередине этого  срока Я  стал  преподавать
инкрементную  разработку.  џ  был  поражен,  какой  возбуждающий  эффект  на
моральный дух группы  оказывает перваЯ картинка на экране, перваЯ работающаЯ
система.
     <b>‘емейства   Џарнаса.</b>  „эвид   Џарнас  был  главным  властителем  дум  в
программотехнике в течение всего этого 20-летнего периода. ‚сем известна его
идеЯ  скрытиЯ  информации.  Њенее  известна  очень  важнаЯ  идеЯ  Џарнаса  о
проектировании   программного   продукта   как   <i>семейства</i>   взаимосвЯзанных
продуктов.11 Ћн требует,  чтобы  проектировщик  имел в  виду  как дальнейшее
развитие, так  и  новые  версии  продукта и определЯл их  функциональные или
межплатформенные  различиЯ так, чтобы строить дерево  родственных  продуктов
(рис. 19.3).

     <img src=mithsoftware_pic19_3.png>

     ђис. 19.3
     ”окус при проектировании такого дерева  состоит  в том, чтобы  ближе к
корню поместить те решениЯ, изменение которых наименее вероЯтно.
     ’акаЯ  стратегиЯ   проектированиЯ  повышает   повторную  используемость
модулей. …ще важнее, что ее можно расширить, включаЯ не только  поставлЯемые
продукты, но и последовательные промежуточные версии, созданные по стратегии
инкрементируемых  сборок.   ‚   этом  случае   продукт   развиваетсЯ   через
промежуточные стадии с минимумом возврата назад.
     <b>Џодход   Microsoft:  "ежевечернЯЯ   сборка".</b>  „жеймс  Њаккарти   (James
McCarthy) описал мне процесс, использовавшийсЯ им и другими в Microsoft. ќто
пошаговое наращивание, доведенное до логического конца. Ћн пишет:
     <i>‘делав  первую  поставку, новые версии мы  поставлЯем с дополнительными
функциЯми, по  сравнению с существующим работающим продуктом.  Џочему должен
быть  иным процесс  первоначальной сборки? ‘ момента достижениЯ  нами первой
вехи  (у  первой  поставки три промежуточных  вехи)  мы  каждый вечер заново
собираем  разрабатываемую систему  (и прогонЯем  контрольные  примеры). –икл
сборки становитсЯ ритмом жизни проекта. Љаждый вечер  одна или более  бригад
программистов,  проводЯщих   тестирование,   регистрируют  модули  с  новыми
функциЯми. Џосле  каждой сборки  у  нас есть работающаЯ система. …сли сборка
оказываетсЯ неудачной,  мы останавливаем  весь процесс, пока ошибка не будет
найдена и исправлена. ‚ любой момент все в группе знают положение дел.
     ќто действительно тЯжело. ’ребуетсЯ выделение больших  ресурсов, но это
управлЯемый  процесс,  прослеживаемый  и  понЯтный. Ћн  вызывает  у  команды
доверие к себе. Ђ доверие определЯет мораль, эмоциональное состоЯние.</i>
     ’акой  процесс  удивлЯет  и  даже  шокирует  разработчиков  в  других
организациЯх.  Ћдин  из них говорит: "џ взЯл себе за  правило  делать сборку
каждую  неделю,  но  ежедневнаЯ  сборка,  Я думаю, потребует  слишком  много
труда." € это, возможно, верно.  Ќапример, в Bell Northern Research собирают
систему, состоЯщую из 12 миллионов строк, раз в неделю.
     <b>€нкрементнаЯ сборка  и  быстрое макетирование.</b>  Џоскольку  инкрементнаЯ
разработка  позволЯет рано  начать тестирование реальными  пользователЯми, в
чем ее отличие от быстрого макетированиЯ? Њне кажетсЯ, что  они свЯзаны,  но
различаютсЯ. Ћдним можно пользоватьсЯ без другого.
     •арел дает полезное определение макета:
     <i>(версиЯ программы, котораЯ) отражает только проектные решениЯ, принЯтые
в  процессе  подготовки  концептуальной  модели,  а  не  решениЯ,  вызванные
соображениЯми реализации.</i>12
     Њожно  построить  макет,  который  вовсе  не ЯвлЯетсЯ частью  продукта,
развивающегосЯ   в  направлении  поставки.  Ќапример,  можно  создать  макет
интерфейса,  за  которым  стоит  не реально  работающаЯ  программа,  а  лишь
конечный автомат, заставлЯющий его имитировать прохождение  состоЯний. Њожно
даже  макетировать  и  тестировать интерфейсы методом волшебника изумрудного
города,   когда   спрЯтанный   человек   имитирует  отклик   системы.  ’акое
макетирование может быть  весьма полезным  длЯ быстрого  получениЯ  обратной
свЯзи от пользователЯ, но оно находитсЯ совершенно в стороне от тестированиЯ
продукта, который готовитсЯ к поставке.
     Ђналогично, разработчики  могут попробовать построить вертикальный срез
продукта, в котором полностью реализован  весьма ограниченный набор функций,
чтобы  заранее пролить свет на те  места,  где могут таитьсЯ  опасности  длЯ
производительности продукта. ‚ чем состоит различие между сборкой на  первой
вехе в  процедуре  Microsoft и быстрым макетом? ‚ функциЯх. Џродукт с первой
вехи может  иметь такую ограниченную функциональность, что  ни  длЯ кого  не
будет представлЯть  интереса.  ѓотовность продукта  к поставке  определЯетсЯ
завершенностью в предоставлении полезного набора функций и своим  качеством,
уверенностью в надежной работе.
     Џарнас был прав, а Я - нет в отношении сокрытиЯ информации
     ‚ главе 7  Я противопоставлЯю  две точки зрениЯ на  то,  в  какой мере
каждый участник команды может иметь право или поощрЯтьсЯ к знанию проектов и
текстов программ, созданных коллегами. ‚о времЯ проекта Operating System/360
мы решили, что <i>все</i> программисты должны видеть  <i>весь</i> материал, т.е. у каждого
программиста была рабочаЯ тетрадь проекта, котораЯ к концу насчитывала свыше
10000  страниц.  •арлан  Њиллз убедительно  доказывал, что "программирование
должно  быть открытым процессом",  что  предоставление  всей работы на общее
обозрение способствует контролю качества как  благодарЯ давлению со  стороны
коллег, заставлЯющему работать  хорошо, так  и благодарЯ тому,  что  коллеги
действительно находЯт промахи и ошибки.
     ќтот  взглЯд резко  противоречит  мнению  „эвида  Џарнаса  о  том,  что
программные  модули  должны  быть инкапсулированы,  с  хорошо  определенными
интерфейсами,   а   внутренность   таких   модулей   должна   быть   частной
собственностью программиста,  невидимой  снаружи.  Џрограммисты  эффективнее
всего работают, будучи ограждены от внутренностей чужих модулей.13
     ‚ главе 7 Я заклеймил  идею Џарнаса как "рецепт катастрофы". Џарнас был
прав,  а  Я ошибалсЯ.  ‘егоднЯ Я убежден, что ограничение  информации, часто
осуществлЯемое  теперь   методами   объектного  программированиЯ,   ЯвлЯетсЯ
единственным способом поднЯть уровень программных разработок.
     €спользуЯ другие  методы, можно действительно попасть  в беду. ‘огласно
методике   Њиллза   программисты  могут   получить   подробности   семантики
интерфейсов, с которыми они работают, узнав,  что находитсЯ "по ту сторону".
“крывание этой семантики  может быть причиной  системных  ошибок.  ‘  другой
стороны, методика Џарнаса способствует устойчивости при внесении изменений и
больше  подходит  к  стратегии  проектированиЯ,  предполагающей изменениЯ  в
будущем.
     ‚ главе 16 утверждаетсЯ следующее:
     -   большаЯ  часть  роста  производительности  разработки  программного
обеспечениЯ  обеспечена  устранением  второстепенных трудностей,  таких  как
неудобные  Языки   программированиЯ  и  медленнаЯ  оборачиваемость  пакетной
обработки;
     - легких решений в этом направлении практически не осталось;
     -  радикального  прогресса   можно   добитьсЯ,   разрешив  существенные
сложности моделированиЯ сложных концептуальных конструкций.
     ‘амое очевидное  на этом пути - признать, что программы составлЯютсЯ из
концептуальных блоков,  значительно более  крупных, чем отдельные  операторы
Языков  высокого  уровнЯ:  подпрограмм, или  модулей,  или  классов. …сли мы
сумеем  ограничить проектирование и построение программ  задачей  соединениЯ
вместе  и  параметризации  таких  блоков  из  ранее  созданных  наборов,  то
радикально  повысим концептуальный  уровень  и избавимсЯ от огромного объема
работ и широких возможностей длЯ  ошибок,  существующих на уровне  отдельных
операторов.
     „анное Џарнасом определение  модулей с сокрытием информации было первым
открытым  шагом в этой  критически важной  программе исследований  и идейным
провозвестником  объектно-ориентированного  программированиЯ.  Ћн  определил
модуль как  программный объект с  собственной моделью  данных  и собственным
набором  операций. „оступ к его данным может быть  осуществлен  только через
имеющиесЯ   в   нем  операции.  ‘ледующий  шаг   ЯвилсЯ  вкладом  нескольких
исследователей:  развитие  модулей  Џарнаса  в  <i>абстрактный  тип  данных</i>, из
которого   можно   производить  много  объектов.  Ђбстрактный   тип   данных
обеспечивает  единообразный  способ  представлениЯ  и  заданиЯ   интерфейсов
модулей, а также дисциплину доступа, которую легко осуществлЯть.
     ’ретий шаг,  объектно-ориентированное  программирование,  вводит важное
понЯтие <i>наследованиЯ</i>, при  котором  классы (типы данных) по  умолчанию имеют
атрибуты  своих  предков  в  иерархии  классов.14 ’о,  что  мы  рассчитываем
получить  от  объектно-  ориентированного  программированиЯ,  происходит,  в
сущности,   от   первого  шага,  инкапсулЯции  модулей,  плюс  идеЯ  заранее
подготовленных   библиотек   модулей   или   классов,   <i>спроектированных   и
протестированных  с  целью   повторного   использованиЯ</i>.   Њногие  предпочли
проигнорировать   тот  факт,  что  такие  модули   не  просто  программы,  а
программные продукты в том смысле,  который разъЯснен  в  главе 1.  Ќапрасно
рассчитывать  на успешное  повторное  использование  модулей,  не  оплачиваЯ
начальные   издержки  на  разработку   качественных   программных   модулей:
обобщенных,  надежных,   протестированных  и   документированных.  Ћбъектно-
ориентированное программирование  и  повторное использование  обсуждались  в
главах 16 и 17.
     Ќасколько мифичен человеко-месЯц? Њодель и данные Ѓема
     ‚  течение  рЯда лет  были  выполнены  многочисленные  количественные
исследованиЯ  производительности  труда  программистов  и  влиЯющих  на  нее
факторов, особенно соотношений  между  обеспеченностью персоналом и графиком
работ.
     Ќаиболее обстоЯтельное  исследование сделано Ѓарри  Ѓемом (Barry Boehm)
на основании примерно 63  проектов, в основном в аэрокосмической области, из
них  около  25  -  в  TRW.  …го  работа  "ќкономика разработки  программного
обеспечениЯ" содержит не только результаты, но и рЯд полезных моделей затрат
с  нарастающей  сложностью.  •отЯ  несомненно,  что  применЯемые  в  моделЯх
коэффициенты различны  длЯ  обычных  космических  программ  и  длЯ программ,
создаваемых  в аэрокосмической области по  правительственным стандартам, все
же его модели подкреплЯютсЯ огромным количеством данных. џ думаю, что  книга
будет полезным классическим трудом и через поколение.
     Џолученные им  результаты  уверенно  подкреплЯют  содержащеесЯ  в  Њ—-Њ
утверждение  о  том, что соотношение  между численностью  занЯтых и временем
выполнениЯ  проекта  далеко  не линейное,  что  человеко-месЯц действительно
ЯвлЯетсЯ мифической мерой производительности. ‚ частности, он считает:15
     - ‘уществует  оптимальное,  с точки  зрениЯ  затрат,  времЯ  выполнениЯ
графика длЯ  первой поставки:  T =  2,5 (—Њ)1/3. ’о есть оптимальное времЯ в
месЯцах  изменЯетсЯ как  кубический  корень предполагаемого объема  работ  в
человеко- месЯцах - формула, полученнаЯ из  оценки размера и других факторов
в  его модели.  ‘ледствием ЯвлЯетсЯ криваЯ, дающаЯ  оптимальную  численность
занЯтых.
     - ЉриваЯ стоимости медленно растет, если запланированный график длиннее
оптимального. ђабота занимает все отведенное длЯ нее времЯ.
     - ЉриваЯ  стоимости резко растет, если  запланированный  график  короче
оптимального.
     - <i>Џрактически ни  один проект невозможно завершить  быстрее, чем  за  .
расчетного оптимального графика вне зависимости от количества занЯтых в нем!</i>
ќтот  примечательный результат  дает менеджеру программного проекта солидное
подкрепление,  когда  высшее  руководство   требует  принЯтиЯ   невозможного
графика.
     <b>Ќасколько  верен  закон   Ѓрукса?</b>  Ѓыли   даже   проведены   тщательные
исследованиЯ  закона  Ѓрукса   (намеренно  упрощенного),  согласно  которому
выделение  дополнительных  людей   длЯ  отстающего   графика  проекта   лишь
задерживает   его  выполнение.   ‹учше   всего  это  сделано  Ђбдель-•амидом
(Abdel-Hamid) и Њадником  (Madnick)  в честолюбивой и ценной книге "„инамика
программного  проекта:  интегрированный  подход".16  ‚   книге   разработана
количественнаЯ модель динамики проекта. ѓлава о законе Ѓрукса более подробно
вникает в  то, что  происходит  при  различных допущениЯх относительно того,
кого добавлЯют, и когда. —тобы исследовать это, авторы развивают собственную
тщательную модель программного  проекта среднего размера, предполагаЯ, что у
вновь  добавлЯемых людей  есть  криваЯ обучениЯ,  и  учитываЯ дополнительные
издержки на общение и обучение. Ћни приходЯт к выводу, что "добавление новых
людей  к  запаздывающему  проекту  всегда приводит  к его удорожанию, но  не
<i>всегда</i>   к  более  позднему  завершению"   (курсив  авторов).  ‚  частности,
увеличение численности работников в начале проекта гораздо безопаснее, чем в
конце,  поскольку  добавление  новых  людей  всегда  вызывает  отрицательный
эффект, длЯ компенсации которого требуютсЯ недели.
     туцке  (Stutzke)  предлагает  более  простую  модель   длЯ  проведениЯ
аналогичных исследований,  и с тем же  результатом.17 Ћн проводит  подробный
анализ процесса и издержек, свЯзанных с привлечением новых работников, Явным
образом  учитываЯ  отвлечение  наставников  от  непосредственной работы  над
проектом. Ћн проверЯл свою модель на реальном проекте, в котором численность
работником была удвоена, благодарЯ  чему  удалось уложитьсЯ в первоначальный
график,  несмотрЯ на  отставание в середине. Ћн  рассматривает  альтернативы
добавлению   новых  работников,  особенно  сверхурочную  работу.  Ќаибольшую
ценность  представлЯют  его  многочисленные  практические советы  о том, как
привлекать  новых работников, обучать  их,  обеспечивать  инструментарием  и
т.д.,  чтобы  минимизировать  отрицательный  эффект   увеличениЯ  персонала.
Ћсобенно достойно вниманиЯ его замечание,  что дополнительно привлекаемые на
поздних стадиЯх проекта работники должны быть игроками команды, стремЯщимисЯ
войти   в  игру  и  вписатьсЯ  в  процесс,  а  не  пытатьсЯ   изменить   или
усовершенствовать сам процесс!
     туцке считает, что дополнительнаЯ тЯжесть обмена информацией в крупном
проекте  имеет второй порЯдок  малости, и  не включает ее  в свою модель. Ќе
вполне Ясно, учитывают ли ее Ђбдель-•амид  и Њадник, и если да, то как. Ќи в
одной из моделей  не  учитываетсЯ  то обстоЯтельство, что работа должна быть
перераспределена - процесс, который длЯ менЯ часто оказывалсЯ нетривиальным.
     "Љрайне   упрощеннаЯ"   формулировка  закона  Ѓрукса  становитсЯ  более
полезной,   будучи   дополнена   этими   тщательно   сделанными  надлежащими
оговорками. ЏодытоживаЯ,  Я продолжаю придерживатьсЯ  исходного  утверждениЯ
как   приближениЯ  к  истине   нулевого   порЯдка,   практического  правила,
предупреждающего  менеджеров о неразумности  инстинктивной попытки  вытЯнуть
запаздывающий проект.
     Љадры решают все (или почти все)
     Ќекоторые читатели  удивлЯютсЯ,  что  большаЯ часть рассуждений  Њ—-Њ
посвЯщена   административным   сторонам   программной   инженерии,   а    не
многочисленным  техническим  проблемам. ’акой  перекос  частично  вызван той
ролью, которую Я играл  в  IBM Operating System/360  (теперь  MVS/370). …сли
смотреть глубже, это происходит от убеждениЯ, что качество людей,  занЯтых в
проекте,  их организациЯ и администрирование имеют гораздо  большее значение
длЯ успеха, чем инструменты,  которыми  они  пользуютсЯ, или применЯемые ими
технические решениЯ.
     Џоследующие исследованиЯ подкрепили мою уверенность. Њодель COCOMO Ѓема
признает,  что  качество команды  ЯвлЯетсЯ  важнейшим  фактором  ее  успеха,
практически  вчетверо  более важным,  чем следующий за  ним  по  значимости.
Ѓольшинство научных исследований по программной инженерии сосредоточилось на
инструментах. џ люблю хороший  инструмент и жажду его. ’ем не менее  отрадно
видеть продолжение исследовательских программ в отношении заботы о людЯх, их
роста  и  поддержки,  а также развитиЯ управлениЯ  разработкой  программного
обеспечениЯ.
     <b>—еловеческий  фактор.</b>  Љрупным достижением  последних лет  стала  книга
„емарко  (DeMarco)  и  ‹истера  (Lister)  "—еловеческий фактор: продуктивные
проекты  и  программы", изданнаЯ в 1987  году. ‚ основе ее лежит положение о
том,  что  "главные  проблемы  в нашей  работе  по природе своей не  столько
<i>технологические</i>, сколько <i>социологические</i>". Ћна изобилует такими жемчужинами,
как "задача  менеджера не заставить людей работать, а сделать так, чтобы они
могли работать". ‚ ней говоритсЯ о таких прозаических  вещах, как помещение,
мебель,  совместное  питание  команды. „емарко  и ‹истер  приводЯт  реальные
данные  из   своего  "ЏрограммированиЯ  военных  игр",   которые  показывают
поразительную коррелЯцию между производительностью  программистов из одной и
той же организации, а  также  между характеристиками рабочих мест  и уровнем
продуктивности и наличиЯ ошибок.
     <i>‚  помещениЯх  наиболее  продуктивных  программистов  тише,  они  более
личные, лучше защищены  против непрошеного вторжениЯ, и они просто больше...
Џонимаете ли вы, что покой,  пространство и уединенность способствуют лучшей
работе ваших теперешних  работников  или  (с  другой  стороны)  способствует
привлечению и сохранению лучших работников?</i>18
     џ искренне рекомендую эту книгу всем моим читателЯм.
     <b>Џередача проектов.</b> „емарко и ‹истер уделЯют большое внимание <i>спаЯнности</i>
команды,  неуловимому,  но  важному  качеству.  џ   думаю,  что  непонимание
администрацией спаЯнности  служит причиной той готовности, с  которой, как Я
наблюдал,  в  компаниЯх,  расположенных  на  нескольких  площадках,  проекты
передаютсЯ из одной лаборатории в другую.
     ‚ своей практике Я наблюдал, возможно, с  полдюжины  передач проекта, и
ни одна из  них не была успешной. Њожно  с успехом передавать <i>заданиЯ</i>. Ќо во
всех случаЯх  попытки  передать  проект  новаЯ  команда фактически  начинала
сначала, несмотрЯ  на наличие хорошей документации, некоторого продвижениЯ в
проекте  и некоторых людей из  передающей команды.  џ думаю,  что разрушение
спаЯнности  прежней  команды  приводит  к  выкидышу проекта, находЯщегосЯ  в
эмбриональном состоЯнии, и осуществлению его с начальной точки.
     ‘ила отказатьсЯ от власти
     …сли согласитьсЯ, что, как Я неоднократно доказывал на протЯжении этой
книги, творчество исходит  от  личностей,  а не организационных  структур  и
процессов,  тогда главнаЯ задача  менеджера  программного проекта -  создать
организационную  структуру и рабочий процесс,  способствующий  творчеству  и
инициативе, а не  подавлЯющие  их. Љ счастью, эта проблема присуща не только
программным  организациЯм, и над ней  работали  многие  большие  умы. ….  ”.
умахер (E. F. Schumacher) в классической работе "Њалое прекрасно: экономика
ради  людей"  предлагает  теорию  организации  предприЯтий,  максимизирующую
творческую активность и  радость работников.  ‚ качестве первого принципа он
выдвигает "принцип  вспомогательной  функции" из энциклики Quadragesimo Anno
папы ЏиЯ XI:
     <i>Џередача  большему и вышестоЯщему сообществу  того,  что  могут  делать
меньшие и нижестоЯщие организации ЯвлЯетсЯ несправедливостью и в то же времЯ
серьезным злом и нарушением правильного  порЯдка.  €бо  всЯкаЯ  общественнаЯ
деЯтельность  по  сути  своей должна предоставлЯть помощь членам  социальной
группы, а не  разрушать  и поглощать их... ’ем, кто управлЯет, следует  быть
уверенными,   что   чем   лучше   среди  различных   сообществ   сохранЯетсЯ
дифференцированный порЯдок в соблюдении принципа второстепенной функции, тем
крепче  будет власть  и  эффективность в  обществе,  тем более  счастливым и
процветающим государство.</i>19
     умахер приводит разъЯснение:
     <i>Џринцип  второстепенной  функции  учит нас, что власть и  эффективность
центра увеличатсЯ, если будут тщательно охранЯтьсЯ свобода и ответственность
более  низких формирований,  а  в итоге  организациЯ  в  целом будет  "более
счастливой и процветающей".
     Љак  можно  добитьсЯ  такой организации? ... ЃольшаЯ организациЯ должна
состоЯть  из   множества  полуавтономных   единиц,  которые   можно  назвать
квази-фирмами.  ЉаждаЯ из них должна обладать  значительной  свободой, чтобы
предоставить  наилучшие  возможности  длЯ  творчества  и предприимчивости...
ЉаждаЯ  из  квази- фирм  должна  иметь свой учет прибылей и потерь,  а также
балансовый отчет.</i>20
     Љ   числу  наиболее  замечательных  достижений  программной   инженерии
принадлежат первые этапы практического осуществлениЯ  таких  организационных
идей.  Џрежде всего,  микрокомпьютернаЯ революциЯ создала новую  программную
индустрию с сотнЯми вновь возникших фирм, которые изначально малы и отмечены
энтузиазмом,  свободой  и  творчеством.  ‘ейчас  индустриЯ менЯетсЯ  по мере
поглощениЯ мелких фирм крупными. Џосмотрим, поймут ли крупные фирмы важность
сохранениЯ творческой активности мелких, поглощаемых ими.
     …ще  более примечательно,  что  высшее  руководство рЯда  крупных  фирм
предпринЯло меры по  передаче власти вниз отдельным командам, работающим над
программными  проектами,  что  сближает  их  с  квази-фирмами   умахера  по
структуре и ответственности. ђезультаты вызвали удивление и удовлетворение.
     „жим Њаккарти из Microsoft описывал мне свой опыт эмансипации команд:
     <i>“  каждой  бригады  (30-40 человек)  есть  свой  набор  разрабатываемых
объектов, свой график и даже свои правила разработки, реализации и поставки.
‚  бригаде  есть  специалисты  в  четырех  или пЯти  областЯх, в  том  числе
реализации,  тестировании  и  документировании.   Ѓригада   сама   улаживает
разногласиЯ  по  пустЯкам,  начальник  не вмешиваетсЯ. Ќе  боюсь переоценить
важность   перемещениЯ   власти,   когда   бригада    самостоЯтельно   несет
ответственность за свои достижениЯ.</i>
     ќрл “илер (Earl Wheeler), бывший руководитель  программных  разработок
IBM, поделилсЯ со мной своим опытом  делегированиЯ вниз полномочий, бывших в
течение долгого времени сосредоточенными у администрации управлениЯ IBM.
     <i>Љлючевым порывом последних лет стало делегирование полномочий вниз. ќто
было  чудом!  “лучшились  качество,  продуктивность,  моральный дух.  “  нас
небольшие бригады без централизованного управлениЯ. Ѓригады сами  определЯют
правила производственного процесса,  но они  испытывают  давление со стороны
рынка. € это давление заставлЯет их самих искать способы решениЯ проблем.</i>
     Ћбщение   с  отдельными   членами   бригад  показывает,   конечно,  и
удовлетворение  от передачи  полномочий и свободы, а также более  сдержанную
оценку  того,  в  какой мере контроль действительно ослаблен. ’ем  не менее,
достигнутаЯ степень передачи полномочий ЯвлЯет шаг в правильном направлении.
Џолучаемые  выгода точно те, которые предсказывались  Џием XI:  в результате
делегированиЯ полномочий центр усиливает свою реальную власть, а организациЯ
в целом становитсЯ более счастливой и процветающей.
     Љакой самый большой сюрприз? Њиллионы компьютеров
     ‚се компьютерные гуру,  с которыми  Я разговаривал, признают, что длЯ
них  были  неожиданностью  микрокомпьютернаЯ  революциЯ  и  ее  порождение -
производство  коробочных  программных продуктов.  ‚не  сомнениЯ,  это  самое
значительное  событие  за  два  десЯтилетиЯ  после  выхода  Њ—-Њ.  Ћно имеет
многочисленные последствиЯ длЯ программной инженерии.
     <b>ЊикрокомпьютернаЯ    революциЯ    изменила    характер    использованиЯ
компьютеров.</b> умахер сформулировал проблему более 20 лет назад:
     <i>—его мы действительно хотим  от ученых и технологов?  џ отвечу так: нам
нужны методы и оборудование, которые:</i>
     - <i>достаточно дешевы, чтобы быть доступными практически каждому;</i>
     - <i>пригодны длЯ небольших приложений;</i>
     - <i>соответствуют потребности человека в творческой деЯтельности.</i>21
     ќто  как  раз  те  замечательные  свойства,  которые  микрокомпьютернаЯ
революциЯ  дала  компьютерной  промышленности и  ее  потребителЯм,  которыми
теперь  стала  широкаЯ  публика. ‘редний американец может сегоднЯ  позволить
себе не только собственный компьютер,  но и набор программных  средств,  длЯ
покупки которого 20 лет назад потребовалось бы королевское жалованье. Љаждую
из целей,  поставленных умахером,  стоит рассмотреть отдельно. ЏредставлЯет
также  интерес, в какой мере  они достигнуты -  особенно последнЯЯ.  ‚ одной
области  за другой  обычным  людЯм и профессионалам становЯтсЯ доступны  все
новые средства самовыражениЯ.
     Ћтчасти, развитие в других областЯх происходит так же,  как  в создании
программ - благодарЯ устранению побочных трудностей. Џобочные ограничениЯ на
рукописи   накладывались  длительностью  и  стоимостью  перепечатываниЯ  длЯ
внесениЯ исправлений.  ђаботу  объемом  в  300  страниц  иногда  приходилось
перепечатывать  каждые  три  или  шесть  месЯцев,  а  в перерыве  чиркать  в
рукописи. ’рудно было оценить влиЯние внесенных изменений на общий ход мысли
и ритм слов. ‘ейчас чудесным образом рукописи стали постоЯнно менЯющимисЯ.22
     Ђналогичную  изменчивость компьютер  придал многим  другим  материалам:
картинам  художников,  планам  построек,  чертежам  механизмов,  музыкальным
сочинениЯм, фотографиЯм, кинофильмам, слайдовым презентациЯм, мультимедийным
работам  и  даже электронным таблицам.  ‚ каждом случае при  ручном  способе
изготовлениЯ  длЯ того,  чтобы  увидеть изменениЯ в  контексте,  требовалось
копирование больших неизменных частей. ’еперь,  независимо  от материала, мы
можем пользоватьсЯ такими же  выгодами,  какие  работа  в  режиме разделениЯ
времени принесла в программирование: возможность редактированиЯ и мгновенной
оценки результата без потери хода мысли.
     ’ворческие   возможности  усилились   также  благодарЯ   новым   гибким
вспомогательным инструментам. Ћдин пример - сочинение прозы,  при котором мы
пользуемсЯ  проверкой  орфографии,  грамматики, стилистическими подсказками,
системами  библиографии  и  замечательной  возможностью  одновременно видеть
страницы в  окончательно отформатированном виде. Њы  еще не оценили значениЯ
мгновенного  доступа  к  энциклопедиЯм  и  безграничным  ресурсам  всемирной
паутины длЯ использованиЯ писателем импровизированного поиска.
     ‘амое  главное, обретеннаЯ  изменчивость  материала  упрощает  изучение
многих  в  корне различных  возможностей,  когда  творческаЯ  работа  только
обретает форму. ‚от другой пример, когда  порЯдок величины  в количественном
параметре - в  данном случае, времени, необходимом длЯ внесениЯ изменений, -
производит качественный скачок в подходе к задаче.
     €нструменты  длЯ  черчениЯ  позволЯют  проектировщикам  зданий  за  час
творческой   работы  исследовать   гораздо   больше  вариантов.  Џодключение
компьютеров к синтезаторам и программы, позволЯющие автоматически записывать
или проигрывать ноты, значительно облегчают фиксацию бренчаниЯ по  клавишам.
–ифроваЯ обработка  фотографий, как  в Adobe Photoshop, позволЯет в  течение
считанных минут провести эксперименты, длЯ которых потребовались часы работы
в  фотолаборатории. ќлектронные таблицы  позволЯют легко исследовать десЯтки
альтернативных сценариев типа "что, если".
     Ќаконец,  благодарЯ  вездесущести  персональных  компьютеров  создаетсЯ
совершенно новый материал. ѓипертексты, предложенные ‚анневаром Ѓушем в 1945
году, осуществимы только с помощью компьютеров.23 Њультимедийные презентации
и опыты были  сложнейшими задачами  - слишком много хлопот  -  до того,  как
стало возможным  проводить  их  с  помощью  компьютеров  и  соответствующего
богатого программного обеспечениЯ. ‘истемы виртуальной  реальности, пока еще
дорогие и не  широко распространенные, в будущем  станут  такими и  создадут
новый материал длЯ творчества.
     <b>ЊикрокомпьютернаЯ революциЯ изменила характер  разработки  программного
обеспечениЯ.</b>  ’ехнологии  разработки  программного  обеспечениЯ  1970-х сами
изменились  в  результате  микрокомпьютерной   революции  и   вызвавших   ее
технических   достижений.  “странена   значительнаЯ   часть   второстепенных
сложностей   технологий   разработки   программного   обеспечениЯ.   Ѓыстрые
персональные  компьютеры  стали обычным  инструментом разработчика, и  времЯ
оборачиваемости стало  почти устаревшим понЯтием.  ‘егоднЯшний  персональный
компьютер быстрее  не только  суперкомпьютера  60-го года, но и Unix-станции
1985-го.  ќто  значит, что компилЯциЯ быстро осуществлЯетсЯ даже на скромных
по мощности машинах, а благодарЯ большому  объему памЯти отпали задержки при
компоновке с использованием дисков. ЃольшаЯ памЯть позволЯет также хранить в
памЯти  таблицы  символических имен  вместе с объектным кодом, в  результате
чего становитсЯ обычной высокоуровневаЯ отладка без перекомпилЯции.
     ‡а  последние  20  лет мы почти покончили  с  использованием разделениЯ
времени как методологией  разработки программного  обеспечениЯ. ‚ 1975  году
разделение времени  только-только вытеснило пакетную  обработку  в  качестве
наиболее  распространенной  технологии. ‘еть использовалась длЯ  того, чтобы
дать разработчику программного обеспечениЯ доступ как  к общим файлам, так и
к   большим  вычислительным   мощностЯм   длЯ   компилЯции,   компоновки   и
тестированиЯ.  ‘егоднЯ  вычислительную  мощность  обеспечивает  персональнаЯ
рабочаЯ станциЯ,  а сеть используетсЯ в основном длЯ обеспечениЯ совместного
доступа к файлам бригады,  разрабатывающей продукт. Љлиент-серверные системы
менЯют  и  упрощают   технологию  общего  доступа  длЯ  загрузки,  сборки  и
выполнениЯ контрольных примеров.
     ‘ходный прогресс произошел с  пользовательскими интерфейсами. €нтерфейс
WIMP  обеспечивает  гораздо  большие  удобства  при  редактировании  текстов
программ  и текстов на естественном  Языке.  ќкран размером  24 строки на 72
колонки  сменилсЯ  полностраничным или даже двухстраничным  экраном, поэтому
программисты могут видеть изменениЯ, которые они делают, в значительно более
широком контексте.
     –елаЯ новаЯ программнаЯ отрасль - коробочные пакеты
     ђЯдом с классической индустрией программных продуктов широко развилась
еще  одна. Џродажи  программных  продуктов  числЯтсЯ  сотнЯми  тысЯч и  даже
миллионами.  –елые  мощные  пакеты  можно  приобрести  по цене  меньшей, чем
стоимость оплаты одного рабочего днЯ программиста. ќти две отрасли во многом
различны и существуют параллельно.
     <b>ЉлассическаЯ программнаЯ индустриЯ.</b> ‚  1975  году программнаЯ индустриЯ
имела несколько отдельных и до некоторой степени различных составных частей,
существующих по сей день:
     - Џроизводители компьютеров, поставлЯющие также  операционные  системы,
компилЯторы и утилиты длЯ своих продуктов.
     -  Џользователи   приложений,  например,  в   информационно-управлЯющих
системах,  банках,   страховых   компаниЯх,  правительственных  учреждениЯх,
создающие пакеты программ длЯ собственного употреблениЯ.
     -   ђазработчики   заказных   программ,  работающие   по   контракту  с
пользователем.  Њногие из этих  подрЯдчиков специализируютсЯ  на приложениЯх
длЯ военной сферы, где требованиЯ, стандарты и маркетинговые процедуры носЯт
специфический характер.
     -  ђазработчики  коммерческих пакетов, в  то  времЯ  разрабатывавшие, в
основном,  большие  приложениЯ длЯ  специфических рынков,  такие  как пакеты
статистического анализа и автоматического проектированиЯ.
     ’ом  „емарко отмечает  фрагментацию  классической  индустрии разработки
программного обеспечениЯ, особенно в части пользователей приложений:
     <i>џ  не  ожидал,  что эта  область распадетсЯ на отдельные  ниши.  Џриемы
работы  в  большей степени  определЯютсЯ  нишей,  чем  использованием  общих
методов анализа  систем,  Языков программированиЯ и технологий тестированиЯ.
Ada был последним из Языков общего назначениЯ, и он стал Языков ниши.</i>
     ‚  нише  обычных  коммерческих  приложений  значительный вклад сделан
Языками четвертого поколениЯ (4GL). Ѓем пишет, что "наиболее удачные из  4GL
Явились результатом написаниЯ какой-либо части области  приложений на  Языке
опций и параметров". Ќаиболее широко распространенными  из этих 4GL ЯвлЯютсЯ
генераторы приложений и  комбинированные пакеты баз данных и свЯзи с Языками
запросов.
     <b>Њиры  операционных  систем  объединились.</b>  ‚  1975  году  было  изобили
операционных систем - у каждого производителЯ компьютеров  была, по  крайней
мере, одна патентованнаЯ  операционнаЯ система длЯ  каждой  производственной
серии, а часто и две. Ќасколько  изменилось положение сегоднЯ! ‹озунгом  днЯ
стали открытые системы, и осталось лишь  пЯть главных операционных сред, длЯ
которых создаютсЯ пакеты приложений (в хронологическом порЯдке):
     - IBM MVS и VM
     - DEC VMS
     - Unix в том или ином варианте
     - IBM PC, будь то DOS, OS/2 или Windows
     - Apple Macintosh.
     <b>€ндустриЯ коробочных  продуктов.</b> ќкономические законы длЯ разработчиков
в этой  отрасли совершенно отличны от тех, которые  действуют в классической
индустрии:   стоимость   разработки  нужно  делить  на  большое   количество
экземплЯров,  расходы  на  упаковку  и   маркетинг  высоки.  ‚  классической
индустрии при внутрифирменной разработке  график работ и набор функций могли
быть изменены, в отличие от стоимости разработки. Ќа открытом  рынке жесткой
конкуренции сроки и функциональность полностью доминируют над  затратами  на
разработку.
     Љак  и  следовало ожидать,  столь  различные  экономические  требованиЯ
породили  весьма  различающиесЯ культуры  программированиЯ.  ‚  классической
индустрии  лидирующее  положение  занЯли  крупные  фирмы  с  установившимисЯ
стилЯми  управлениЯ  и культурой  работы.  ‚ коробочной индустрии, напротив,
возникли  сотни начинающих  фирм, ничем не  свЯзанных  и сосредоточенных  на
конечной  цели,  а не  на  процессе.  ‚  такой атмосфере  талант  отдельного
программиста  всегда  ценитсЯ  значительно  выше,  и  существует  подспуд