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

7.8 «Каждый член команды должен видеть все материалы (рабочей тетради).» (Сейчас я бы сказал «должен иметь возможность видеть». Например, достаточно WWW-страниц.)

7.9 Своевременное обновление может иметь критическое значение.

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

7.11 Рабочая тетрадь проекта OS/360 начиналась с бумажного варианта с последующим переходом на микрофиши.

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

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

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

7.15 Предложение Парнаса — путь к катастрофе. (Парнас вполне убедил меня в обратном, и я совершенно изменил свое мнение.)

Организация

7.16 Задачей организации является сокращение объема необходимого общения и согласования.

7.17 Организация заключает в себе разделение труда и специализацию функций с целью сократить обмен информацией.

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

7.19 Структура обмена информацией в организации является не деревом, а сетью, и нужно придумать различные виды специальных организационных механизмов («пунктирные линии»), чтобы преодолеть дефицит обмена информацией в древовидной организации.

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

7.21 Вполне эффективным может быть любой тип взаимоотношений между этими двумя должностями:

• Это может быть одно лицо.

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

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

Глава 8. Объявляя удар

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

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

8.3 Объем работ растет как степенная функция размера программы.

8.4 Некоторые опубликованные исследования показывают, что показатель степени примерно равен 1,5. (Результаты Бёма с этим не согласуются и меняются от 1,05 до 1,2.) [1]

8.5 Данные Портмана по ICL показывают, что занятые на полный рабочий день программисты только около 50 процентов времени занимаются программированием и отладкой, а остальное время занимают разные дополнительные задачи.

8.6 По данным Арона из IBM, производительность труда лежит в пределах от 1,5 до 10 тысяч строк программы на человека в год в зависимости от количества взаимодействий между частями системы.

8.7 По данным Харра из Bell Labs, производительность труда при задаче типа разработки операционной системы составила около 0,6 тысяч строк кода на человека в год, а при разработке компиляторов — 2,2 тысячи для законченных продуктов.

8.8 Данные Брукса по OS/360 согласуются с данными Харра: 0,6-0,8 тысяч строк кода на человеко-год для операционных систем и 2-3 тысячи для компиляторов.

8.9 Данные Корбато по проекту МТИ MULTICS показывают, что производительность труда при разработке смеси операционной системы и компиляторов составила 1,2 тысяч строк кода на человека в год, но это строки кода PL/I, а остальные данные относятся к строкам кода ассемблера!

8.10 Производительность примерно постоянна в переводе на элементарные операторы.

8.11 При использовании подходящих языков высокого уровня производительность можно увеличить в пять раз.

Глава 9. Два в одном

9.1 Если не считать времени выполнения, то главные издержки приходятся на занимаемое программой пространство памяти. Это в особенности верно для операционных систем, значительная часть которых остается резидентной.

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

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

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

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