Мифический человеко-месяц

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

11.6 Поэтому планируйте выбросить первую версию — вам все равно придется это сделать.

11.7 «Программист поставляет удовлетворение потребности пользователя, а не какой-то осязаемый продукт» (Косгроув).

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

11.9 Податливость и неосязаемость программного продукта побуждают его создателей (исключительно) к вечному изменению требований.

11.10 Некоторые законные изменения в задачах (и стратегиях разработки) неизбежны, и лучше подготовиться к ним заранее, чем предполагать, что их не будет.

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

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

11.13 Вносите изменения квантами в хорошо определенные нумерованные версии. (Сейчас это обычная практика.)

Планируйте организацию для изменений

11.14 «Нежелание программистов документировать проект происходит не столько от лени, сколько от неуверенности, стоит ли связывать себя отстаиванием решений, которые, как знает проектировщик, являются предварительными» (Косгроув).

11.15 Создавать организационную структуру с учетом внесения в будущем изменений значительно труднее, чем проектировать систему с учетом будущих изменений.

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

11.17 Препятствия к поддержанию эффективной организации с двойной служебной лестницей являются социологическими. Необходимо постоянно бдительно и энергично бороться с ними.

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

11.19 Организация по типу операционной бригады позволяет активно решать все стороны этой проблемы. Это действительно долгосрочное решение проблемы гибкой организации.

Два шага вперед, шаг назад: сопровождение программ

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

11.21 Стоимость пожизненного сопровождения широко используемой программы обычно составляет 40 и более процентов стоимости ее разработки.

11.22 Стоимость сопровождения сильно зависит от числа пользователей: чем больше пользователей, тем больше ошибок они находят.

11.23 Кэмпбел отмечает интересную кривую взлета и падений обнаруживаемых ошибок в течение жизни продукта.

11.24 Исправление одной ошибки с большой вероятностью (от 20 до 50 процентов) вносит другую.

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

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

11.27 То же можно сказать о методах реализации проектов меньшим числом интерфейсов и меньшим количеством ошибок.

Шаг вперед, шаг назад: энтропия системы с течением времени растет

11.28 Леман и Белади считают, что общее количество модулей растет линейно с номером версии операционной системы (OS/360), но числи модулей, затронутых изменениями, растет экспоненциально в зависимости от номера версии.

11.29 Все исправления имеют тенденцию к разрушению структуры, увеличению энтропии и дезорганизации системы. Даже самое искусное сопровождение программы только отдаляет момент повержения ее в состояние неисправимого хаоса, выходом из которого является повторное проектирование с самого начала. (Иногда реальная необходимость обновления программы, например, с целью повышения производительности, вызывает необходимость изменения