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 Ресурсы памяти должны привязываться к назначению функций: точно определяйте, что должен делать модуль, когда задаете его размеры.

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

9.7 На всем протяжении реализации системные архитекторы должны постоянно проявлять бдительность с целью непрерывного обеспечения целостности системы.

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

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

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

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

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

9.13 Библиотеки программ должны иметь по две версии каждого компонента — быструю и компактную. (Похоже, что сегодня это устарело.)

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

9.15 Таким прорывом часто является новый алгоритм.

9.16 Еще чаще прорыв происходит благодаря изменению представления данных или таблиц. Представление — сущность программирования.