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

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

4.3 Для достижения концептуальной целостности проект должен создаваться одним человеком или группой единомышленников.

4.4 «Отделение разработки архитектуры от реализации является эффективным способом достижения концептуальной целостности при работе над очень большими проектами.» (И маленькими тоже.)

4.5 «Если вы хотите, чтобы система обладала концептуальной целостностью, кто-то один должен взять руководство концепциями. Это аристократизм, который не нуждается в извинениях.»

4.6 Дисциплина полезна искусству. Получение архитектуры извне усиливает, а не подавляет творческую активность группы исполнителей.

4.7 Концептуально целостные системы быстрее разрабатываются и тестируются.

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

Глава 5. Эффект второй системы

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

5.2 Как архитектору успешно влиять на реализацию:

• Помнить, что ответственность за творчество, проявляемое при реализации, несет строитель, поэтому архитектор только предлагает.

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

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

• Не рассчитывать на признательность за предложенные усовершенствования.

• Выслушивать предложения разработчиков по усовершенствованию архитектуры.

5.3 Из всех проектируемых систем наибольшую опасность представляет вторая по счету; обычно ее приходится перепроектировать заново.

5.4 OS/360 является ярким примером эффекта второй системы. (Похоже, что Windows NT — это пример для 1990 года.)

5.5 Достойной внимания практикой является предварительное назначение функциям величин в байтах и микросекундах.

Глава 6. Донести слово

6.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 Правильное структурирование текущей документации с самого начала позволяет «составленные позднее документы оформить в виде отрывков, которые вписываются в эту структуру» и улучшает руководства по продукту.