Мифический человеко-месяц или как создаются программные системы

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

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

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

Используя другие методы, можно действительно попасть в беду. Согласно методике Миллза программисты могут получить

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

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

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

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

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

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

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

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

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

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

Наиболее обстоятельное исследование сделано Барри Бёмом (Barry Boehm) на основании примерно 63 проектов, в основном в аэрокосмической области, из них около 25 – в TRW. Его работа «Экономика разработки программного обеспечения» содержит не только

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

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

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

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

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

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

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

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