Geum.ru

Фредерик П. Брукс

Вид материалаДокументы
Чем заняться разработчику, пока он вынужден ждать?
Подобный материал:
1   ...   6   7   8   9   10   11   12   13   ...   48

Чем заняться разработчику, пока он вынужден ждать?


Очень неприятно совершить ошибку стоимостью в миллион долларов, но зато она надолго запоминается. Я отчетливо помню тот день, когда мы приняли решение о том, как практически организовать составление внешних спецификаций для OS/360. Менеджер по архитектуре, менеджер по реализации управляющей программы и я прорабатывали план, график и разделение обязанностей.

У менеджера по архитектуре было 10 хороших специалистов. Он утверждал, что они в состоянии написать спецификации и сделать это должным образом. Это должно было занять 10 месяцев - на три больше, чем отводилось по графику.

У менеджера по реализации управляющей программы было 150 человек. Он заявлял, что они могут подготовить спецификации, при этом группа архитекторов выполняла бы координирующие функции. Обещалось, что это будет сделано хорошо и практично, с соблюдением сроков. Более того, если оставить спецификации группе архитекторов, его 150 человек в течение десяти месяцев будут бить баклуши.

На это менеджер по архитектуре возразил, что если я сделаю ответственной за написание спецификаций группу управляющей программы, то результата в срок не будет: он все равно задержится на три месяца, но по качеству будет много хуже. Так оно и оказалось в действительности. Он оказался прав в обоих пунктах. Кроме того, из-за отсутствия концептуальной целостности создание и внесение изменений в систему оказались значительно более дорогостоящими, и, по моим оценкам, отладка удлинилась на год.

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

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

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

- Архитекторы получат все радости творчества и заблокируют изобретательность исполнителей.

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

Первое возражение отражает реальную опасность и будет рассмотрено в следующей главе. Остальные два являются чистым заблуждением. Как мы видели выше, разработка также является в высшей степени творческой деятельностью. Возможность проявить творчество и изобретательность при разработке незначительно ограничивается необходимостью работать в рамках заданных внешних спецификаций, и такая дисциплина может даже усилить степень творчества. Это, несомненно, верно для проекта в целом.

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

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

Как отмечает Блау, всю программу создания составляют три отдельные стадии: архитектура, разработка и реализация. Оказывается, что на практике их можно начинать параллельно и продолжать одновременно. Например, при проектировании компьютеров проектировщик может приступать к работе, имея относительно общие допущения в отношении руководства пользователя, несколько более ясные идеи относительно технологии и вполне определенные задачи по стоимости и рабочим характеристикам. Он может начать проектирование потоков данных, управляющих последовательностей, общих идей компоновки и т.д. Он разрабатывает или адаптирует необходимый инструментарий, особенно систему ведения учета, в том числе систему автоматизации проектирования.

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

То же самое справедливо при создании программных систем. Задолго до завершения внешних спецификаций проектировщик может найти себе достаточно работы. Он может приступить к делу, основываясь на грубом приближении функциональности системы, которая в конечном итоге будет воплощена во внешних спецификациях. У него должны быть ясно определенные цели в отношении памяти и временных параметров. Он должен изучить конфигурацию системы, на которой будет выполняться его продукт. Затем он может начать определение границ модулей, структур таблиц, расчленения на проходы или стадии алгоритмов и всевозможных инструментальных средств. Некоторое время он должен также посвятить общению с архитектором.

В то же время достаточно работы и на уровне реализации. У программирования своя технология. Если машина новая, много труда требуют соглашения по подпрограммам, технология работы с супервизором, алгоритмы поиска и сортировки.7

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