Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы
Что это за инструменты, разработку которых менеджер должен обдумывать, планировать и организовывать? Прежде всего, вычислительные средства. Для этого требуются машины, и должна быть принята политика планирования времени. Для этого требуется операционная система, и должна быть установлена политика обслуживания. Для этого требуется язык, и должна быть заложена политика в отношении языка. Затем идут утилиты, средства отладки, генераторы контрольных примеров и текстовый процессор для работы с документацией. Рассмотрим их поочередно.[1]
Целевые машины
Машинную поддержку полезно разделить на целевые машины и рабочие машины. Целевая машина — это та, для которой пишется программное обеспечение и на которой, в конце концов, его нужно будет тестировать. Рабочие машины — это те, которые предоставляют сервисы, используемые для создания системы. Если создается новая операционная система для старой машины, последняя может служить одновременно и целевой, и рабочей.
Каковы типы целевых средств? Если бригада создает новый супервизор или другое программное средство, составляющее сердцевину системы, то ей, конечно, нужна своя машина. Для таких систем потребуются операторы и один или два системных программиста, чтобы машина была в рабочем состоянии.
Если требуется отдельная машина, то она должна быть довольно специфической: не требуется, чтобы она была быстрой, но требуется, по меньшей мере, 1 Мбайт
оперативной памяти, 100 Мбайт в активных дисках и терминалы. Достаточно символьных терминалов, но со значительно большей скоростью, чем 15 символов в секунду, характерных для пишущих машинок. Наличие большой памяти значительно способствует продуктивности, позволяя заняться разбиением на оверлеи и минимизацией размера после тестирования функций.
Машина или программные средства для отладки должны также иметь средства для автоматического подсчета и измерений любых параметров программы во время отладки. К примеру, карты использования памяти служат мощным диагностическим средством при выяснении странной логики поведения или неожиданно низкой производительности.
Планирование времени. Если целевая машина новая, — например, для нее создается первая операционная система, — то машинного времени мало, и планирование становится большой проблемой. Потребности в рабочем времени целевой машины имеет специфическую кривую роста. При разработке OS/360 у нас были хорошие эмуляторы System/360 и другие машины. По прежнему опыту мы оценили, сколько часов рабочего времени S/360 нам понадобится, и стали получать первые машины с производства. Но месяц за месяцем они оставались без нагрузки. Затем сразу все 16 систем оказались загруженными, и распределение времени стало проблемой. Использование машин выглядело примерно как на рисунке 12.1. Все одновременно начали отлаживать первые компоненты, и затем все команды постоянно что-то отлаживали.
Рис. 12.1 Рост использования целевых машин
Мы централизовали все свои машины и библиотеки магнитных лент и организовали для их работы профессиональную и опытную группу машинного зала. Для максимизации бывшего в недостатке машинного времени S/360 все отладочные прогоны мы осуществляли в пакетном режиме на подходящих свободных машинах. Мы добились четырех запусков в день (оборачиваемость составила два с половиной часа), а требовалась четырехчасовая оборачиваемость. Вспомогательная машина 1401 с терминалами использовалась для планирования прогонов, отслеживания тысяч заданий и контроля времени оборачиваемости.
Но со всей этой организованностью мы перестарались. После нескольких месяцев низкой оборачиваемости, взаимных обвинений и прочих мук мы перешли к выделению машинного времени крупными блоками. К примеру, вся группа из пятнадцати человек, занимавшаяся сортировкой, получала систему на срок от четырех до шести часов. Планирование этого времени было их внутренним делом. Даже если система была на занята, посторонние не могли ею пользоваться.
Это оказалось более удачным способом планирования. Хотя коэффициент использования машины, возможно, несколько упал (а часто и этого не было), производительность поднялась. Для каждого члена команды десять запусков в течение шести часов значительно продуктивнее, чем десять запусков, осуществленных с перерывами в три часа, поскольку постоянная концентрация сокращает время обдумывания. После такой гонки команде обычно требовалось один-два дня, чтобы подогнать работу с документами, прежде чем просить о выделении нового блока. Зачастую всего три программиста могут с пользой поделить и распределить между собой выделенный им блок времени. Похоже, что это лучший способ использования целевой машины при отладке новой операционной системы.
Так было на практике, хотя это не соответствовало теории. Системная отладка всегда была занятием для ночной смены, подобно астрономии. Двадцать лет назад, работая над 701-й машиной, я впервые познал продуктивную свободу от формальностей, присущую предрассветным часам, когда все начальники из машинного зала крепко спят по домам, а операторы не расположены бороться за соблюдение правил. Сменилось три поколения машин, полностью изменились технологии, появились операционные системы, но этот лучший способ работы остался прежним. Он продолжает жить, поскольку наиболее эффективен. Пришла пора признать его продуктивность и шире применять.
Рабочие машины и службы данных
Эмуляторы. Если целевой компьютер новый, то для него необходим логический эмулятор. Это дает аппарат для отладки задолго до того, как целевая машина будет в наличии. Что столь же важно, даже тогда, когда становится доступной целевая машина, имеется доступ к надежному средству для отладки.
Надежное — не то же самое, что точное. Эмулятор неизбежно в каком-либо отношении будет отступать от верной и точной реализации архитектуры новой машины. Но это будет одна и та же реализация и сегодня, и завтра, чего не скажешь о новой аппаратной части.
В наше время мы привыкли к тому, что аппаратная часть компьютера большую часть времени работает без сбоев. Если только разработчик прикладной программы не замечает, что система неодинаково ведет себя при разных идентичных прогонах программы, ему правильнее всего поискать ошибки в своем коде, а не в технике.
Этот опыт, однако, сослужил плохую службу при программировании новой машины. Лабораторные разработки, предварительные или ранние выпуски компьютеров не работают должным образом, не работают надежно и не остаются неизменными день ото дня. По мере обнаружения ошибок технические изменения производятся во всех экземплярах машины, включая используемый группой программистов. Такая неустойчивость основания достаточно неприятна. Отказы аппаратуры, обычно скачкообразные, еще хуже. И хуже всего неопределенность, лишающая стимула старательно копаться в своем коде в поисках ошибки — ее может там вовсе не быть. Поэтому надежный эмулятор на зрелой машине остается полезным значительно дольше, чем можно было предположить.
Машины для компилятора и ассемблера. По тем же причинам требуются компиляторы и ассемблеры, работающие на надежных машинах, но компилирующие объектный код для целевой системы. Затем можно начать его отладку на эмуляторе.
При программировании на языках высокого уровня значительную часть отладки можно произвести при компиляции для вспомогательной машины и тестировании результирующей программы, прежде чем отлаживать программу для целевой машины. Этим достигается производительность непосредственного исполнения, а не эмуляции, в сочетании с надежностью стабильной машины.
Библиотеки программ и учет. Очень успешным и важным применением вспомогательной машины в программе разработки OS/360 была поддержка библиотек программ. Система, разработанная под руководством У. Р. Кроули (W. R. Crowley), состояла из двух соединенных вместе машин 7010 и общей дисковой базой данных. На 7010 поддерживался также ассемблер для S/360. В этой библиотеке хранился весь протестированный или находящийся в процессе тестирования код, как исходный, так и ассемблированные загрузочные модули. На практике библиотека была разбита на подбиблиотеки с различными правами доступа.
Прежде всего, у каждой группы или программиста была область для хранения экземпляров программ, контрольных примеров и окружения, которое требовалось для тестирования компонентов. На этой площадке для игр не было никаких ограничений на действия с собственными программами.
Когда компонент программиста был готов к включению в более крупную часть, его экземпляр передавался менеджеру этой более крупной системы, который помещал его в подбиблиотеку системной интеграции. Теперь автор не мог его изменить без разрешения менеджера интеграции. Когда система собиралась воедино, этот менеджер проводил все виды системного тестирования, выявляя ошибки и получая исправления.
