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

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 Еще чаще прорыв происходит благодаря изменению представления данных или таблиц. Представление — сущность программирования.

Глава 10. Документарная гипотеза

10.1 Гипотеза: Среди моря бумаг несколько документов становятся критически важными осями, вокруг которых вращается все управление проектом. Они являются главными личными инструментами менеджера.

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

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

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

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

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

10.7 Сопровождение каждого важного документа требует наличия механизма слежения за состоянием и предупреждения.

10.8 Каждый документ в отдельности служит контрольным списком и базой данных.

10.9 Важнейшая задача менеджера — обеспечить общее движение в одном направлении.

10.10 Главная постоянная задача менеджера — общение, а не принятие решений; документы информируют всю команду о планах и решениях.

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

10.12 По этой причине модная идея «всеохватывающей информационной системы для управления», обеспечивающей поддержку руководителя, основывается на неверной модели поведения руководителя.

Глава 11. Планируйте на выброс

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

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

11.3 Для большинства проектов первую построенную версию едва можно использовать: слишком медленная, слишком большая, слишком сложная в применении, или все это вместе.

11.4 Отбросить и перепроектировать можно все сразу, а можно по частям, но все равно это придется сделать.

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

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

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

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

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

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