1 Даже в большой команде проектировщиков оформление результатов нужно поручить одному или двум людям, чтобы обеспечить согласованность мини-решений.
6.2 Важно явно определить те части архитектуры, которыенепрописаны столь же тщательно, как остальные.
6.3 Необходимо иметь как формальное описание проекта — для точности, так и текстуальное — для понимания.
6.4 Либо формальное, либо текстуальное определения выбираются в качестве стандарта, при этом второе определение является производным. Каждое определение может выступать в любой из ролей.
6.5 Реализация, в том числе модель, может служить определением архитектуры; такое использование имеет существенные недостатки.
6.6 Прямое включение является очень искусным приёмом для осуществления стандартов архитектуры в программном обеспечении (в аппаратном обеспечении — тоже: возьмите интерфейс Mac WIMP, встроенный в ROM).
6.7 Архитектурное «определение будет яснее, а (архитектурная) дисциплина крепче, если изначально строятся как минимум две реализации».
6.8 Важно, чтобы архитектор в телефонных разговорах отвечал исполнителям на их вопросы; обязательно нужно регистрировать эти разговоры в журнале и доводить их до общего сведения. (Сейчас для этого предпочтительнее электронная почта.)
6.9 «Лучший друг менеджера проекта — его постоянный противник, независимая организация, тестирующая продукт.»
Глава 7. Почему не удалось построить Вавилонскую башню?
7.1 Проект Вавилонской башни провалился из-за недостаткаобмена информациейи, как следствие,организации .
Обмен информацией
7.2 «Отставание графика, несоответствие функциональности, системные ошибки — все это из-за того, что левая рука не знает, что творит правая.» Предположения команд расходятся.
7.3 Бригады должны поддерживать между собой связь всеми возможными способами: неформально, путём регулярных совещаний по проекту с техническими отчётами и через общую рабочую тетрадь проекта. (А также электронную почту.)
Рабочая тетрадь проекта
7.4 Рабочая тетрадь проекта есть «не столько отдельный документ, сколько структура, налагаемая на все документы, которые, так или иначе, будут созданы во время выполнения проекта.»
7.5 « Вседокументы проекта должны входить в эту структуру (рабочей тетради).»
7.6 Структуру рабочей тетради нужно проектироватьтщательноирано .
7.7 Правильное структурирование текущей документации с самого начала позволяет «составленные позднее документы оформить в виде отрывков, которые вписываются в эту структуру» и улучшает руководства по продукту.
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. ) [119]
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.