Читаем Мифический человеко-месяц или как создаются программные системы полностью

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

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

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

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

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

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

<p>Глава 5 Эффект второй системы</p>

Adde parvum parvo magnus acervus erit. (Складывай малое с малым, и получишь большую кучу.)

ОВИДИЙ

Если ответственность за спецификацию функций отделить от ответственности за быстрое создание недорогого продукта, то чем сдержать изобретательский энтузиазм архитектора?

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

Дисциплина взаимодействия для архитектора

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

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

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

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

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

• выдвигая такие предложения, действовать без шума и огласки;

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

Перейти на страницу:

Похожие книги

100 абсолютных законов успеха в бизнесе
100 абсолютных законов успеха в бизнесе

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

Брайан Трейси

Деловая литература / Маркетинг, PR, реклама / О бизнесе популярно / Финансы и бизнес