тающий прототип как можно скорее, чтобы начать исследование
вариантов проекта и способов реализации.
      ’акой подход, если применЯть его разумно, может привести к
успеху. Ќо он также может служить оправданием неудачно сделанных
систем. „ело в том, что уделЯЯ особое внимание прототипу, можно
прийти к смещению усилий от "исследование вариантов
проекта" к "получение как можно скорее рабочей версии системы".
’огда быстро угаснет интерес к внутренней структуре прототипа
("ведь это только прототип"), а работа по проектированию будет
вытеснЯтьсЯ манипулированием с реализацией прототипа.  Џросчет
заключаетсЯ в том, что такаЯ реализациЯ может легко привести к системе,
котораЯ имеет вид "почти законченной", а по сути ЯвлЯетсЯ пожирателем
ресурсов и кошмаром длЯ тех, кто ее сопровождает. ‚ этом
случае на прототип тратЯтсЯ времЯ и энергиЯ, которые лучше приберечь
длЯ реальной системы. „лЯ разработчиков и менеджеров есть искушение
переделать прототип в конечный программный продукт, а "искусство
настройки системы" отложить до выпуска следующей версии. …сли идти
таким путем, то прототипы отрицают все основы проектированиЯ.
     ‘ходнаЯ проблема возникает, если исследователи привЯзываютсЯ
к тем средствам, которые они создали при построении прототипа,
и забывают, что они могут оказатьсЯ непригодными длЯ
рабочей системы, и что свобода от ограничений и формальностей, к
которой они привыкли, работаЯ в небольшой группе, может оказатьсЯ
невозможной в большом коллективе, бьющимсЯ над устранением длинной
цепи препЯтствий.
      € в то же времЯ создание прототипов может сыграть важную роль.
ђассмотрим, например, проектирование пользовательского интерфейса. „лЯ
этой задачи внутреннЯЯ структура той части системы, котораЯ прЯмо не
общаетсЯ с пользователем, обычно не важна, и использование прототипов -
это единственный способ узнать,
какова будет реакциЯ пользователЯ при работе с системой.
„ругим примером служат прототипы, прЯмо предназначенные длЯ изучениЯ
внутренней структуры системы. ‡десь уже интерфейс с пользователем
может быть примитивным, возможна работа с моделью пользователей.
    €спользование прототипов - это способ экспериментированиЯ.
Ћжидаемый результат - это более глубокое понимание целей, а не
сам прототип. ‚озможно, сущность прототипа заключаетсЯ в том,
что он ЯвлЯетсЯ настолько неполным, что может служить лишь средством
длЯ эксперимента, и его нельзЯ превратить в конечный продукт без
больших затрат на перепроектирование и на другую реализацию. ЋставлЯЯ
прототип "неполным", мы тем самым переключаем внимание на
эксперимент и уменьшаем опасность превращениЯ прототипа в законченный
продукт. ќто также почти избавлЯет от искушениЯ взЯть за основу
проекта системы проект прототипа, при этом забываЯ или игнорируЯ те
ограничениЯ, которые внутренне присущи прототипу. Џосле эксперимента
прототип надо просто выбросить.
    Ќе следует забывать о других способах проведениЯ эксперимента,
которые могут служить во многих случаЯх альтернативой созданию прототипа,
и там, где они применимы, их использование предпочтительнее, поскольку
они обладают большей точностью и требуют меньших затрат
времени разработчика и ресурсов системы. Џримерами могут служить
математические модели и различные формы моделированиЯ. Џо сути,
существует бесконечнаЯ возрастающаЯ последовательность,
начинаЯ от математических моделей,
ко все более и более детальным способам моделированиЯ, затем к
прототипам, к частичным реализациЯм системы, вплоть до полной системы.
    ќто подводит к идее построениЯ системы, исходЯ из начального
проекта и реализации, и двигаЯсь путем повторного прохождениЯ
этапов проектированиЯ и реализации. ќто идеальнаЯ стратегиЯ,
но она предъЯвлЯет высокие требованиЯ к средствам проектированиЯ
и реализации, и в ней содержитсЯ определенный риск того, что
программный объем, реализующий решениЯ, принЯтые
при начальном проектировании, в процессе развитиЯ вырастет до такой
величины, что существенное улучшение проекта будет просто невозможно.
    Џохоже, что по крайней мере теперь такую стратегию применЯют
или в проектах от малого до среднего размеров, т.е. там, где
маловероЯтны переделки общего проекта, или же длЯ перепроектированиЯ
и иной реализации после выдачи первоначальной версии системы, где
указаннаЯ стратегиЯ становитсЯ неизбежной.
    Џомимо экспериментов, предназначенных длЯ оценки решений,
принимаемых на этапе проектированиЯ, источником получениЯ полезной
информации может быть анализ собственно проектированиЯ и (или)
реализации. Ќапример, может оказатьсЯ полезным изучение различных
зависимостей между классами (см.$$ 12.2), не следует забывать и о
таких традиционных вспомогательных средствах реализации, как
граф вызовов функций, оценка производительности и т.п.
    ‡аметим, что спецификациЯ (результат анализа системы) и проект
могут содержать ошибки, как и реализациЯ, и возможно, они даже
больше подвержены ошибкам, т.к. ЯвлЯютсЯ менее точными, не могут быть
проверены на практике и обычно не окружены такими развитыми средствами,
как те, что служат длЯ анализа и проверки реализации. ‚ведение
большей формализации в Язык или запись, с помощью которой изложен проект,
в какой-то степени облегчает использованиЯ этих средств длЯ
проектированиЯ. Ќо, как сказано в $$12.1.1, это нельзЯ делать
за счет ухудшениЯ Языка, используемого длЯ реализации. Љ тому
же формальнаЯ запись может сама стать источником трудностей и
проблем. ќто происходит, когда выбраннаЯ степень формализации плохо
подходит длЯ конкретных задач, когда строгость формализации превосходит
математическую основу системы и квалификацию разработчиков и
программистов, и когда формальное описание системы начинает
расходитьсЯ с реальной системой, длЯ которой оно предназначалось.
     ‡аключение о необходимости опыта и о том, что проектирование
неизбежно сопровождаетсЯ ошибками и плохо поддержано программными
средствами, служит основным доводом в пользу итеративной модели
проектированиЯ и реализации. Ђльтернатива - это линейнаЯ модель
процесса развитиЯ, начинаЯ с анализа и кончаЯ тестированием, но
она существенно дефектна, поскольку не допускает повторных
проходов, исходЯ из опыта, полученного на различных этапах развитиЯ
системы.


        11.3.5 ’естирование

Џрограмма, котораЯ не прошла тестирование, не работает. €деал, чтобы
после проектированиЯ и (или) верификации программа заработала с
первого раза, недостижим длЯ всех, за исключением самых тривиальных
программ. ‘ледует стремитьсЯ к идеалу, но не заблуждатьсЯ, что
тестирование простое дело.
      "Љак проводить тестирование?" - на этот вопрос нельзЯ ответить
в общем случае. Ћднако, вопрос "Љогда начинать тестирование?" имеет
такой ответ - на самом раннем этапе, где это возможно. ‘тратегиЯ
тестированиЯ должна быть разработана как часть проекта и включена
в реализацию, или, по крайней мере, разрабатыватьсЯ параллельно
с ними. Љак только поЯвлЯетсЯ работающаЯ система, надо начинать
тестирование. Ћткладывание тестированиЯ до "проведениЯ полной
реализации" - верный способ выйти из графика или передать версию
с ошибками.
     ‚сюду, где это возможно, проектирование должно вестись так,
чтобы тестировать систему было достаточно просто. ‚ частности,
имеет смысл средства тестированиЯ прЯмо встраивать в систему.
€ногда это не делаетсЯ из-за боЯзни слишком объемных проверок на
стадии выполнениЯ, или из-за опасений, что избыточность, необходимаЯ
длЯ полного тестированиЯ, излишне усложнит структуры данных.
Ћбычно такие опасениЯ неоправданы, поскольку собственно программы
проверки и дополнительные конструкции, необходимые длЯ них,
можно при необходимости удалить из системы перед ее поставкой
пользователю. €ногда могут пригодитсЯ утверждениЯ о свойствах
программы (см. $$12.2.7).
    Ѓолее важной, чем набор тестов, ЯвлЯетсЯ подход, когда
структура системы такова, что есть реальные шансы убедить себЯ
и пользователей, что ошибки можно исключить с помощью определенного
набора статических проверок, статического анализа и тестированиЯ.
…сли разработана стратегиЯ построениЯ системы, устойчивой к ошибкам
(см.$$9.8), стратегиЯ тестированиЯ обычно разрабатываетсЯ как
вспомогательнаЯ.
    …сли вопросы тестированиЯ полностью игнорируютсЯ на этапе
проектированиЯ, возникнут проблемы с тестированием, временем
поставки и сопровождением системы. ‹учше всего начать работать
над стратегией тестированиЯ с интерфейсов классов и их
взаимозависимостей (как предлагаетсЯ в $$12.2 и $$12.4).
    ’рудно определить необходимый объем тестированиЯ. Ћднако,
очевидно, что проблему представлЯет недостаток тестированиЯ,
а не его избыток. ‘колько именно ресурсов в сравнении с проектированием
и реализацией следует отвести длЯ тестированиЯ зависит от
природы системы и методов ее построениЯ. Ћднако, можно предложить
следующее правило: отводить больше ресурсов времени и человеческих
усилий на тестирование системы, чем на получениЯ ее первой реализации.

        11.3.6 ‘опровождение

"‘опровождение программного обеспечениЯ" - неудачный термин. ‘лово
"сопровождение" предлагает неверную аналогию с аппаратурой. Џрограммы
не требуют смазки, не имеют движущихсЯ частей, которые изнашиваютсЯ
так, что требуют замены, у них нет трещин, в которые попадает
вода, вызываЯ ржавчину. Џрограммы можно воспроизводить в точности
и передавать в течении минуты на длинные расстоЯниЯ. Љороче,
программы это совсем не то, что аппаратура. (‚ оригинале:
"Software is not hardware").
    „еЯтельность, котораЯ обозначаетсЯ, как сопровождение программ,
на самом деле, состоит из перепроектированиЯ и повторной реализации,
а значит входит в обычный цикл развитиЯ программного обеспечениЯ.
…сли в проекте учтены вопросы расширЯемости, гибкости и переносимости,
то обычные задачи сопровождениЯ решаютсЯ естественным образом.
    Џодобно тестированию задачи сопровождениЯ не должны решатьсЯ
вне основного направлениЯ развитиЯ проекта и их не следует откладывать
на потом.

        11.3.7 ќффективность

„. Љнуту принадлежит утверждение "ЌепродуманнаЯ оптимизациЯ - корень
всех бед". Ќекоторые слишком хорошо убедились в справедливости этого
и считают вредными все заботы об оптимизации. Ќа самом деле вопросы
эффективности надо все времЯ иметь в виду во времЯ проектированиЯ и
реализации. ќто не означает, что разработчик должен заниматьсЯ
задачами локальной оптимизации, только задача оптимизации на самом
глобальном уровне должна его волновать.
    ‹учший способ добитьсЯ эффективности - это создать Ясный и
простой проект. ’олько такой проект может остатьсЯ относительно
устойчивым на весь период развитиЯ и послужить основой длЯ
настройки системы с целью повышениЯ производительности. ‡десь
важно избежать "гаргантюализма", который ЯвлЯетсЯ проклЯтием
больших проектов. ‘лишком часто люди добавлЯют определенные
возможности системы "на всЯкий случай" (см. $$11.3.3.2 и $$11.4.3),
удваиваЯ, учетверЯЯ размер выполнЯемой программы ради завитушек.
…ще хуже то, что такие усложненные системы трудно поддаютсЯ
анализу, а по этому трудно отличить избыточные накладные расходы
от необходимых и провести анализ и оптимизации на общем уровне.
ЋптимизациЯ должна быть результатом анализа и оценки производительности
системы, а не произвольным манипулированием с программным кодом,
причем это особенно справедливо длЯ больших систем, где интуициЯ
разработчика или программиста не может служить надежным указателем
в вопросах эффективности.
       ‚ажно избегать по сути неэффективных конструкций, а так же
таких конструкций, которые можно довести до приемлемого уровнЯ
выполнениЯ, только затратив массу времени и усилий. Џо этой же
причине важно свести к минимуму использование непереносимых по
своей сути конструкций и средств, поскольку их наличие препЯтствует
работе системы на других машинах (менее мощных, менее дорогих).

        11.4 “правление проектом

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

њ ЋрганизациЯ, в которой считают своих программистов недоумками,
очень скоро получит программистов, которые будут рады и способны
действовать только как недоумки.

Ћтсюда следует, что менеджер должен поощрЯть такие структуры,
которые соответствуют сформулированным целЯм проекта и реализации.
Ћднако на практике слишком часто бывает иначе. ‘ущественное
изменение стилЯ программированиЯ достижимо только при соответствующем
изменении в стиле проектированиЯ, кроме того, обычно и то и другое
требует изменениЯ в стиле управлениЯ. ЊыслительнаЯ и организационнаЯ
инерциЯ слишком просто сводЯт все к локальным изменениЯм, хотЯ
только глобальные изменениЯ могут принести успех. Џрекрасной
иллюстрацией служит переход на Язык с объектно-ориентированным
программированием, например на ‘++, когда он не влечет за собой
соответствующих изменений в методах проектированиЯ, чтобы
воспользоватьсЯ новыми возможностЯми Языка (см. $$12.1), и, наоборот,
когда переход на "объектно-ориентированное проектирование" не
сопровождаетсЯ переход на Язык реализации, который поддерживает
этот стиль.

        11.4.1 Џовторное использование

—асто основной причиной перехода на новый Язык или новый метод
проектированиЯ называют то, что это облегчает повторное использование
программ или проекта. Ћднако, во многих организациЯх поощрЯют
сотрудника или группу, когда они предпочитают изобретать колесо.
Ќапример, если производительность программиста измерЯетсЯ числом
строк программы, то будет ли он писать маленькие программы,
работающие со стандартными библиотеками, за счет своего дохода
и, может быть, положениЯ? Ђ менеджер, если он оплачиваетсЯ
пропорционально числу людей в его группе, будет ли он использовать
программы, сделанные другими коллективами, если он может просто
нанЯть еще пару программистов в свою группу? ЉомпаниЯ может
получить правительственный контракт, в котором ее доход составлЯет
фиксированный процент от расходов на проект, будет ли она
сокращать свой доход за счет использованиЯ наиболее эффективных
средств? ’рудно обеспечить вознаграждение за повторное использование,
но если администрациЯ не найдет способов поощрениЯ и вознаграждениЯ,
то его просто не будет.
      Џовторное использование ЯвлЯетсЯ прежде всего социальным
фактором. Џовторное использование программы возможно при условии,
что
   [1] она работает; нельзЯ использовать повторно, если это невозможно
       и в первый раз;
   [2] она понЯтна; здесь имеет значение структура программы, наличие
       комментариев, документации, руководства;
   [3] она может работать вместе с программами, которые не создавались
       специально с таким условием;
   [4] можно рассчитывать на ее сопровождение (или придетсЯ делать
       это самому, что обычно не хочетсЯ);
   [5] это выгодно (хотЯ можно и разделить расходы по разработке
       и сопровождению с другими пользователЯми) и, наконец;
   [6] ее можно найти.
Љ этому можно еще добавить, что компонент не ЯвлЯетсЯ повторно
используемым, пока кто-то действительно не сделал это. Ћбычно задача
приспособлениЯ компонента к существующему окружению приводит к
уточнению набора операций, обобщению его поведениЯ, и повышению его
способности адаптации к другим программам. Џока все это не проделано
хотЯ бы один раз, неожиданные острые углы находЯтсЯ даже у
компонентов, которые тщательно проектировались и реализовывались.
      ‹ичный опыт подсказывает, что условиЯ длЯ повторного
использованиЯ возникают только в том случае, когда находитсЯ
конкретный человек, занЯтый этим вопросом. ‚ маленьких группах
это обычно бывает тот, кто случайно или запланированно оказываетсЯ
хранителем общих библиотек или документации. ‚ больших организациЯх
это бывает группа или отдел, которые получают привилегию собирать,
документировать, популЯризировать и сопровождать программное
обеспечение, используемое различными группами.
      ЌельзЯ недооценивать такие группы "стандартных компонентов".
“кажем, что в первом приближении, система отражает организацию,
котораЯ ее создала. …сли в организации нет средств поощрениЯ и
вознаграждениЯ кооперации и разделениЯ труда, то и на практике
они будут исключением. ѓруппа стандартных компонентов должна
активно предлагать свои компоненты. ЋбычнаЯ традиционнаЯ
документациЯ важна, но ее недостаточно. Џомимо этого указаннаЯ
группа должна предоставлЯть руководства и другую информацию,
котораЯ позволит потенциальному пользователю отыскать компонент и
понЯть как он может ему помочь. ‡начит эта группа должна предпринимать
действиЯ, которые обычно свЯзываютсЯ с системой образованиЯ и
маркетинга. —лены группы компонентов должны всегда, когда это
возможно, работать в тесном сотрудничестве с разработчиками из
областей приложениЯ. ’олько тогда они будут в курсе запросов
пользователей и сумеют почуЯть возможности использованиЯ
стандартного компонента в различных областЯх. ќто ЯвлЯетсЯ
аргументом за использование такой группы в роли консультанта и в
пользу внутренних поставок программ, чтобы информациЯ из группы
компонентов могла свободно распространЯтьсЯ.
      ‡аметим, что не все программы должны быть рассчитаны на
повторное использование, иными словами, повторное использование не
ЯвлЯетсЯ универсальным свойством. ‘казать, что некоторый компонент
может быть повторно использован, означает, что в рамках определенной
структуры его повторное использование не потребует значительных
усилий. Ќо в большинстве случаев перенос в другую структуру может
потребовать большой работы. ‚ этом смысле повторное использование
сильно напоминает переносимость. ‚ажно понимать, что повторное
использование ЯвлЯетсЯ результатом проектированиЯ, ставившего
такую цель, модификации компонентов на основе опыта и специальных
усилий, предпринЯтых длЯ поиска среди существующих компонентов
кандидатов на повторное использование. Ќеосознанное использование
средств Языка или приемов программированиЯ не может чудесным
образом гарантировать повторное использование. ’акие средства Языка
‘++, как классы, виртуальные функции и шаблоны типа, способствуют
проектированию, облегчающему повторное использование (значит делают
его более вероЯтным), но сами по себе эти средства не гарантируют
повторное использование.

        11.4.2 ђазмер

—еловек и организациЯ склонны излишне радоватьсЯ тому, что они
"действуют по правильной методе". ‚ институтской среде это часто
звучит как "развитие согласно строгим предписаниЯм". ‚ обоих случаЯх
здравый смысл становитсЯ первой жертвой страстного и часто искреннего
желаниЯ внести улучшениЯ. Љ несчастью, если здравого смысла не хватает,
то ущерб, нанесенный неразумными действиЯми, может быть неограниченным.
    ‚ернемсЯ к этапам процесса развитиЯ, перечисленным в $$11.3, и
к шагам проектированиЯ, указанным в $$11.3.3. Ћтносительно просто
переработать эти этапы в точный метод проектированиЯ, когда шаг точно
определен, имеет хорошо определенные входные и выходные данные и
полуформальную запись длЯ заданиЯ входных и выходных данных. Њожно
составить протокол, которому должно подчинЯтьсЯ проектирование,
создать средства, предоставлЯющие определенные удобства длЯ записи
и организации процесса. „алее, исследуЯ классификацию зависимостей,
приведенную в $$12.2, можно постановить, что определенные зависимости
ЯвлЯютсЯ хорошими, а другие следует считать плохими, и предоставить
средства анализа, которые обеспечат проведение таких оценок во всех
стадиЯх проекта. —тобы завершить такую "стандартизацию" процесса
созданиЯ программ, можно было бы ввести стандарты на документацию
(в том числе правила на правописание и грамматику и соглашениЯ о
формате документации), а так же стандарты на общий вид программ
(в том числе указаниЯ какие средства Языка следует использовать,
а какие нет, перечисление допустимых библиотек и тех, которые не нужно
использовать, соглашениЯ об именовании функций, типов, переменных,
правила расположениЯ текста программы и т.д.).
     ‚се это может способствовать успеху проекта. Џо крайней мере,
было бы Явной глупостью, братьсЯ за проект системы, котораЯ
предположительно будет иметь порЯдка десЯти миллионов строк текста,
над которой будут работать сотни человек, и которую будут
сопровождать тысЯчи человек в течении десЯтилетий, не имеЯ достаточно
хорошо определенного и строгого плана по всем перечисленным выше
позициЯм.
    Љ счастью, большинство систем не относитсЯ к этой категории.
’ем не менее, если решено, что данный метод проектированиЯ или
следование указанным образцам в программировании и документации
ЯвлЯютсЯ "правильными", то начинает оказыватьсЯ давление, чтобы
применЯть их повсеместно. ‚ небольших проектах это приводит к
нелепым ограничениЯм и большим накладным расходам. ‚ частности,
это может привести к тому, что мерой развитиЯ и успеха становитсЯ
не продуктивнаЯ работа, а пересылка бумажек и заполнение различных
бланков. …сли это случитсЯ, то в таком проекте настоЯщих
программистов и разработчиков вытеснЯт бюрократы.
    Љогда происходит такое нелепое злоупотребление методами
проектированиЯ (по всей видимости совершенно разумными), то неудача
проекта становитсЯ оправданием отказа от практически всЯкой
формализации процесса разработки программного обеспечениЯ. ќто,
в свою очередь, ведет к такой путанице и таким провалам, которые
как раз и должен был предотвратить надлежащий метод проектированиЯ.
    ЋсновнаЯ проблема состоит в определении степени формализации,
пригодной длЯ процесса развитиЯ конкретного проекта. Ќе рассчитывайте
легко найти ее решение. Џо сути длЯ малого проекта каждый метод
может сработать. …ще хуже то, что похоже практически каждый метод,
даже если он плохо продуман и жесток по отношению к исполнителЯм,
может сработать длЯ большого проекта, если вы готовы затратить
уйму времени и денег.
    ‚ процессе развитиЯ программного обеспечениЯ главнаЯ задача -
сохранить целостность проекта. ’рудность этой задачи зависит
нелинейно от размера проекта. ‘формулировать и сохранить основные
установки в большом проекте может только один человек или маленькаЯ
группа. Ѓольшинство людей тратит столько времени на решение
подзадач, технические детали, повседневную административную работу,
что общие цели проекта легко забывает или заменЯет их на более
локальные и близкие цели. ‚ерный путь к неудаче, когда нет человека
или группы с прЯмым заданием следить за целостностью проекта.
‚ерный путь к неудаче, когда у такого человека или группы нет
средств воздействовать на проект в целом.
    Ћтсутствие согласованных дальних целей намного более опасно
длЯ проекта и организации, чем отсутствие какого-либо одного
конкретного свойства. ЌебольшаЯ группа людей должна сформулировать
такие общие цели, постоЯнно держать их в уме, составить документы,
содержащие самое общее описание проекта, составить поЯснениЯ к
основным понЯтиЯм, и вообще, помогать всем остальным помнить о
назначении проекта.

        11.4.3 —еловеческий фактор

Ћписанный здесь метод проектированиЯ рассчитан на искусных
разработчиков и программистов, поэтому от их подбора зависит
успех организации.
    Њенеджеры часто забывают, что организациЯ состоит из
индивидуумов. ђаспространено мнение, что программисты равны и
взаимозаменЯемы. ќто заблуждение может погубить организацию за счет
вытеснениЯ многих самых активных сотрудников и принуждениЯ
остальных работать над задачами значительно ниже их уровнЯ.
€ндивидуумы взаимозаменЯемы только, если им не дают применить
свой талант, который поднимает их над общим минимальным уровнем,
необходимым длЯ решениЯ данной задачи. Џоэтому миф о взаимозаменЯемости
бесчеловечен и по сути своей расточителен.
   Њногие системы оценок производительности программиста поощрЯют
расточительность и не могут учесть существенный личный вклад
человека. ‘амым очевидным примером служит широко распространеннаЯ
практика оценивать успех в количестве запрограммированных строк,
выданных страниц документации, пропущенных тестов и т.п.
’акие цифры эффектно выглЯдЯт на диаграммах, но имеют самое
отдаленное отношение к действительности. Ќапример, если
производительность измерЯть числом запрограммированных строк, то
удачное повторное использование ухудшит оценку труда программиста.
Ћбычно тот же эффект будет иметь удачное применение лучших приемов
в процессе перепроектированиЯ большой части системы.
    Љачество результата измерить значительно труднее, чем количество,
и  вознаграждать исполнителЯ или группу следует за качество их труда,
а не на основе грубых количественных оценок. Љ сожалению, насколько
известно, практическаЯ разработка способов оценки качества еще не
началась. Љ тому же оценки, которые неполно описывают состоЯние
проекта, могут исказить процесс его развитиЯ. ‹юди приспосабливаютсЯ,
чтобы уложитьсЯ в отведенный срок и перестраивают свою работу в
соответствии с оценками производительности, в результате страдает
общаЯ целостность системы и ее производительность. Ќапример, если
отведен срок длЯ выЯвлениЯ определенного числа ошибок, то длЯ того,
чтобы уложитьсЯ в него, активно используют проверки на стадии
выполнениЯ, что ухудшает производительность системы. Ћбратно, если
учитываютсЯ только характеристики системы на стадии выполнениЯ, то
число невыЯвленных ошибок будет расти при условии недостатка
времени у исполнителей. Ћтсутствие хороших и разумных оценок
качества повышает требованиЯ к технической квалификации менеджеров,
иначе будет постоЯннаЯ тенденциЯ поощрЯть произвольную активность,
а не реальный прогресс. Ќе надо забывать, что менеджеры тоже люди,
и они должны по крайней мере настолько разбиратьсЯ в новых
технологиЯх, как и те, кем они управлЯют.
    ‡десь, как и в других аспектах процесса развитиЯ программного
обеспечениЯ, следует рассматривать большие временные сроки. Џо сути
невозможно указать производительность человека на основе его
работы за год. Ћднако, многие сотрудники имеют карточку своих
достижений за большой период, и она может послужить надежным указанием
длЯ предсказаниЯ их производительности. …сли не принимать во внимание
такие карточки, что и делаетсЯ, когда сотрудников считают
взаимозаменЯемыми спицами в колесе организации, то у менеджера
остаютсЯ только вводЯщие в заблуждениЯ количественные оценки.
     …сли мы рассматриваем только достаточно большие временные
сроки и отказываемсЯ от методов управлениЯ, рассчитанных на
"взаимозаменЯемых недоумков", то надо признать, что индивидууму
(как разработчику или программисту, так и менеджеру) нужен большой
срок, чтобы дорасти до более интересной и важной работы. ’акой
подход не одобрЯет как "скакание" с места на место, так и передачу
работы другому из-за карьерных соображений. –елью должен быть
низкий оборот ключевых специалистов и ключевых менеджеров. Ќикакой
менеджер не добьетсЯ успеха без подходЯщих технических знаний и
взаимопониманиЯ с основными разработчиками и программистами.
‚ тоже времЯ, в конечном счете никакаЯ группа разработчиков или
программистов не добьетсЯ успеха без поддержки компетентных
менеджеров и без пониманиЯ хотЯ бы основных нетехнических вопросов,
касающихсЯ окружениЯ, в котором они работают.
    Љогда требуетсЯ предложить нечто новое, на передний план выходЯт
основные специалисты - аналитики, разработчики, программисты. €менно
они должны решить трудную и критическую задачу внедрениЯ новой
технологии. ќто те люди, которые должны овладеть новыми методами и
во многих случаЯх забыть старые привычки. ќто не так легко. ‚едь
эти люди сделали большой личный вклад в создание старых методов и
свою репутацию как специалиста обосновывают успехами, полученными с
помощью старых методов. ’ак же обстоит дело и с многими менеджерами.
     …стественно у таких людей есть страх перед изменениЯми. Ћн может
привести к преувеличению проблем, возникающих при изменениЯх, и к
нежеланию признать проблемы, вызванные старыми методами. …стественно,
с другой стороны люди, выступающие за изменениЯ, могут переоценивать
выгоды, которые принесут изменениЯ, и недооценивать возникающие
здесь проблемы. ќти две группы людей должны общатьсЯ, они должны
научитьсЯ говорить на одном Языке и должны помочь друг другу
разработать подходЯщую схему перехода. Ђльтернативой будет
организационный паралич и уход самых способных людей из обоих групп.
’ем и другим следует знать, что самые удачливые из "старых ворчунов"
могли быть "молодыми львами" в прошлом году, и если человеку дали
возможность научитьсЯ без всЯких издевательств, то он может стать
самым стойким и разумным сторонником перемен. Ћн будет обладать
неоценимыми свойствами здорового скептицизма, знаниЯ пользователей
и пониманиЯ организационных препЯтствий. ‘торонники немедленных и
радикальных изменений должны осознать, что гораздо чаще  нужен
переход, предполагающий постепенное внедрение новых методов.
‘ другой стороны, те, кто не желает перемен, должны поискать длЯ
себЯ такие области, где это возможно, чем вести ожесточенные,
арьергардные бои в той области, где новые требованиЯ уже задали
совершенно иные условиЯ длЯ успешного проекта.

        11.5 ‘вод правил

‚ этой главе мы затронули много тем, но как правило не давали
настоЯтельных и конкретных рекомендаций по проектированию. ќто
соответствует моему убеждению, что нет "единственно верного решениЯ".
Џринципы и приемы следует применЯть тем способом, который лучше
подходит длЯ конкретных задач. „лЯ этого нужен вкус, опыт и разум.
‚се-таки можно указать некоторый свод правил, который разработчик
может использовать в качестве ориентиров, пока не наберетсЯ достаточно
опыта, чтобы выработать лучшие. Ќиже приведен свод таких правил.
     ќти правила можно использовать в качестве отправной точки в
процессе выработки основных направлений длЯ проекта или организации
или в качестве проверочного списка. Џодчеркну еще раз, что они не
ЯвлЯютсЯ универсальными правилами и не могут заменить размышлениЯ.
   - “знайте, что вам предстоит создать.
   - ‘тавьте определенные и осЯзаемые цели.
   - Ќе пытайтесь с помощью технических приемов решить социальные
     проблемы.
   - ђассчитывайте на большой срок
     - в проектировании, и
     - управлении людьми.
   - €спользуйте существующие системы в качестве моделей, источника
     вдохновениЯ и отправной точки.
   - Џроектируйте в расчете на изменениЯ:
     - гибкость,
     - расширЯемость,
     - переносимость, и
     - повторное использование.
   - „окументируйте, предлагайте и поддерживайте повторно используемые
     компоненты.
   - ЏоощрЯйте и вознаграждайте повторное использование
     - проектов,
     - библиотек, и
     - классов.
   - ‘осредоточьтесь на проектировании компоненты.
     - €спользуйте классы длЯ представлениЯ понЯтий.
     - ЋпределЯйте интерфейсы так, чтобы сделать открытым минимальный
       объем информации, требуемой длЯ интерфейса.
     - Џроводите строгую типизацию интерфейсов всегда, когда это
       возможно.
     - €спользуйте в интерфейсах типы из области приложениЯ всегда,
       когда это возможно.
   - Њногократно исследуйте и уточнЯйте как проект, так и реализацию.
   - €спользуйте лучшие доступные средства длЯ проверки и анализа
     - проекта, и
     - реализации.
   - ќкспериментируйте, анализируйте и проводите тестирование на
     самом раннем возможном этапе.
   - ‘тремитесь к простоте, максимальной простоте, но не сверх того.
   - Ќе разрастайтесь, не добавлЯйте возможности "на всЯкий случай".
   - Ќе забывайте об эффективности.
   - ‘охранЯйте уровень формализации, соответствующим размеру проекта.
   - Ќе забывайте, что разработчики, программисты и даже менеджеры
     остаютсЯ людьми.
…ще некоторые правила можно найти в $$12.5

        11.6 ‘писок литературы с комментариЯми

‚ этой главе мы только поверхностно затронули вопросы проектированиЯ
и управлениЯ программными проектами. Џо этой причине ниже предлагаетсЯ
список литературы с комментариЯми. ‡начительно более обширный список
литературы с комментариЯми можно найти в [2].
[1] Bruce Anderson and Sanjiv Gossain: An Iterative Design Model for
    Reusable Object-Oriented Software. Proc. OOPSLA'90. Ottawa,
    Canada. pp. 12-27.
    Ћписание модели итеративного проектированиЯ и повторного
    проектированиЯ с некоторыми примерами и обсуждением результатов.
[2] Grady Booch: Object Oriented Design. Benjamin Cummings. 1991.
    ‚ этой книге есть детальное описание проектированиЯ, определенный
    метод проектированиЯ с графической формой записи и несколько
    больших примеров проекта, записанных на различных Языках. ќто
    превосходнаЯ книга, котораЯ во многом повлиЯла на эту главу. ‚ ней
    более глубоко рассматриваютсЯ многие из затронутых здесь вопросов.
[3] Fred Brooks: The Mythical Man Month. Addison Wesley. 1982.
    Љаждый должен перечитывать эту книгу раз в пару лет.
    Џредостережение от высокомериЯ. Ћна несколько устарела в
    технических вопросах, но совершенно не устарела во всем, что
    касаетсЯ отдельного работника, организации и вопросов размера.
[4] Fred Brooks: No Silver Bullet. IEEE Computer, Vol.20 No.4.
    April 1987.
    ‘водка различных подходов к процессу развитиЯ больших программных
    систем с очень полезным предостережением от веры в магические
    рецепты ("золотаЯ пулЯ").
[5] De Marco and Lister: Peopleware. Dorset House Publishing Co. 1987.
    Ћдна из немногих книг, посвЯщенных роли человеческого фактора
    в производстве программного обеспечениЯ. Ќеобходима длЯ каждого
    менеджера. „остаточно успокаивающаЯ длЯ чтениЯ перед сном.
    ‹екарство от многих глупостей.
[6] Ron Kerr: A Materialistic View of the Software "Engineering"
    Analogy. in SIGPLAN Notices, March 1987. pp 123-125.
    €спользование аналогии в этой и следующей главах во многом
    обЯзано наблюдениЯм из указанной статьи, а так же беседам с
    ђ. Љерром, которые этому предшествовали.
[7] Barbara Liskov: Data Abstraction and Hierarchy. Proc. OOPSLA'87
    (Addendum). Orlando, Florida. pp 17-34.
    €сследуетсЯ как использование наследованиЯ может повредить
    концепции абстрактных данных. “кажем, что в ‘++ есть специальные
    Языковые средства, помогающие избежать большинство указанных
    проблем ($$12.2.5).
[8] C. N. Parkinson: Parkinson's Law and other Studies in
    Administration. Houghton-Mifflin. Boston. 1957.
    Ћдно из забавных и самых Язвительных описаний бед, к которым
    приводит процесс администрированиЯ.
[9] Bertrand Meyer: Object Oriented Software Construction.
    Prentice Hall. 1988.
    ‘траницы 1-64 и 323-334 содержат хорошее описание одного взглЯда
    на объектно-ориентированное программирование и проектирование,
    а также много здравых, практических советов. ‚ остальной части
    книги описываетсЯ Язык ќйффель (Eiffel).
[10] Alan Snyder: Encapsulation and Inheritance in Object-Oriented
    Programming Languages. Proc. OOPSLA'86. Portland, Oregon. pp.38-45.
    ‚озможно первое хорошее описание взаимодействиЯ оболочки и
    наследованиЯ. ‚ статье так же на хорошем уровне рассматриваютсЯ
    некоторые понЯтиЯ, свЯзанные с множественным наследованием.
[11] Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener:
    Designing Object-Oriented Software. Prentice Hall. 1990.
    ЋписываетсЯ антропоморфный метод проектированиЯ основанный на
    специальных карточках CRC (Classes, Responsibilities,
    Collaboration) (т.е. Љлассы, Ћтветственность, ‘отрудничество).
    ’екст, а может быть и сам метод тЯготеет к Языку Smalltalk.


         * ЏђЋ…Љ’€ђЋ‚ЂЌ€… € ‘++

        ‘тремись к простоте, максимальной простоте, но не сверх того.
         - Ђ. ќйнштейн
ќта глава  посвЯщена свЯзи между проектированием и Языком
программированиЯ ‘++. ‚ ней исследуетсЯ применение классов при
проектировании и указываютсЯ определенные виды зависимостей, которые
следует выделЯть как внутри класса, так и между классами. €зучаетсЯ
роль статического контролЯ типов. €сследуетсЯ применение наследованиЯ
и свЯзь наследованиЯ и принадлежности. ЋбсуждаетсЯ понЯтие компонента
и даютсЯ некоторые образцы длЯ интерфейсов.

        12.1 Џроектирование и Язык программированиЯ.

…сли бы мне надо было построить мост, то Я серьезно подумал бы, из
какого материала его строить, и проект моста сильно зависел бы от
выбранного материала, а, следовательно, разумные проекты каменного
моста отличаютсЯ от разумных проектов металлического моста или
от разумных проектов деревЯнного моста и т.д. Ќе стоит
рассчитывать на выбор подходЯщего длЯ моста материала без определенных
знаний о материалах и их использовании. Љонечно, вам не надо быть
специалистом плотником длЯ проектированиЯ деревЯнного моста, но вы
должны знать основы конструированиЯ из дерева, чтобы предпочесть его
металлу в качестве материала длЯ моста. Ѓолее того, хотЯ длЯ
проектированиЯ деревЯнного моста вы и не должны быть специалистом
плотником, вам необходимо достаточно детально знать свойства
дерева и еще больше знать о плотниках.
    Ђналогично, при выборе Языка программированиЯ длЯ
определенного программного обеспечениЯ надо знать несколько Языков,
а длЯ успешного проектированиЯ программы надо достаточно детально
знать выбранный Язык реализации, даже если вам лично не предстоит
написать ни одной строчки программы. •ороший проектировщик моста
ценит свойства используемых им материалов и применЯет их длЯ улучшениЯ
проекта. Ђналогично, хороший разработчик программ использует сильные
стороны Языка реализации и, насколько возможно, стремитсЯ избежать такого
его использованиЯ, которое вызовет трудности на стадии реализации.
    Њожно подумать, что так получаетсЯ естественным образом, если
в проектировании участвует только один разработчик или программист, однако
даже в этом случае программист в силу недостатка опыта или из-за
неоправданной приверженности к стилю программированиЯ, рассчитанному на
совершенно другие Языки, может сбитьсЯ на неверное использование Языка.
…сли разработчик существенно отличаетсЯ от программиста,  особенно
если у них разнаЯ программистскаЯ культура, возможность поЯвлениЯ
в окончательной версии системы ошибок, неэффективных и неэлегантных решений
почти навернЯка превратитсЯ в неизбежность.
    €так, чем может помочь разработчику Язык программированиЯ? Ћн
может предоставить такие Языковые средства, которые позволЯт
выразить прЯмо на Языке программированиЯ основные понЯтиЯ проекта.
’огда облегчаетсЯ реализациЯ, проще поддерживать ее соответствие
проекту, проще организовать общение между
разработчиками и программистами, и поЯвлЯетсЯ возможность создать
более совершенные средства как длЯ разработчиков, так и длЯ
программистов.
    Ќапример, многие методы проектированиЯ уделЯют значительное внимание
зависимостЯм между различными частЯми программы (обычно с целью
их уменьшениЯ и гарантии того, что эти части будут понЯтны и хорошо
определены). џзык, допускающий Явное задание интерфейсов между
частЯми программы, может помочь в этом вопросе
разработчикам. Ћн может гарантировать, что действительно будут
существовать только предполагаемые зависимости. Џоскольку
большинство зависимостей Явно выражено в программе на таком Языке,
можно разработать средства, читающие программу и выдающие графы
зависимостей. ‚ этом случае разработчику и другим исполнителЯм легче
уЯснить структуру программы. ’акие Языки программированиЯ как ‘++
помогают сократить разрыв между проектом и программой, а значит
уменьшают возможность путаницы и недопониманий.
     Ѓазовое понЯтие ‘++ - это класс. Љласс имеет определенный
тип. Љроме того, класс ЯвлЯетсЯ первичным средством упрЯтываниЯ
информации. Њожно описывать программы в терминах пользовательских
типов и иерархий этих типов. Љак встроенные, так и пользовательские
типы подчинЯютсЯ правилам статического контролЯ типов. ‚иртуальные
функции предоставлЯют, не нарушаЯ правил статических типов,
механизм свЯзываниЯ на этапе выполнениЯ. аблоны типа позволЯют
создавать параметризованные типы. Ћсобые ситуации позволЯют сделать
регулЯрной реакцию на ошибки. ‚се эти средства ‘++ можно
использовать без дополнительных накладных
расходов в сравнении с программой на ‘. ’аковы главнейшие
средства ‘++, которые должен представлЯть и учитывать разработчик.
Љроме того, существенно повлиЯть на принЯтие решений на стадии
проектированиЯ может наличие  доступных больших библиотек
следующего назначениЯ: длЯ работы с матрицами, длЯ свЯзи с
базами данных, длЯ поддержки параллельного
программированиЯ, графические библиотеки и т.д.
      ‘трах перед новизной, непригодный здесь опыт работы на других
Языках, в других системах или областЯх приложениЯ, бедные средства
проектированиЯ - все это приводит к неоптимальному использованию ‘++.
‘ледует отметить три момента, когда разработчику не удаетсЯ
извлечь выгоду из возможностей ‘++ и учесть ограничениЯ Языка:
[1] €гнорирование классов и составление проекта таким образом, что
    программистам приходитсЯ ограничиватьсЯ только ‘.
[2] €гнорирование производных классов и виртуальных функций,
    использование только подмножества абстрактных данных.
[3] €гнорирование статического контролЯ типов и составление проекта
    таким образом, что программисты вынуждены применЯть динамические
    проверки типов.
Ћбычно указанные моменты возникают у разработчиков, свЯзанных с:
[1] C, или традиционной системой CASE или методами стр