Мифический человеко-месяц или как создаются программные системы
Шрифт:
8.1 Нельзя точно оценить общий объем или график работ программного проекта, просто оценив время написания программы и умножив на некоторые коэффициенты для остальных частей задания.
8.2 Данные, относящиеся к созданию небольших отдельных систем, не применимы к проектам создания программных комплексов.
8.3 Объем работ растет как степенная функция размера программы.
8.4 Некоторые опубликованные исследования показывают, что показатель степени примерно равен 1,5. (Результаты Бёма с этим не согласуются и меняются от 1,05 до 1,2.) [1]
8.5
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 Еще чаще прорыв происходит благодаря изменению представления данных или таблиц. Представление — сущность программирования.
Глава 10. Документарная гипотеза
10.1 Гипотеза: Среди моря бумаг несколько документов становятся критически важными осями, вокруг которых вращается все управление проектом. Они являются главными личными инструментами менеджера.
10.2 Для проекта разработки компьютера решающими документами являются цели, руководство, график, бюджет, организационная структура, план помещений, а также оценка, прогноз и цены для самой машины.
10.3 Для факультета университета важнейшие документы аналогичны: цели, требования к соискателям степеней, описания курсов, предложения по научной работе, расписание занятий и план обучения, бюджет, план помещений, а также назначения преподавателей и аспирантов.
10.4 Для программного проекта требования те же: цели, руководство пользователя, внутренняя документация, график, бюджет, организационная структура и план помещений.
10.5 Поэтому даже для самого маленького проекта менеджер с самого начала должен формализовать такой набор документов.
10.6 Подготовка каждого документа их этого маленького набора концентрирует мысль и кристаллизует обсуждение. При изложении на бумаге требуется принятие сотен мини-решений, и их наличие отличает четкую и точную политику от расплывчатой.