Текст книги "Программное обеспечение и его разработка"

Автор книги: Джозеф Фокс

сообщить о нарушении

Текущая страница: 20 (всего у книги 21 страниц)

Мне не раз демонстрировали схемы, на которых указано, что «70 % затрат на программное обеспечение было сделано при его сопровождении». Это чрезмерное упрощение! Для очень большого числа программных систем это просто неправда.

Одна причина оптимистических оценок

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

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

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

Научные исследования в программном обеспечении

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

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

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

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

Отсутствие методов представления программ

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

Рис. 6.25. Различные воплощения планов и программ.

Вверху: Версия программы на машинном языке и в памяти машины

Внизу. Та же версия в мозгу ее создателя и в виде проекта на бумаге.

Многие предпочитают представлять себе программы как нечто статическое, при этом программы выглядят так же, как и многое другое записанное на бумагу. Они при этом приобретают некоторую осязаемость и материальность.

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

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

Тот факт, что программа может одновременно находиться в нескольких формах, оказывается источником путаницы. И не только источником путаницы для новичков, но также источником ошибок в реальных системах, в которых одна форма может подвергаться модификациям, в то время, как другая не изменяется. Через некоторое время при этом путаница может достигнуть невероятных размеров, никто не будет в состоянии понять, какая же версия программы настоящая, (см. рис. 6.25).

Разрабатывать программы так же, как и аппаратуру?

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

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

2. Взаимосвязи программного обеспечения неограниченны. Ограничениями аппаратуры являются законы физики. Столько-то объектов могут иметь столько-то взаимосвязей. С программным обеспечением дело обстоит не так.

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

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

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

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

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

Мы не увидим программы, если она достаточно велика, даже если тысячу раз на нее взглянем. Миллион строк текста программы умещается на двух с половиной километрах бумажной ленты! Будь мы хоть семи пядей во лбу, мы увидим только статическое представление. До своего вступления в действие, до того как она начнет выполняться, ее потоки, взаимодействия, соединения, границы и т. д. невидимы.

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

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

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

Тирания физических ограничений на взаимосвязи исчезла. Вплоть до появления запоминаемых команд, машинам объясняли, что они должны будут делать, с помощью их собственной физической конструкции. Если у этих машин были возможности по организации условных переходов, их можно было называть специализированными вычислительными машинами. Джон фон Нейман в меморандуме 1946 года указал, что до появления универсальных вычислительных машин, их предшественники «получали инструкции для работы с помощью конструкции». (Курсив мой.)

Физические ограничения запрещали многие возможные ветви или последовательности. Рояль можно считать аппаратурой, у него имеется 88 клавиш. Ноты – это команды пианисту, следуя которым он производит музыкальные звуки, а число различных сочетаний нот неограниченно. А понятие «правильности» весьма субъективно. То, что приятно одному, режет слух другому. Но все это – музыка.

Можно привести и другую аналогию – со словарем (аппаратурой) и романом – представляющим собой взаимосвязанные слова. Словарь точен и ограничен, даже если он очень большой. Но с помощью ограниченного числа слов мы можем написать команды для выполнения любых действий или создать неограниченное число произведений художественной литературы (см. табл. 6.8)

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

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

Таблица 6.8. Различия между аппаратурой и ее обеспечением

Ограниченные связи	Неограниченные связи
Аппаратура	Обеспечение
Рояль	Мелодии, музыка
Словарь	Романы, поэмы и т. д.
Пленка и проектор	Художественные фильмы
Вычислительная машина	Программы

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

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

В жизненном цикле программного обеспечения отсутствует фаза производства. Иногда в его жизненный цикл включается фаза сопровождения. Эти два факта оказывают огромное воздействие на всю экономику создания программного обеспечения в современном мире.

Сходство между аппаратурой и программным обеспечением

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

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

Глава 7
Некоторые новые важнейшие принципы вычислительной техники

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

Когда я возглавлял общее руководство группой программистов фирмы IBM, я узнал от руководителя группы внутренней обработки данных (мы работали над составлением платежной ведомости для 15 тысяч человек, разбросанных по всей стране), что нам нужно «купить» удаленную вычислительную машину, которая будет использоваться для разгрузки центральной машины, выполняя «удаленные вычисления». Я ответил: «Прекрасно, а теперь покажите мне, сколько мы на этом сэкономим». Мы провели три совещания общей продолжительностью в четыре с половиной часа и пришли к выводу, что денег нам на этом сэкономить не удастся, более того, возникнут дополнительные затраты, но зато «может» появиться некоторая «эффективность». Эффективность эта была несущественна (мое мнение). Предложение поэтому было отвергнуто. Этот случай показал мне, что мой руководитель внутренней обработки не может четко мыслить.

Многопроцессорная обработка и мультипрограммирование

Мультипрограммирование – это метод, применяемый в системном программировании для такого управления вычислительной машиной, при котором переключение с одной программы (например, составляющей платежную ведомость) на другую (занимающейся, к примеру, инвентаризацией) происходит без загрузки и откачки какой-либо из этих программ. Такой прием приводит к повышению уровня использования ЦП. Одновременно в памяти машины может располагаться несколько десятков программ, которые выполняются, периодически переключаясь с одной на другую. Тем самым резко уменьшается время простоев ЦП, вызванное ожиданием ответов от диска или другими действиями по вводу/выводу.

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

Два ЦП могут обладать и не одинаковыми возможностями. Для увеличения скорости решения задач один ЦП может делаться ведущим, а второй – вспомогательным, но при этом используются две разные операционные системы и, по нашему определению, нет никакой многопроцессорной обработки. Высокопроизводительный центральный процессор может соединяться с медленным ЦП, на котором, однако, имеется много разнообразных устройств ввода/вывода. Медленный ЦП будет выполнять все функции по обеспечению ввода/вывода, оставляя быстрому ЦП заботы по выполнению выстроенных в очередь заданий. Такой метод часто называется методом присоединенного вспомогательного процессора. С появлением мультипрограммных операционных систем этот метод применяется все реже.

Производительность при многопроцессорной обработке

Если в состав многопроцессорного комплекса входят машины в 1 МКС – каждая из них выполняет миллион команд в секунду – и у нас их четыре, мы, конечно же, получим систему в 4 МКС, не так ли? Нет, не так. Когда сразу несколько ЦП пытаются обратиться к одному блоку памяти, возникает эффект блокирования. В некоторых приложениях специально формулируются требования по синхронизации, позволяющие достичь целостности данных, когда несколько ЦП пытаются обратиться к одному файлу данных или к одной физической ячейке памяти. При этом может возникать некоторое снижение производительности, измерить которое и понять очень сложно. (См. рис. 7.1.)

Рис. 7.1. Производительность многопроцессорной системы

Если кто-то говорит, что такая-то и такая-то системы имеют по 16 ЦП, можно побиться об заклад, что либо 1) они работают с очень специальной задачей в крайне жестких граничных условиях, либо 2) такие системы не более чем любопытная лабораторная диковина, которая вряд ли может быть применена в настоящих приложениях. На путях внедрения 16-процессорных систем в практику универсальной обработки данных еще остается много препятствий.

Существуют, однако, и замечательные примеры применения многопроцессорных систем в системах реального времени. Система диспетчеризации авиалиний FAA имеет четыре процессора, четыре программируемых канала ввода/вывода и несколько десятков отдельных блоков памяти. В качестве многопроцессорной системы она начала работать более шести лет назад в 21 центре. Это очень дорогостоящая разработка, причем средства защиты от отказов (продолжения работы в более ограниченных условиях, когда часть аппаратуры отключается) еще до конца не запрограммированы. Но многопроцессорная обработка уже ведется.

Готовность

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

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

Для того чтобы определить, что надежнее – дублирование или многопроцессорность, разберем простой пример. Для простоты рассмотрим случай многопроцессорной системы всего с двумя блоками памяти и двумя ЦП, не обращая внимания на каналы ввода/вывода и другие детали. (См. рис. 7.2.) Единственная разница между системами состоит в том, что устройства памяти разделяются обоими процессорами (доступны им обоим). Следовательно, потеря одного ЦП в системе 1 и одного блока памяти в системе 2 не должна приводить к прекращению функционирования. Теперь нам надо представить себе, что мы хотим определить вероятность готовности системы к продолжению работы.

Рис. 7.2. Дублирование и многопроцессорная обработка.

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

Интуитивно может показаться очевидным, что многопроцессорная система имеет более высокий коэффициент готовности, но это не так, по крайней мере не всегда так. Нужно обязательно провести исследование и расчеты, очень длительные расчеты. В 1963 г. глубокое изучение этого вопроса, проведенное исследовательской группой IBM, созванной В. Пирсоном (вице-президент IBM, а затем председатель отделения) для того, чтобы ответить на запрос, поступивший из FAA, привело к созданию системы диспетчеризации авиалиний Соединенных Штатов.

Технический отдел IBM горячо доказывал, что в данном случае дублирование даст более хороший результат, система будет в более высокой степени готовности. В качестве предполагаемого руководителя выполнением заказа для FAA я спорил с ними, доказывая, что многопроцессорный вариант более надежен (исходные требования от FAA прямо приводили к многопроцессорной системе). Многие часы провели мы в исследовательском комитете. К моему удивлению, было выработано решение, в котором система с дублированием объявлялась более надежной. В тот зимний день 1963 г., проведенный в Поукипси, шт. Нью-Йорк, я просто отказывался верить своим ушам. Лирсон склонялся к тому, чтобы в IBM делали систему с дублированием. «Но ведь требования прямо ведут к многопроцессорности!» По некоторым причинам я никак не мог объяснить это Лирсону. Он спросил, все ли собравшиеся согласны с тем, что в требованиях есть предпосылки многопроцессорной системы. Все были согласны. Лирсон решил остановиться на многопроцессорном варианте. Наш проект был принят.

Причины многопроцессорной обработки

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

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

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

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

Целостность данных

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

Предположим, что на моем счете находится 575 долларов и у меня есть чек на 35 долларов, а у вас – на 100 долларов. Если баланс начну подводить я, то, увидев сумму 575 долларов, я должен буду производить вычитание из нее. Если в это же время вы тоже начнете производить вычитание из этой же суммы, мы ошибемся. Я получу результат в 500 долларов, а вы в 475 долларов. Кто бы ни написал в основной файл новое значение последним, он напишет неверное значение. В данном случае не была обеспечена целостность процесса. Мы не имеем права разрешать внесение изменений в основной файл более чем одному пользователю за раз. Значение баланса должно быть заблокировано все время, пока кто-то его изменяет. Это справедливо и для многих других типов данных – мест расположения самолетов, медицинских сведений и т. д. Это же относится и к сложным вычислительным комплексам. Мы должны следить за целостностью данных и в многопроцессорных системах, и в системах распределенной обработки данных, и в сетях.

Как мы это делаем? С помощью системных программ.

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

Аппаратные решения этих сложных конфигураций известны уже не один десяток лет. С аппаратурой у нас проблем нет.

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

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

Сети

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

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

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

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

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

Заказ на создание сети для фирмы General Motors

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

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

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

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

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

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

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