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

1. Желание организовать связь. При этом вычислительные машины играют вспомогательную роль, а сеть существует для передачи информации.

2. Желание создать сеть машин. Такая сеть нужна для вычисления, и линии связи обеспечивают возможность этих вычислений.

Очевидно, что между этими двумя типами существует некоторое перекрытие. И с ним уже десяток лет борется FCC (Федеральная комиссия по связи — Federal Communications Commission).

Стоимость сетей первого типа — сетей связи — должна определяться их задачами. Либо они себя оправдывают, либо нет. И если существует более дешевый способ управления системой, то вычислительные машины использовать нет необходимости. Экономическую целесообразность использования вычислительных сетей показать не так просто. Сеть Агентства министерства обороны США по передовым исследовательским проектам (Advanced Research Projects Agency — ARPA) можно считать великолепным техническим достижением, доказавшим, что можно объединять в одной сети множество разнотипных вычислительных машин, причем все протоколы, написанные для этого, будут верно работать. Вычислительных же сетей, действующих в частном секторе и дающих реальный доход, очень мало, если они вообще существуют. Некоторые крупные компании, занимающиеся работой в режиме разделения времени, считают экономически более выгодным использовать центральный вычислительный комплекс, состоящий из расположенных в одном месте нескольких вычислительных машин, и коммуникационную сеть, собирающую информацию для централизованной обработки. При этом можно обойтись единым руководством, одной бригадой операторов, единой охраной и т. д. Кроме экономических могут, однако, существовать и другие причины, приводящие к распределению вычислительных машин. Надежность, защита от стихийных бедствий и забастовок, исключение необходимости создания огромных сложнейших систем программного обеспечения могут оказаться вполне достаточными предпосылками.

В середине 1974 г. я получил приглашение от отделения обработки данных фирмы IBM (ООД): не смогу ли я совместно со своими лучшими специалистами затратить один день на рассмотрение состояния дел в работе над предложениями, которые ООД собиралось передать в General Motors? Я согласился.

Просить помощи не в правилах ООД. Но о предложениях, готовящихся для General Motors, уже складывались легенды — их масштаб и сложность, как говорили, не имели прецедентов.

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

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

Люди из ООД подробно проинформировали нас, и нам стали очевидны два факта 1) техническая компетентность и 2) путаница в целях.

Зачем огромной вычислительной машине, выполняющей инвентаризацию, составление платежных ведомостей и планирующей производство в городе 1, взаимодействовать с большой системой разделения времени, расположенной в городе 2? И зачем этим двум машинам еще взаимодействовать с мощной машиной для научных расчетов, которая стоит в городе 3?

Потому что так требуется в запросе на систему! Может быть, для выравнивания загрузки, может быть, для разделения данных, может быть, для…?

Ясного ответа на эти вопросы не было! Способ взаимодействия и используемые при этом соглашения зависят от того, зачем вы объединяете все эти вычислительные машины. «Как» идет следом за «почему».

Известно, что фирма General Motors так и не подписала контракт! Несмотря даже на то, что IBM и некоторые фирмы потратили по миллиону долларов, чтобы ответить на все запросы.

Фирма General Motors не новичок в деле использования вычислительной техники. И даже этот весьма квалифицированный пользователь не избежал соблазна, исходящего от «новых» методов, «новых» использований.

Распределенная обработка нужна и всегда была нужна, но пользоваться ею нужно в оправданных случаях. Это не панацея и не волшебное лекарство. Всему свое место. Слишком часто все эти «новые» подходы используются вслепую.

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

Если мы не будем достаточно осторожны, оценивая размеры программ, организующих взаимодействие, то мы вскоре обнаружим, что получившаяся система 80 или 90 % времени тратит не на работу, а на это взаимодействие. Каждое подключение к сети независимого вычислителя (вычислительной машины или одиночного центрального процессора) усложняет связь между всеми остальными частями сети. Надо следить, чтобы эта сложность не затрудняла выполнение основной задачи системы — обработки данных.

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

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

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

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

Работа на основе ветвящейся структуры

Руководство и управление конфигурацией

Возможность слежения

Инспекторские проверки (сквозной контроль)

Управление качеством

Верификация

Тестирование

Выборочные прослушивания

Руководство проектом

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

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