Geum.ru

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

Вид материалаДокументы
Парнас был прав, а я - нет в отношении сокрытия информации
Насколько мифичен человеко-месяц? Модель и данные Бема
Насколько верен закон Брукса?
Подобный материал:
1   ...   38   39   40   41   42   43   44   45   ...   48

Парнас был прав, а я - нет в отношении сокрытия информации


В главе 7 я противопоставляю две точки зрения на то, в какой мере каждый участник команды может иметь право или поощряться к знанию проектов и текстов программ, созданных коллегами. Во время проекта Operating System/360 мы решили, что все программисты должны видеть весь материал, т.е. у каждого программиста была рабочая тетрадь проекта, которая к концу насчитывала свыше 10000 страниц. Харлан Миллз убедительно доказывал, что "программирование должно быть открытым процессом", что предоставление всей работы на общее обозрение способствует контролю качества как благодаря давлению со стороны коллег, заставляющему работать хорошо, так и благодаря тому, что коллеги действительно находят промахи и ошибки.

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

В главе 7 я заклеймил идею Парнаса как "рецепт катастрофы". Парнас былп рав, а я ошибался. Сегодня я убежден, что ограничение информации, часто осуществляемое теперь методами объектного программирования, является единственным способом поднять уровень программных разработок.

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

В главе 16 утверждается следующее:

- большая часть роста производительности разработки программногообеспечения обеспечена устранением второстепенных трудностей, таких какнеудобные языки программирования и медленная оборачиваемость пакетнойобработки;

- легких решений в этом направлении практически не осталось;

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

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

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

Третий шаг, объектно-ориентированное программирование, вводит важноепонятие наследования, при котором классы (типы данных) по умолчанию имеютатрибуты своих предков в иерархии классов.14 То, что мы рассчитываемполучить от объектно- ориентированного программирования, происходит, всущности, от первого шага, инкапсуляции модулей, плюс идея заранееподготовленных библиотек модулей или классов, спроектированных ипротестированных с целью повторного использования. Многие предпочлипроигнорировать тот факт, что такие модули не просто программы, апрограммные продукты в том смысле, который разъяснен в главе 1. Напраснорассчитывать на успешное повторное использование модулей, не оплачиваяначальные издержки на разработку качественных программных модулей:обобщенных, надежных, протестированных и документированных. Объектно-ориентированное программирование и повторное использование обсуждались вглавах 16 и 17.

Насколько мифичен человеко-месяц? Модель и данные Бема


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

Наиболее обстоятельное исследование сделано Барри Бемом (Barry Boehm)на основании примерно 63 проектов, в основном в аэрокосмической области, изних около 25 - в TRW. Его работа "Экономика разработки программногообеспечения" содержит не только результаты, но и ряд полезных моделей затратс нарастающей сложностью. Хотя несомненно, что применяемые в моделяхкоэффициенты различны для обычных космических программ и для программ,создаваемых в аэрокосмической области по правительственным стандартам, всеже его модели подкрепляются огромным количеством данных. Я думаю, что книгабудет полезным классическим трудом и через поколение.

Полученные им результаты уверенно подкрепляют содержащееся в МЧ-Мутверждение о том, что соотношение между численностью занятых и временемвыполнения проекта далеко не линейное, что человеко-месяц действительноявляется мифической мерой производительности. В частности, он считает:15

- Существует оптимальное, с точки зрения затрат, время выполненияграфика для первой поставки: T = 2,5 (ЧМ)1/3. То есть оптимальное время вмесяцах изменяется как кубический корень предполагаемого объема работ вчеловеко- месяцах - формула, полученная из оценки размера и других факторовв его модели. Следствием является кривая, дающая оптимальную численностьзанятых.

- Кривая стоимости медленно растет, если запланированный график длиннееоптимального. Работа занимает все отведенное для нее время.

- Кривая стоимости резко растет, если запланированный график корочеоптимального.

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

Насколько верен закон Брукса? Были даже проведены тщательныеисследования закона Брукса (намеренно упрощенного), согласно которомувыделение дополнительных людей для отстающего графика проекта лишьзадерживает его выполнение. Лучше всего это сделано Абдель-Хамидом(Abdel-Hamid) и Мадником (Madnick) в честолюбивой и ценной книге "Динамикапрограммного проекта: интегрированный подход".16 В книге разработанаколичественная модель динамики проекта. Глава о законе Брукса более подробновникает в то, что происходит при различных допущениях относительно того,кого добавляют, и когда. Чтобы исследовать это, авторы развивают собственнуютщательную модель программного проекта среднего размера, предполагая, что увновь добавляемых людей есть кривая обучения, и учитывая дополнительныеиздержки на общение и обучение. Они приходят к выводу, что "добавление новыхлюдей к запаздывающему проекту всегда приводит к его удорожанию, но невсегда к более позднему завершению" (курсив авторов). В частности,увеличение численности работников в начале проекта гораздо безопаснее, чем вконце, поскольку добавление новых людей всегда вызывает отрицательныйэффект, для компенсации которого требуются недели.

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

Штуцке считает, что дополнительная тяжесть обмена информацией в крупномпроекте имеет второй порядок малости, и не включает ее в свою модель. Невполне ясно, учитывают ли ее Абдель-Хамид и Мадник, и если да, то как. Ни водной из моделей не учитывается то обстоятельство, что работа должна бытьперераспределена - процесс, который для меня часто оказывался нетривиальным.

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