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

Некоторые считают это безрадостной картиной. Это те, кто полагал, что вот-вот наступит прорыв.

Но некоторые из нас — достаточно сварливые, чтобы считать себя реалистами, — относятся к этому как к глотку свежего воздуха. Наконец-то можно сосредоточиться на чем-то более близком к жизни, чем журавль в небе. Теперь, вероятно, мы сможем заняться постепенными усовершенствованиями производства программного обеспечения, которые действительно достижимы, а не ждать прорывов, которые вряд ли когда-либо произойдут. [29]

Сегодня о технике разработки программного обеспечения известно значительно больше, чем в 1975 году. Какие из утверждений, содержащихся в первом издании 1975 года, подтвердились опытом и данными? Какие были опровергнуты? Какие устарели в нашем изменчивом мире? Чтобы вам легче было судить, здесь, в виде сводки, приведены важнейшие утверждения книги 1975 года, которые я считал верными: факты и извлеченные из опыта практические правила, приведенные с сохранением изначального смысла. (Можно задаться вопросом: если это все, что было сказано в первоначальном издании, почему тогда это заняло так много места?) В скобках приведены свежие комментарии.

Большинство этих предложений можно проверить на практике. Излагая их в сжатой форме, я надеюсь сконцентрировать мысли читателя, измерения и комментарии.

Глава 1. Смоляная яма

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

1.2 Занятие программированием «отвечает глубокой внутренней потребности в творчестве и удовлетворяет чувственные потребности, которые есть у всех у нас», доставляя пять видов радости:

• Радость, получаемая при создании чего-либо своими руками.

• Удовольствие создавать вещи, которые могут быть полезны другим людям.

• Очарование создания сложных головоломных объектов, состоящих из взаимодействующих движущихся частей.

• Радость, получаемая от неизменного узнавания нового, неповторяемости задачи.

• Удовольствие от работы со столь податливым материалом — чистой мыслью, который, тем не менее, существует, движется и работает так, как не могут словесные объекты.

1.3 В то же время этому занятию присущи и огорчения:

• При изучении программирования труднее всего привыкнуть к требованию совершенства.

• Постановка задач осуществляется другими людьми и приходится зависеть от вещей (особенно, программ), которые нельзя контролировать; полномочия не соответствуют ответственности.

• Страшно только на словах: фактическая власть приобретается как следствие успешного выполнения задач.

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

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

Глава 2. Мифический человеко-месяц

2.1 Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам, вместе взятым.

2.2 Чтобы приготовить вкусную пищу, нужно время; некоторые задачи нельзя ускорить, не испортив результат.

2.3 Все программисты являются оптимистами: «Все будет хорошо».

2.4 Поскольку программист работает с чистыми идеями, мы не ожидаем особых трудностей при реализации.

2.5 Но сами наши идеи бывают ошибочными — отсюда и ошибки в программах.

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

2.7 Разделение задачи между несколькими людьми вызывает дополнительные затраты на обучение и обмен информацией.

2.8 Мое практическое правило: 1/3 времени — на проектирование, 1/6 — на написание программы, 1/4 — на тестирование компонентов и 1/4 — на системное тестирование.