Мифический человеко-месяц или как создаются программные системы
Шрифт:
Последнее возражение касается планирования временных рамок и этапов. Проще всего воздержаться от найма исполнителей до завершения работы над спецификациями. Когда воздвигается здание, так и поступают.
Однако при создании компьютерных систем темпы выше, и желательно уплотнить график работ. В какой мере разработка спецификаций и разработка могут перекрываться?
Как отмечает Блау, всю программу создания составляют три отдельные стадии: архитектура, разработка и реализация. Оказывается, что на практике их можно начинать параллельно и продолжать одновременно.
Например,
В то же время на уровне реализации нужно спроектировать, усовершенствовать и описать микросхемы, платы, кабели, каркасы, блоки питания и устройства памяти. Эта работа протекает параллельно с архитектурой и разработкой.
То же самое справедливо при создании программных систем. Задолго до завершения внешних спецификаций проектировщик может найти себе достаточно работы. Он может приступить к делу, основываясь на грубом приближении функциональности системы, которая в конечном итоге будет воплощена во внешних спецификациях. У него должны быть ясно определенные цели в отношении памяти и временных параметров. Он должен изучить конфигурацию системы, на которой будет выполняться его продукт. Затем он может начать определение границ модулей, структур таблиц, расчленения на проходы или стадии алгоритмов и всевозможных инструментальных средств. Некоторое время он должен также посвятить общению с архитектором.
В то же время достаточно работы и на уровне реализации. У программирования своя технология. Если машина новая, много труда требуют соглашения по подпрограммам, технология работы с супервизором, алгоритмы поиска и сортировки.[7]
Концептуальная целостность требует, чтобы система отражала единую философию, и технические условия, в том виде, в котором они будут видны пользователю, проистекали от малого числа авторов. Это не означает, что спроектированная таким образом система создается дольше, поскольку используется действительное
разделение труда на архитектуру, разработку и реализацию. Опыт показывает обратное: цельная система продвигается быстрее и требует меньше времени для отладки. В результате широко распространенное горизонтальное разделение труда значительно сокращается за счет вертикального разделения, что влечет резкое уменьшение обмена информацией и улучшение концептуальной целостности.
Глава 5 Эффект второй системы
Adde parvum parvo magnus acervus erit. (Складывай малое с малым, и получишь большую кучу.)
ОВИДИЙ
Если ответственность за спецификацию функций отделить от ответственности за быстрое создание недорогого продукта,
Принципиальное решение — обеспечение всестороннего, тщательного и доброжелательно обмена информацией между архитектором и разработчиком. Однако имеются и более тонкие решения, которые заслуживают внимания.
Дисциплина взаимодействия для архитектора
Архитектор, строящий здание, действует в рамках сметы, используя методы оценки, которые в последующем подтверждаются или корректируются заявками подрядчиков. Часто случается, что все предложения выходят за рамки сметы. Тогда архитектор пересматривает свои оценки в сторону увеличения сметы, а проект — в сторону сокращения, и цикл повторяется. Иногда он предлагает подрядчикам способы удешевления реализации его проекта в сравнении с избранными ими способами.
Сходные процессы происходят с архитектором компьютерных или программных систем. Однако у него есть то преимущество, что предложения подрядчика можно получить на ранних стадиях проектирования, часто — в любой момент. Недостатком обычно является то, что работа идет с единственным подрядчиком, который может менять цену в зависимости от степени своей удовлетворенности проектом. На практике, процесс общения, начатый на ранних этапах и продолжающийся непрерывно, может дать архитектору верную оценку стоимости, а разработчику — уверенность в проекте, не снимая при этом четкого разграничения сфер ответственности.
У архитектора, когда он сталкивается с неприемлемо высокой стоимостью, есть два выхода: сократить проект или воздействовать на стоимость, предлагая более дешевые способы реализации. Второй способ неизбежно вызывает эмоции, ведь архитектор оспаривает то, как строитель справляется со своим делом. Чтобы успешно справиться с этим, архитектору необходимо:
• помнить, что ответственность за изобретательность и творчество, проявляемые при реализации, несет строитель, поэтому архитектор предлагает, а не требует;
• всегда быть готовым предложить некоторый способ реализации своих замыслов и быть готовым согласиться с любым другим способом, позволяющим решить задачу не хуже;
• выдвигая такие предложения, действовать без шума и огласки;
• не рассчитывать на признательность за сделанные предложения.
Обычно разработчик парирует предложением изменений в архитектуре. Часто он прав — реализация какой-нибудь малосущественной детали может оказаться неожиданно дорогостоящей.
Самодисциплина — эффект второй системы
Первый проект архитектора стремится к скромности и ясности. Архитектор понимает, что не знает, чем занимается, поэтому он занимается этим со старанием и самоограничением.
При работе над первым проектом ему постоянно приходят в голову то одни, то другие «украшения». Они откладываются в сторону для использования «в следующий раз». В конце концов, первая система закончена, и архитектор, с твердой уверенностью в себе и продемонстрированным освоением этого класса систем, готов к созданию нового проекта.