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

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

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

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

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

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

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

Библиотеки программ и учет. Очень успешным и важным применением вспомогательной машины в программе разработки OS/360 была поддержка библиотек программ. Система, разработанная под руководством У. Р. Кроули (W. R. Crowley), состояла из двух соединенных вместе машин 7010 и общей дисковой базой данных. На 7010 поддерживался также ассемблер для S/360. В этой библиотеке хранился весь протестированный или находящийся в процессе тестирования код, как исходный, так и ассемблированные загрузочные модули. На практике библиотека была разбита на подбиблиотеки с различными правами доступа.

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

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

Через некоторое время системная версия была готова для более широкого использования. Тогда она перемещалась в подбиблиотеку текущей версии. Этот экземпляр был священным, и доступ к нему разрешался только для исправления разрушительных ошибок. Его можно было использовать для интегрирования и тестирования всех новых версий модулей. Программный каталог на машине 7010 отслеживал все версии каждого модуля, его состояние, местонахождение и изменения.

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

По моему мнению, это было одним из лучших решений в программе OS/360. Эта часть технологии управления была независимо разработана для нескольких крупных программных проектов, в том числе в Bell Labs, ICL и Кембриджском университете. [2] Она применима как к программам, так и к документации. Это — неоценимая технология.

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

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