Страница:
творческой работы исследовать гораздо больше вариантов. Подключение
компьютеров к синтезаторам и программы, позволяющие автоматически записывать
или проигрывать ноты, значительно облегчают фиксацию бренчания по клавишам.
Цифровая обработка фотографий, как в Adobe Photoshop, позволяет в течение
считанных минут провести эксперименты, для которых потребовались часы работы
в фотолаборатории. Электронные таблицы позволяют легко исследовать десятки
альтернативных сценариев типа "что, если".
Наконец, благодаря вездесущести персональных компьютеров создается
совершенно новый материал. Гипертексты, предложенные Ванневаром Бушем в 1945
году, осуществимы только с помощью компьютеров.23 Мультимедийные презентации
и опыты были сложнейшими задачами - слишком много хлопот - до того, как
стало возможным проводить их с помощью компьютеров и соответствующего
богатого программного обеспечения. Системы виртуальной реальности, пока еще
дорогие и не широко распространенные, в будущем станут такими и создадут
новый материал для творчества.
Микрокомпьютерная революция изменила характер разработки программного
обеспечения. Технологии разработки программного обеспечения 1970-х сами
изменились в результате микрокомпьютерной революции и вызвавших ее
технических достижений. Устранена значительная часть второстепенных
сложностей технологий разработки программного обеспечения. Быстрые
персональные компьютеры стали обычным инструментом разработчика, и время
оборачиваемости стало почти устаревшим понятием. Сегодняшний персональный
компьютер быстрее не только суперкомпьютера 60-го года, но и Unix-станции
1985-го. Это значит, что компиляция быстро осуществляется даже на скромных
по мощности машинах, а благодаря большому объему памяти отпали задержки при
компоновке с использованием дисков. Большая память позволяет также хранить в
памяти таблицы символических имен вместе с объектным кодом, в результате
чего становится обычной высокоуровневая отладка без перекомпиляции.
За последние 20 лет мы почти покончили с использованием разделения
времени как методологией разработки программного обеспечения. В 1975 году
разделение времени только-только вытеснило пакетную обработку в качестве
наиболее распространенной технологии. Сеть использовалась для того, чтобы
дать разработчику программного обеспечения доступ как к общим файлам, так и
к большим вычислительным мощностям для компиляции, компоновки и
тестирования. Сегодня вычислительную мощность обеспечивает персональная
рабочая станция, а сеть используется в основном для обеспечения совместного
доступа к файлам бригады, разрабатывающей продукт. Клиент-серверные системы
меняют и упрощают технологию общего доступа для загрузки, сборки и
выполнения контрольных примеров.
Сходный прогресс произошел с пользовательскими интерфейсами. Интерфейс
WIMP обеспечивает гораздо большие удобства при редактировании текстов
программ и текстов на естественном языке. Экран размером 24 строки на 72
колонки сменился полностраничным или даже двухстраничным экраном, поэтому
программисты могут видеть изменения, которые они делают, в значительно более
широком контексте.
Целая новая программная отрасль - коробочные пакеты
Рядом с классической индустрией программных продуктов широко развилась
еще одна. Продажи программных продуктов числятся сотнями тысяч и даже
миллионами. Целые мощные пакеты можно приобрести по цене меньшей, чем
стоимость оплаты одного рабочего дня программиста. Эти две отрасли во многом
различны и существуют параллельно.
Классическая программная индустрия. В 1975 году программная индустрия
имела несколько отдельных и до некоторой степени различных составных частей,
существующих по сей день:
- Производители компьютеров, поставляющие также операционные системы,
компиляторы и утилиты для своих продуктов.
- Пользователи приложений, например, в информационно-управляющих
системах, банках, страховых компаниях, правительственных учреждениях,
создающие пакеты программ для собственного употребления.
- Разработчики заказных программ, работающие по контракту с
пользователем. Многие из этих подрядчиков специализируются на приложениях
для военной сферы, где требования, стандарты и маркетинговые процедуры носят
специфический характер.
- Разработчики коммерческих пакетов, в то время разрабатывавшие, в
основном, большие приложения для специфических рынков, такие как пакеты
статистического анализа и автоматического проектирования.
Том Демарко отмечает фрагментацию классической индустрии разработки
программного обеспечения, особенно в части пользователей приложений:
Я не ожидал, что эта область распадется на отдельные ниши. Приемы
работы в большей степени определяются нишей, чем использованием общих
методов анализа систем, языков программирования и технологий тестирования.
Ada был последним из языков общего назначения, и он стал языков ниши.
В нише обычных коммерческих приложений значительный вклад сделан
языками четвертого поколения (4GL). Бем пишет, что "наиболее удачные из 4GL
явились результатом написания какой-либо части области приложений на языке
опций и параметров". Наиболее широко распространенными из этих 4GL являются
генераторы приложений и комбинированные пакеты баз данных и связи с языками
запросов.
Миры операционных систем объединились. В 1975 году было изобили
операционных систем - у каждого производителя компьютеров была, по крайней
мере, одна патентованная операционная система для каждой производственной
серии, а часто и две. Насколько изменилось положение сегодня! Лозунгом дня
стали открытые системы, и осталось лишь пять главных операционных сред, для
которых создаются пакеты приложений (в хронологическом порядке):
- IBM MVS и VM
- DEC VMS
- Unix в том или ином варианте
- IBM PC, будь то DOS, OS/2 или Windows
- Apple Macintosh.
Индустрия коробочных продуктов. Экономические законы для разработчиков
в этой отрасли совершенно отличны от тех, которые действуют в классической
индустрии: стоимость разработки нужно делить на большое количество
экземпляров, расходы на упаковку и маркетинг высоки. В классической
индустрии при внутрифирменной разработке график работ и набор функций могли
быть изменены, в отличие от стоимости разработки. На открытом рынке жесткой
конкуренции сроки и функциональность полностью доминируют над затратами на
разработку.
Как и следовало ожидать, столь различные экономические требования
породили весьма различающиеся культуры программирования. В классической
индустрии лидирующее положение заняли крупные фирмы с установившимися
стилями управления и культурой работы. В коробочной индустрии, напротив,
возникли сотни начинающих фирм, ничем не связанных и сосредоточенных на
конечной цели, а не на процессе. В такой атмосфере талант отдельного
программиста всегда ценится значительно выше, и существует подспудное
ощущение, что выдающиеся проекты создаются выдающимися архитекторами. Во
вновь возникшей культуре есть возможность вознаграждать "звезд"
соответственно их вкладу. В классической индустрии социальная политика фирм
и их принципы оплаты труда всегда это затрудняли. Неудивительно поэтому, что
многие звезды нового поколения были втянуты в орбиту пакетной индустрии.
Покупай и создавай: коробочные продукты в качестве компонентов
Радикально улучшить устойчивость программных продуктов и производительность
труда при их создании можно, лишь поднявшись на один уровень и изготавливая
программы из модулей или объектов. Особенно многообещающей тенденцией
становится использование рыночных пакетов в качестве платформ, на которых
создаются более богатые и специализированные продукты. Система управления
движением грузовиков создается с помощью коробочной базы данных и
коммуникационного пакета, также как и информационная система для студентов.
Объявления в журналах предлагают сотни стеков для Hypercard,
специализированных шаблонов для Excel, десятки специальных функций на Pascal
для MiniCad или функций на AutoLisp для AutoCad.
Метапрограммирование. Стеки для Hypercard, специализированные шаблоны
для Excel, функции для MiniCad часто называют метапрограммированием,
созданием нового слоя, приспосабливающего функции к нуждам определенной
группы пользователей пакета. Идея метапрограммирования не нова, она
вернулась и получила свое название. В начале 60-х многие производители
компьютеров и вычислительные центры больших информационно-управляющих систем
образовывали небольшие группы специалистов, создававших целые языки
прикладного программирования с помощью макросов, написанных на ассемблере. В
вычислительном центре Eastman Kodak был создан язык прикладного
программирования на базе макроассемблера для IBM 7080. Аналогично, в
телекоммуникационной программе Queued Telecommunications Access Method для
IBM OS/360 можно было на многих страницах кода, написанного предположительно
на языке макроассемблера, не найти ни одной команды машинного уровня. Сейчас
блоки, создаваемые метапрограммистом, значительно больше, чем тогдашние
макроопределения. Такое развитие вторичного рынка очень обнадеживает: пока
мы ждали возникновения активного рынка классов C++, незаметно возник рынок
метапрограмм многократного использования.
Это действительно наступление на сущность. Поскольку на среднего
программиста информационно-управляющих систем феномен разработки на основе
пакетов еще не оказал воздействия, он пока не очень замечаем программной
инженерией. Тем не менее, это направление будет быстро развиваться,
поскольку затрагивает сущность моделирования концептуальных конструкций.
Коробочный пакет предоставляет большой функциональный модуль со сложным, но
точным интерфейсом, а его внутреннюю концептуальную структуру вовсе не
требуется проектировать. Программные продукты с функциями высокого уровня,
такие как Excel и 4th Dimension, действительно являются большими модулями,
но служат понятными, документированными, отлаженными модулями, с помощью
которых можно создавать заказные системы. Разработчики приложений следующего
уровня получают богатство функций, сокращение времени разработки, отлаженные
компоненты, улучшенную документацию и резко сниженную цену.
Сложность, конечно, в том, что коробочные пакеты разработаны как
самостоятельные объекты, функции и интерфейсы которых метапрограммисты не
могут изменить. Кроме того, более существенно то, что разработчики
коробочных пакетов, кажется, не слишком стремятся сделать свои продукты
пригодными в качестве модулей более крупных систем. Думаю, что такое
понимание неверно, и существует неудовлетворенный рынок для пакетов,
способствующих использованию метапрограммирования.
Так что же требуется? Можно выделить четыре уровня пользователей
коробочных продуктов:
- Пользователь как таковой, просто использующий приложение и
удовлетворенный функциями и интерфейсом, предоставленными разработчиками.
- Метапрограммист, строящий шаблоны и функции поверх отдельного
приложения с использованием имеющихся интерфейсов, главным образом, для
обеспечения труда конечного пользователя.
- Разработчик внешних функций, вводящий в приложение дополнительные
функции. Это, по сути, новые примитивы языка прикладного программирования,
обращающиеся к отдельным модулям, написанным на языке общего назначения.
Необходима возможность интерфейса этих новых функций с приложением через
перехватываемые команды, обратные вызовы или перегружаемые функции.
- Метапрограммист, использующий одно и, в особенности, несколько
приложений в качестве компонентов более крупной системы. Это пользователь,
чьи нужды сегодня слабо удовлетворяются. Это тот вид использования, который
обещает наибольший рост производительности при создании новых приложений.
Для этого последнего типа пользователей коробочный продукт должен иметь
дополнительный документированный интерфейс - интерфейс метапрограммирования.
Он должен предоставлять несколько возможностей. Прежде всего, метапрограмма
должна управлять ансамблем приложений, несмотря на то, что каждое
приложение, как правило, считает, что управляет самим собой. Этот ансамбль
должен управлять интерфейсом пользователя, хотя обычно само приложение
считает, что делает это. Ансамбль должен быть в состоянии вызвать любую
функцию приложения, как если бы его командная строка исходила от
пользователя. Выходные данных приложения должны передаваться ему, а не на
экран, причем в виде логических блоков подходящих типов данных, а не
текстовой строки, которую нужно отобразить. В некоторых приложениях,
например, FoxPro, есть дырочки, позволяющие передать командную строку, но
возвращаются скудные и неразобранные данные. Такая дырочка - заплатка на
скорую руку, в то время как требуется общее проработанное решение.
Большие возможности дало бы наличие языка сценариев для управления
взаимодействием приложений, входящих в ансамбль. Такого рода функции впервые
предоставила Unix с помощью каналов и стандарта файлов в формате
ASCII-строк. Сегодня неплохим решением является AppleScript.
Состояние и будущее программной инженерии
Однажды я попросил Джима Феррелла (Jim Ferrell), председателя химико-
технологического факультета университета штата Северная Каролина поведать о
развитии химических технологий вне связи с химией, на что он экспромтом
выдал мне замечательный рассказ, продолжавшийся час, начиная с
существовавших с античных времен различных производственных процессов для
многих продуктов - от стали до хлеба и парфюмерных изделий. Он рассказал,
как профессор Артур Д. Литтл (Arthur D. Little) в 1918 году основал в МТИ
факультет прикладной химии для исследования, разработки и обучения общим
фундаментальным технологиям всех процессов. Сначала были практические
правила, затем эмпирические номограммы, затем рецепты проектирования
отдельных компонентов, затем математические модели распространения тепла,
масс, количества движения в отдельных емкостях.
По ходу рассказа Феррелла я поразился обилию параллелей между
разработкой химических технологий и развитием программных технологий,
происходившим почти полвека спустя. Парнас утверждает, что я вообще пишу о
"программной инженерии". Он противопоставляет программотехнику как науку
электротехнику и считает, что называть наше занятие инженерией самонадеянно.
Возможно, он прав в том, что эта область никогда не станет инженерной
дисциплиной с такой точной и всеохватывающей основой, какая есть у
электротехники. В конце концов, программная инженерия, подобно химической
технологии, занята нелинейными задачами увеличения масштабов до промышленных
процессов и, подобно организации промышленного производства, постоянно
ставится в тупик сложностями человеческого поведения.
Тем не менее характер и временные рамки развития химической технологии
приводят меня к мысли, что программная инженерия в возрасте 27 лет не
столько безнадежна, сколько является незрелой, какой химическая
промышленность была в 1945 году. Лишь после Второй мировой войны
химики-технологи реально обратились к взаимосвязанным поточным системам с
замкнутым циклом.
Сегодня характерные задачи программной инженерии звучат точно так же,
как они изложены в главе 1:
- Как проектировать и строить программы, образующие системы.
- Как проектировать и строить программы и системы, являющиеся надежным,
отлаженным, документированным и сопровождаемым продуктом.
- Как осуществлять интеллектуальный контроль в условиях большой
сложности.
В смоляной яме программной инженерии еще долго придется вязнуть. Можно
ожидать, что человечество продолжит опыты с системами как внутри, так и за
пределами наших возможностей. Программные системы являются, возможно,
наиболее запутанными человеческими творениями. Это сложное ремесло требует
непрерывно развивать эту дисциплину, учиться создавать из более крупных
блоков, наилучшим образом использовать новые инструменты, старательно
осваивать опробованные методы управления инженерией, щедро использовать
здравый смысл и смиренно сознавать свою подверженность ошибкам и
ограниченность наших возможностей.
Эпилог Пятьдесят лет удивления, восхищения и радостиВ моей памяти все
еще живы удивление и восторг, с которым я - мне тогда было 13 лет - читал
отчет от 7 августа 1944 года об освящении компьютера Mark I, архитектором
которого был Говард Айкен (Howard Aiken), а проектировщиками - инженеры Клер
Лейк (Clair D. Lake), Бенджамин Дурфи (B. M. Durfee) и Фрэнсис Гамильтон (F.
E. Hamilton). Такой же вызывающей ощущение чуда была статья Ванневара Буша
(Vannevar Bush) "That We May Think" в апрельском 1945 года номере "Atlantic
Monthly", в которой он предложил организовать знания в виде огромной
гипертекстовой паутины и обеспечить пользователей машинами для переходов по
существующим ссылкам и создания новых ассоциативных следов.
Новый толчок моя страсть к компьютерам получила в 1952 году, когда,
работая летом на IBM в Эдинкоте, штат Нью-Йорк, я получил практический опыт
программирования для IBM 604 и формальное обучение программированию для IBM
701, их первой машины с хранимой программой. Аспирантура у Айкена и Иверсона
в Гарварде сделала реальностью мои мечты о профессии, и я связал с ней всю
свою жизнь. Немногим Бог дает право зарабатывать на жизнь тем, чем они с
радостью занимались бы по собственной воле, по увлечению. Я благодарен
судьбе.
Для человека, влюбленного в компьютеры, трудно было бы придумать иное
время, когда так радостно было жить. От механических устройств до вакуумных
ламп, транзисторов и интегральных схем шло бурное развитие технологии.
Первый компьютер, на котором я работал сразу после выпуска из Гарварда, был
суперкомпьютер IBM Stretch. Этот компьютер царствовал над миром как самый
быстрый с 1961 по 1964 годы; было изготовлено 9 экземпляров. Мой сегодняшний
Macintosh Powerbook не только быстрее, с большей памятью и большим диском,
но и в тысячу раз дешевле (в пять тысяч раз дешевле с учетом инфляции). Мы
были свидетелями того, как поочередно произошли компьютерная революция,
революция электронных компьютеров, революция миникомпьютеров и революция
микрокомпьютеров, в результате каждой из которых компьютеров становилось на
порядки больше.
Область связанных с компьютерами знаний претерпела взрыв, как и
соответствующая технология. Будучи аспирантом в середине 50-х, я мог
прочесть все журналы и труды конференций. Я мог оставаться на современном
уровне во всей научной дисциплине. Сегодня же мне в моей интеллектуальной
жизни приходится с сожалением расставаться с интересами то в одной, то в
другой подобласти, поскольку количество документов превысило всякую
возможность справиться с ними. Масса интересов, масса замечательных
возможностей для учебы, исследований, размышлений. Чудесное затруднение! Не
только конца не видно, но и шаг не замедляется. В будущем нас ожидают многие
радости.
Глава 1
1. А. П. Ершов полагает, что это не только печаль, но отчасти и
радость. A. P. Ershov. Aesthetics and the human factor in programming //
CACM. 1972. Vol. 15, N 7. July. P. 501-505
Глава 2
1. В. А. Высоцкий из Bell Telephone Laboratories считает, что большой
проект может выдержать до 30% прироста числа сотрудников в год. При большем
увеличении затрудняется и даже подавляется развитие важной неформальной
структуры и ее коммуникационных связей, о чем говорится в главе 7. Ф. Дж.
Корбато из МТИ отмечает, что в длительном проекте следует ожидать ежегодной
смены 20% сотрудников, и новые работники должны как получить техническую
подготовку, так и влиться в формальную структуру.
2. Ч. Портман из International Computers Limited говорит: "Если все
работает и объединено в систему, значит, осталось работы на четыре месяца".
Некоторые другие способы распределения графика приведены в статье: Wolverton
R. W. The cost of developing large-scale software // IEEE Trans. on
Computers. 1974. Vol. C-23, N 6. June. P. 615-636.
3. Рисунками 2.5-2.8 я обязан Джерри Огдину, который, цитируя мой
пример из более ранней публикации этой главы, значительно улучшил
иллюстрации. Ogdin, J. L. The Mongolian hordes versus superprogrammer //
Infosystems. 1972. Dec. P. 20-23.
Глава 3
1. Sackman H., Erikson W. J., Grant E. E. Exploratory experimentation
studies comparing online and offline programming performance // CACM. 1968.
Vol. 11, N 1. Jan. P. 3-11.
2. Mills H. Chief programmer team, principles, and procedures // IBM
Federal Systems Division Report FSC 71-5108. Gaithersburg, Md., 1971.
3. Baker F. T. Chief programmer team management of production
programming // IBM Sys. J. 1972. Vol. 11, N 1.
Глава 4
1. Eschapasse M. Reims Cathedral, Caisse Nationale des Monuments
Histiriques. Paris, 1967.
2. Brooks F. P. Architectural Philosophy // Buchholz W. (Ed.). Planning
a Computer System. New York: McGraw-Hill, 1962.
3. Blaauw G. A. Hardware requirements for the fourth generation //
Gruenberger F. (ed.). Fourth Generation Computers. Englewood Cliffs, N. J.:
Prentice-Hall, 1970.
4. Brooks F. P., Iverson K. E. Automatic Data Processing, System/360
Edition. New York: Wiley, 1969. Ch. 5.
5. Glegg G. L. The Design of Design. Cambridge : Cambridge Univ. Press,
1969: "На первый взгляд кажется, что мысль о том, чтобы наложить на
творческий ум какие-то правила или принципы, скорее помешает ему, чем окажет
помощь, но на практике это совершенно неверно. Дисциплинированное мышление
скорее концентрирует вдохновение, чем подавляет его".
6. Conway R. W. The PL/C Compiler // Proceedings of a Conf. on
Definition and Implementation of Universal Programming Languages. Stuttgard,
1970.
7. Хорошее обсуждение необходимости программных технологий см.:
Reynolds C. H. Whats wrong with computer programming management? // Weinwurm
G. F. (Ed.). On the Management of Computer Programming. Philadelphia :
Auerbach, 1971. P. 35-42.
Глава 5
1. Strachey C. Review of Planning a Computer System // Comp. J. 1962.
Vol. 5, N 2. July. P. 152-153.
2. Это относится только к управляющим программам. Некоторые бригады,
разрабатывающие компиляторы для проекта OS/360, создавали уже свой третий
или четвертый продукт, и отличное качество их продуктов это подтверждает.
3. Shell D. L. The Share 709 system: a cooperative effort; Greenwald I.
D., Kane M. The Share 709 system: programming and modification; Boehm E. M.,
Steel T. B., Jr. The Share 709 system: machine implementation of symbolic
programming. Все статьи // JACM. 1959. Vol. 6, N 2. Apr. P. 123-140.
Глава 6
1. Neustadt R. E. Presidential Power. New York: Wiley, 1960. Ch. 2.
2. Backus J. W. The syntax and semantics of the proposed international
algebraic language // Proc. Intl. Conf. Inf. Proc. UNESCO, Paris, 1959 //
Oldenbourg R., Munich and Butterworth. (Eds.). London. Кроме того, целая
подборка статей на эту тему содержится в: Steel T. B., Jr. (Ed.). Formal
Language Description Languages for Computer Programming. Amsterdam: North
Holland, 1966.
3. Lucas P., Walk K. On the formal description of PL/I // Annual Review
in Automatic Programming Language. New York: Wiley, 1962. Ch. 2. P. 2.
4. Iverson K. E. A Programming Language. New York: Wiley, 1962. Ch. 2.
5. Falkoff A. D., Iverson K. E., Sussenguth E. H. A formal description
of System/360 // IBM Systems Journal. 1964. Vol. 3, N 3. P. 198-261.
6. Bell C. G., Newell A. Computer Structures. New York: McGraw-Hill,
1970. P. 120- 136, 517-541.
7. Bell C. G. Частное сообщение.
Глава 7
1. Parnas D. L. Information distribution aspects of design
methodology. Carnegie- Mellon Univ., Dept. Of Computer Science Technical
Report. 1971. February.
2. Copyright 1939, 1940 Street & Smith Publications; Copyright
1950, 1967 Роберта А. Хайнлайна (Robert A. Heinlein). Публикуется по
соглашению с Spectrum Literary Agency.
Глава 8
1. Sackman H., Erikson W. J., Grant E. E. Exploratory experimentation
studies comparing online and offline programming performance // CACM. 1968.
Vol. 11, N 1. Jan. P. 3-11.
2. Nanus B., Farr L. Some cost contributors to large-scale programs //
AFIPS Proc. SJCC. Spring 1964. Vol. 25. P. 239-248.
3. Weinwurm G. F. Research in the management of computer programming //
Report SP-2059, System Development Corp. Santa Monica, 1965.
4. Morin L. H. Estimation of resources for computer programming
projects // M. S. thesis. Chapel Hill: Univ. Of North Carolina, 1974.
5. Portman C. Частное сообщение.
6. В неопубликованном исследовании 1964 года, которое провел E. F.
Bardain, показано, что программисты продуктивно используют 27% рабочего
времени. (Процитировано в: Mayer D. B., Stalnaker A. W. Selection and
evaluation of computer personnel // Proc. 23d ACM Conf., 1968. P. 661.)
7. Aron J. Частное сообщение.
8. Доклад, сделанный на совещании и включенный в AFIPS Proceedings.
9. Wolverton R. W. The cost of developing large-scale software // IEEE
Trans. On Computers. 1974. Vol. C-23, N 6. June. P. 615-636. В этой недавней
важной статье содержатся данные по многим вопросам, обсуждаемым в этой
главе, также подтверждающие выводы о производительности труда.
10. Corbato F. J. Sensitive issues in the design of multi-use systems
// Лекция на открытии Технологического центра электронной обработки данных
компании Honeywell, 1968.
11. W. M. Taliaffero также сообщает о постоянной проиводительности 2400
операторов в год на ассмблере, Fortran и Cobol. См.: Modularity. The key to
system growth potential // Software. 1971. Vol. 1, N 3. July. P. 245-257.
12. В отчете Report TM-3225, Management Handbook for Estimation of
Computer Programming Costs (Nelson E. A. из System Development Corp.)
говорится о росте производительности 3:1 при использовании языка высокого
уровня (стр. 66-67), хотя дисперсия высока.
Глава 9
1. Brooks F. P., Iverson K. E. Automatic Data Processing, System/360
Edition. New York: Wiley, 1969. Ch. 6.
2. Knuth D. E. The Art of Computer Programming. Vols. 1-3. Reading,
Mass.: Addison-Wesley, 1968. ff.
Глава 10
1. Conway M. E. How do committees invent? // Datamation. 1968. Vol.
14, N 4. Apr. P. 28-31.
Глава 11
1. Речь в Оглеторпском университете 22 мая 1932 года.
2. Поучительный отчет об опыте использования MULTICS для создания двух
систем имеется в: Corbaty F. J., Saltzer J. H., Clingen C. T. MULTICS - the
first seven years // AFIPS Proc SJCC. 1972. Vol. 40. P. 571-583.
3. Cosgrove J. Needed: a new planning framework // Datamation. 1971.
Vol. 17, N 23. Dec. P. 37-39.
4. Изменение проекта - сложная проблема, и здесь я ее чрезмерно
упрощаю. См.: Saltzer J. H. Evolutionary design of complex systems // Eckman
D. (Ed.). Systems : Research and Design. New York : Wiley, 1961. Все же,
когда все сказано и сделано, я советую создать опытную систему, которую
планируется выбросить.
5. Campbell E. Report to the AEC Computer Information Meeting. 1970.
Dec. Это явление обсуждается также в: Ordin J. L. Designing reliable
компьютеров к синтезаторам и программы, позволяющие автоматически записывать
или проигрывать ноты, значительно облегчают фиксацию бренчания по клавишам.
Цифровая обработка фотографий, как в Adobe Photoshop, позволяет в течение
считанных минут провести эксперименты, для которых потребовались часы работы
в фотолаборатории. Электронные таблицы позволяют легко исследовать десятки
альтернативных сценариев типа "что, если".
Наконец, благодаря вездесущести персональных компьютеров создается
совершенно новый материал. Гипертексты, предложенные Ванневаром Бушем в 1945
году, осуществимы только с помощью компьютеров.23 Мультимедийные презентации
и опыты были сложнейшими задачами - слишком много хлопот - до того, как
стало возможным проводить их с помощью компьютеров и соответствующего
богатого программного обеспечения. Системы виртуальной реальности, пока еще
дорогие и не широко распространенные, в будущем станут такими и создадут
новый материал для творчества.
Микрокомпьютерная революция изменила характер разработки программного
обеспечения. Технологии разработки программного обеспечения 1970-х сами
изменились в результате микрокомпьютерной революции и вызвавших ее
технических достижений. Устранена значительная часть второстепенных
сложностей технологий разработки программного обеспечения. Быстрые
персональные компьютеры стали обычным инструментом разработчика, и время
оборачиваемости стало почти устаревшим понятием. Сегодняшний персональный
компьютер быстрее не только суперкомпьютера 60-го года, но и Unix-станции
1985-го. Это значит, что компиляция быстро осуществляется даже на скромных
по мощности машинах, а благодаря большому объему памяти отпали задержки при
компоновке с использованием дисков. Большая память позволяет также хранить в
памяти таблицы символических имен вместе с объектным кодом, в результате
чего становится обычной высокоуровневая отладка без перекомпиляции.
За последние 20 лет мы почти покончили с использованием разделения
времени как методологией разработки программного обеспечения. В 1975 году
разделение времени только-только вытеснило пакетную обработку в качестве
наиболее распространенной технологии. Сеть использовалась для того, чтобы
дать разработчику программного обеспечения доступ как к общим файлам, так и
к большим вычислительным мощностям для компиляции, компоновки и
тестирования. Сегодня вычислительную мощность обеспечивает персональная
рабочая станция, а сеть используется в основном для обеспечения совместного
доступа к файлам бригады, разрабатывающей продукт. Клиент-серверные системы
меняют и упрощают технологию общего доступа для загрузки, сборки и
выполнения контрольных примеров.
Сходный прогресс произошел с пользовательскими интерфейсами. Интерфейс
WIMP обеспечивает гораздо большие удобства при редактировании текстов
программ и текстов на естественном языке. Экран размером 24 строки на 72
колонки сменился полностраничным или даже двухстраничным экраном, поэтому
программисты могут видеть изменения, которые они делают, в значительно более
широком контексте.
Целая новая программная отрасль - коробочные пакеты
Рядом с классической индустрией программных продуктов широко развилась
еще одна. Продажи программных продуктов числятся сотнями тысяч и даже
миллионами. Целые мощные пакеты можно приобрести по цене меньшей, чем
стоимость оплаты одного рабочего дня программиста. Эти две отрасли во многом
различны и существуют параллельно.
Классическая программная индустрия. В 1975 году программная индустрия
имела несколько отдельных и до некоторой степени различных составных частей,
существующих по сей день:
- Производители компьютеров, поставляющие также операционные системы,
компиляторы и утилиты для своих продуктов.
- Пользователи приложений, например, в информационно-управляющих
системах, банках, страховых компаниях, правительственных учреждениях,
создающие пакеты программ для собственного употребления.
- Разработчики заказных программ, работающие по контракту с
пользователем. Многие из этих подрядчиков специализируются на приложениях
для военной сферы, где требования, стандарты и маркетинговые процедуры носят
специфический характер.
- Разработчики коммерческих пакетов, в то время разрабатывавшие, в
основном, большие приложения для специфических рынков, такие как пакеты
статистического анализа и автоматического проектирования.
Том Демарко отмечает фрагментацию классической индустрии разработки
программного обеспечения, особенно в части пользователей приложений:
Я не ожидал, что эта область распадется на отдельные ниши. Приемы
работы в большей степени определяются нишей, чем использованием общих
методов анализа систем, языков программирования и технологий тестирования.
Ada был последним из языков общего назначения, и он стал языков ниши.
В нише обычных коммерческих приложений значительный вклад сделан
языками четвертого поколения (4GL). Бем пишет, что "наиболее удачные из 4GL
явились результатом написания какой-либо части области приложений на языке
опций и параметров". Наиболее широко распространенными из этих 4GL являются
генераторы приложений и комбинированные пакеты баз данных и связи с языками
запросов.
Миры операционных систем объединились. В 1975 году было изобили
операционных систем - у каждого производителя компьютеров была, по крайней
мере, одна патентованная операционная система для каждой производственной
серии, а часто и две. Насколько изменилось положение сегодня! Лозунгом дня
стали открытые системы, и осталось лишь пять главных операционных сред, для
которых создаются пакеты приложений (в хронологическом порядке):
- IBM MVS и VM
- DEC VMS
- Unix в том или ином варианте
- IBM PC, будь то DOS, OS/2 или Windows
- Apple Macintosh.
Индустрия коробочных продуктов. Экономические законы для разработчиков
в этой отрасли совершенно отличны от тех, которые действуют в классической
индустрии: стоимость разработки нужно делить на большое количество
экземпляров, расходы на упаковку и маркетинг высоки. В классической
индустрии при внутрифирменной разработке график работ и набор функций могли
быть изменены, в отличие от стоимости разработки. На открытом рынке жесткой
конкуренции сроки и функциональность полностью доминируют над затратами на
разработку.
Как и следовало ожидать, столь различные экономические требования
породили весьма различающиеся культуры программирования. В классической
индустрии лидирующее положение заняли крупные фирмы с установившимися
стилями управления и культурой работы. В коробочной индустрии, напротив,
возникли сотни начинающих фирм, ничем не связанных и сосредоточенных на
конечной цели, а не на процессе. В такой атмосфере талант отдельного
программиста всегда ценится значительно выше, и существует подспудное
ощущение, что выдающиеся проекты создаются выдающимися архитекторами. Во
вновь возникшей культуре есть возможность вознаграждать "звезд"
соответственно их вкладу. В классической индустрии социальная политика фирм
и их принципы оплаты труда всегда это затрудняли. Неудивительно поэтому, что
многие звезды нового поколения были втянуты в орбиту пакетной индустрии.
Покупай и создавай: коробочные продукты в качестве компонентов
Радикально улучшить устойчивость программных продуктов и производительность
труда при их создании можно, лишь поднявшись на один уровень и изготавливая
программы из модулей или объектов. Особенно многообещающей тенденцией
становится использование рыночных пакетов в качестве платформ, на которых
создаются более богатые и специализированные продукты. Система управления
движением грузовиков создается с помощью коробочной базы данных и
коммуникационного пакета, также как и информационная система для студентов.
Объявления в журналах предлагают сотни стеков для Hypercard,
специализированных шаблонов для Excel, десятки специальных функций на Pascal
для MiniCad или функций на AutoLisp для AutoCad.
Метапрограммирование. Стеки для Hypercard, специализированные шаблоны
для Excel, функции для MiniCad часто называют метапрограммированием,
созданием нового слоя, приспосабливающего функции к нуждам определенной
группы пользователей пакета. Идея метапрограммирования не нова, она
вернулась и получила свое название. В начале 60-х многие производители
компьютеров и вычислительные центры больших информационно-управляющих систем
образовывали небольшие группы специалистов, создававших целые языки
прикладного программирования с помощью макросов, написанных на ассемблере. В
вычислительном центре Eastman Kodak был создан язык прикладного
программирования на базе макроассемблера для IBM 7080. Аналогично, в
телекоммуникационной программе Queued Telecommunications Access Method для
IBM OS/360 можно было на многих страницах кода, написанного предположительно
на языке макроассемблера, не найти ни одной команды машинного уровня. Сейчас
блоки, создаваемые метапрограммистом, значительно больше, чем тогдашние
макроопределения. Такое развитие вторичного рынка очень обнадеживает: пока
мы ждали возникновения активного рынка классов C++, незаметно возник рынок
метапрограмм многократного использования.
Это действительно наступление на сущность. Поскольку на среднего
программиста информационно-управляющих систем феномен разработки на основе
пакетов еще не оказал воздействия, он пока не очень замечаем программной
инженерией. Тем не менее, это направление будет быстро развиваться,
поскольку затрагивает сущность моделирования концептуальных конструкций.
Коробочный пакет предоставляет большой функциональный модуль со сложным, но
точным интерфейсом, а его внутреннюю концептуальную структуру вовсе не
требуется проектировать. Программные продукты с функциями высокого уровня,
такие как Excel и 4th Dimension, действительно являются большими модулями,
но служат понятными, документированными, отлаженными модулями, с помощью
которых можно создавать заказные системы. Разработчики приложений следующего
уровня получают богатство функций, сокращение времени разработки, отлаженные
компоненты, улучшенную документацию и резко сниженную цену.
Сложность, конечно, в том, что коробочные пакеты разработаны как
самостоятельные объекты, функции и интерфейсы которых метапрограммисты не
могут изменить. Кроме того, более существенно то, что разработчики
коробочных пакетов, кажется, не слишком стремятся сделать свои продукты
пригодными в качестве модулей более крупных систем. Думаю, что такое
понимание неверно, и существует неудовлетворенный рынок для пакетов,
способствующих использованию метапрограммирования.
Так что же требуется? Можно выделить четыре уровня пользователей
коробочных продуктов:
- Пользователь как таковой, просто использующий приложение и
удовлетворенный функциями и интерфейсом, предоставленными разработчиками.
- Метапрограммист, строящий шаблоны и функции поверх отдельного
приложения с использованием имеющихся интерфейсов, главным образом, для
обеспечения труда конечного пользователя.
- Разработчик внешних функций, вводящий в приложение дополнительные
функции. Это, по сути, новые примитивы языка прикладного программирования,
обращающиеся к отдельным модулям, написанным на языке общего назначения.
Необходима возможность интерфейса этих новых функций с приложением через
перехватываемые команды, обратные вызовы или перегружаемые функции.
- Метапрограммист, использующий одно и, в особенности, несколько
приложений в качестве компонентов более крупной системы. Это пользователь,
чьи нужды сегодня слабо удовлетворяются. Это тот вид использования, который
обещает наибольший рост производительности при создании новых приложений.
Для этого последнего типа пользователей коробочный продукт должен иметь
дополнительный документированный интерфейс - интерфейс метапрограммирования.
Он должен предоставлять несколько возможностей. Прежде всего, метапрограмма
должна управлять ансамблем приложений, несмотря на то, что каждое
приложение, как правило, считает, что управляет самим собой. Этот ансамбль
должен управлять интерфейсом пользователя, хотя обычно само приложение
считает, что делает это. Ансамбль должен быть в состоянии вызвать любую
функцию приложения, как если бы его командная строка исходила от
пользователя. Выходные данных приложения должны передаваться ему, а не на
экран, причем в виде логических блоков подходящих типов данных, а не
текстовой строки, которую нужно отобразить. В некоторых приложениях,
например, FoxPro, есть дырочки, позволяющие передать командную строку, но
возвращаются скудные и неразобранные данные. Такая дырочка - заплатка на
скорую руку, в то время как требуется общее проработанное решение.
Большие возможности дало бы наличие языка сценариев для управления
взаимодействием приложений, входящих в ансамбль. Такого рода функции впервые
предоставила Unix с помощью каналов и стандарта файлов в формате
ASCII-строк. Сегодня неплохим решением является AppleScript.
Состояние и будущее программной инженерии
Однажды я попросил Джима Феррелла (Jim Ferrell), председателя химико-
технологического факультета университета штата Северная Каролина поведать о
развитии химических технологий вне связи с химией, на что он экспромтом
выдал мне замечательный рассказ, продолжавшийся час, начиная с
существовавших с античных времен различных производственных процессов для
многих продуктов - от стали до хлеба и парфюмерных изделий. Он рассказал,
как профессор Артур Д. Литтл (Arthur D. Little) в 1918 году основал в МТИ
факультет прикладной химии для исследования, разработки и обучения общим
фундаментальным технологиям всех процессов. Сначала были практические
правила, затем эмпирические номограммы, затем рецепты проектирования
отдельных компонентов, затем математические модели распространения тепла,
масс, количества движения в отдельных емкостях.
По ходу рассказа Феррелла я поразился обилию параллелей между
разработкой химических технологий и развитием программных технологий,
происходившим почти полвека спустя. Парнас утверждает, что я вообще пишу о
"программной инженерии". Он противопоставляет программотехнику как науку
электротехнику и считает, что называть наше занятие инженерией самонадеянно.
Возможно, он прав в том, что эта область никогда не станет инженерной
дисциплиной с такой точной и всеохватывающей основой, какая есть у
электротехники. В конце концов, программная инженерия, подобно химической
технологии, занята нелинейными задачами увеличения масштабов до промышленных
процессов и, подобно организации промышленного производства, постоянно
ставится в тупик сложностями человеческого поведения.
Тем не менее характер и временные рамки развития химической технологии
приводят меня к мысли, что программная инженерия в возрасте 27 лет не
столько безнадежна, сколько является незрелой, какой химическая
промышленность была в 1945 году. Лишь после Второй мировой войны
химики-технологи реально обратились к взаимосвязанным поточным системам с
замкнутым циклом.
Сегодня характерные задачи программной инженерии звучат точно так же,
как они изложены в главе 1:
- Как проектировать и строить программы, образующие системы.
- Как проектировать и строить программы и системы, являющиеся надежным,
отлаженным, документированным и сопровождаемым продуктом.
- Как осуществлять интеллектуальный контроль в условиях большой
сложности.
В смоляной яме программной инженерии еще долго придется вязнуть. Можно
ожидать, что человечество продолжит опыты с системами как внутри, так и за
пределами наших возможностей. Программные системы являются, возможно,
наиболее запутанными человеческими творениями. Это сложное ремесло требует
непрерывно развивать эту дисциплину, учиться создавать из более крупных
блоков, наилучшим образом использовать новые инструменты, старательно
осваивать опробованные методы управления инженерией, щедро использовать
здравый смысл и смиренно сознавать свою подверженность ошибкам и
ограниченность наших возможностей.
Эпилог Пятьдесят лет удивления, восхищения и радостиВ моей памяти все
еще живы удивление и восторг, с которым я - мне тогда было 13 лет - читал
отчет от 7 августа 1944 года об освящении компьютера Mark I, архитектором
которого был Говард Айкен (Howard Aiken), а проектировщиками - инженеры Клер
Лейк (Clair D. Lake), Бенджамин Дурфи (B. M. Durfee) и Фрэнсис Гамильтон (F.
E. Hamilton). Такой же вызывающей ощущение чуда была статья Ванневара Буша
(Vannevar Bush) "That We May Think" в апрельском 1945 года номере "Atlantic
Monthly", в которой он предложил организовать знания в виде огромной
гипертекстовой паутины и обеспечить пользователей машинами для переходов по
существующим ссылкам и создания новых ассоциативных следов.
Новый толчок моя страсть к компьютерам получила в 1952 году, когда,
работая летом на IBM в Эдинкоте, штат Нью-Йорк, я получил практический опыт
программирования для IBM 604 и формальное обучение программированию для IBM
701, их первой машины с хранимой программой. Аспирантура у Айкена и Иверсона
в Гарварде сделала реальностью мои мечты о профессии, и я связал с ней всю
свою жизнь. Немногим Бог дает право зарабатывать на жизнь тем, чем они с
радостью занимались бы по собственной воле, по увлечению. Я благодарен
судьбе.
Для человека, влюбленного в компьютеры, трудно было бы придумать иное
время, когда так радостно было жить. От механических устройств до вакуумных
ламп, транзисторов и интегральных схем шло бурное развитие технологии.
Первый компьютер, на котором я работал сразу после выпуска из Гарварда, был
суперкомпьютер IBM Stretch. Этот компьютер царствовал над миром как самый
быстрый с 1961 по 1964 годы; было изготовлено 9 экземпляров. Мой сегодняшний
Macintosh Powerbook не только быстрее, с большей памятью и большим диском,
но и в тысячу раз дешевле (в пять тысяч раз дешевле с учетом инфляции). Мы
были свидетелями того, как поочередно произошли компьютерная революция,
революция электронных компьютеров, революция миникомпьютеров и революция
микрокомпьютеров, в результате каждой из которых компьютеров становилось на
порядки больше.
Область связанных с компьютерами знаний претерпела взрыв, как и
соответствующая технология. Будучи аспирантом в середине 50-х, я мог
прочесть все журналы и труды конференций. Я мог оставаться на современном
уровне во всей научной дисциплине. Сегодня же мне в моей интеллектуальной
жизни приходится с сожалением расставаться с интересами то в одной, то в
другой подобласти, поскольку количество документов превысило всякую
возможность справиться с ними. Масса интересов, масса замечательных
возможностей для учебы, исследований, размышлений. Чудесное затруднение! Не
только конца не видно, но и шаг не замедляется. В будущем нас ожидают многие
радости.
Глава 1
1. А. П. Ершов полагает, что это не только печаль, но отчасти и
радость. A. P. Ershov. Aesthetics and the human factor in programming //
CACM. 1972. Vol. 15, N 7. July. P. 501-505
Глава 2
1. В. А. Высоцкий из Bell Telephone Laboratories считает, что большой
проект может выдержать до 30% прироста числа сотрудников в год. При большем
увеличении затрудняется и даже подавляется развитие важной неформальной
структуры и ее коммуникационных связей, о чем говорится в главе 7. Ф. Дж.
Корбато из МТИ отмечает, что в длительном проекте следует ожидать ежегодной
смены 20% сотрудников, и новые работники должны как получить техническую
подготовку, так и влиться в формальную структуру.
2. Ч. Портман из International Computers Limited говорит: "Если все
работает и объединено в систему, значит, осталось работы на четыре месяца".
Некоторые другие способы распределения графика приведены в статье: Wolverton
R. W. The cost of developing large-scale software // IEEE Trans. on
Computers. 1974. Vol. C-23, N 6. June. P. 615-636.
3. Рисунками 2.5-2.8 я обязан Джерри Огдину, который, цитируя мой
пример из более ранней публикации этой главы, значительно улучшил
иллюстрации. Ogdin, J. L. The Mongolian hordes versus superprogrammer //
Infosystems. 1972. Dec. P. 20-23.
Глава 3
1. Sackman H., Erikson W. J., Grant E. E. Exploratory experimentation
studies comparing online and offline programming performance // CACM. 1968.
Vol. 11, N 1. Jan. P. 3-11.
2. Mills H. Chief programmer team, principles, and procedures // IBM
Federal Systems Division Report FSC 71-5108. Gaithersburg, Md., 1971.
3. Baker F. T. Chief programmer team management of production
programming // IBM Sys. J. 1972. Vol. 11, N 1.
Глава 4
1. Eschapasse M. Reims Cathedral, Caisse Nationale des Monuments
Histiriques. Paris, 1967.
2. Brooks F. P. Architectural Philosophy // Buchholz W. (Ed.). Planning
a Computer System. New York: McGraw-Hill, 1962.
3. Blaauw G. A. Hardware requirements for the fourth generation //
Gruenberger F. (ed.). Fourth Generation Computers. Englewood Cliffs, N. J.:
Prentice-Hall, 1970.
4. Brooks F. P., Iverson K. E. Automatic Data Processing, System/360
Edition. New York: Wiley, 1969. Ch. 5.
5. Glegg G. L. The Design of Design. Cambridge : Cambridge Univ. Press,
1969: "На первый взгляд кажется, что мысль о том, чтобы наложить на
творческий ум какие-то правила или принципы, скорее помешает ему, чем окажет
помощь, но на практике это совершенно неверно. Дисциплинированное мышление
скорее концентрирует вдохновение, чем подавляет его".
6. Conway R. W. The PL/C Compiler // Proceedings of a Conf. on
Definition and Implementation of Universal Programming Languages. Stuttgard,
1970.
7. Хорошее обсуждение необходимости программных технологий см.:
Reynolds C. H. Whats wrong with computer programming management? // Weinwurm
G. F. (Ed.). On the Management of Computer Programming. Philadelphia :
Auerbach, 1971. P. 35-42.
Глава 5
1. Strachey C. Review of Planning a Computer System // Comp. J. 1962.
Vol. 5, N 2. July. P. 152-153.
2. Это относится только к управляющим программам. Некоторые бригады,
разрабатывающие компиляторы для проекта OS/360, создавали уже свой третий
или четвертый продукт, и отличное качество их продуктов это подтверждает.
3. Shell D. L. The Share 709 system: a cooperative effort; Greenwald I.
D., Kane M. The Share 709 system: programming and modification; Boehm E. M.,
Steel T. B., Jr. The Share 709 system: machine implementation of symbolic
programming. Все статьи // JACM. 1959. Vol. 6, N 2. Apr. P. 123-140.
Глава 6
1. Neustadt R. E. Presidential Power. New York: Wiley, 1960. Ch. 2.
2. Backus J. W. The syntax and semantics of the proposed international
algebraic language // Proc. Intl. Conf. Inf. Proc. UNESCO, Paris, 1959 //
Oldenbourg R., Munich and Butterworth. (Eds.). London. Кроме того, целая
подборка статей на эту тему содержится в: Steel T. B., Jr. (Ed.). Formal
Language Description Languages for Computer Programming. Amsterdam: North
Holland, 1966.
3. Lucas P., Walk K. On the formal description of PL/I // Annual Review
in Automatic Programming Language. New York: Wiley, 1962. Ch. 2. P. 2.
4. Iverson K. E. A Programming Language. New York: Wiley, 1962. Ch. 2.
5. Falkoff A. D., Iverson K. E., Sussenguth E. H. A formal description
of System/360 // IBM Systems Journal. 1964. Vol. 3, N 3. P. 198-261.
6. Bell C. G., Newell A. Computer Structures. New York: McGraw-Hill,
1970. P. 120- 136, 517-541.
7. Bell C. G. Частное сообщение.
Глава 7
1. Parnas D. L. Information distribution aspects of design
methodology. Carnegie- Mellon Univ., Dept. Of Computer Science Technical
Report. 1971. February.
2. Copyright 1939, 1940 Street & Smith Publications; Copyright
1950, 1967 Роберта А. Хайнлайна (Robert A. Heinlein). Публикуется по
соглашению с Spectrum Literary Agency.
Глава 8
1. Sackman H., Erikson W. J., Grant E. E. Exploratory experimentation
studies comparing online and offline programming performance // CACM. 1968.
Vol. 11, N 1. Jan. P. 3-11.
2. Nanus B., Farr L. Some cost contributors to large-scale programs //
AFIPS Proc. SJCC. Spring 1964. Vol. 25. P. 239-248.
3. Weinwurm G. F. Research in the management of computer programming //
Report SP-2059, System Development Corp. Santa Monica, 1965.
4. Morin L. H. Estimation of resources for computer programming
projects // M. S. thesis. Chapel Hill: Univ. Of North Carolina, 1974.
5. Portman C. Частное сообщение.
6. В неопубликованном исследовании 1964 года, которое провел E. F.
Bardain, показано, что программисты продуктивно используют 27% рабочего
времени. (Процитировано в: Mayer D. B., Stalnaker A. W. Selection and
evaluation of computer personnel // Proc. 23d ACM Conf., 1968. P. 661.)
7. Aron J. Частное сообщение.
8. Доклад, сделанный на совещании и включенный в AFIPS Proceedings.
9. Wolverton R. W. The cost of developing large-scale software // IEEE
Trans. On Computers. 1974. Vol. C-23, N 6. June. P. 615-636. В этой недавней
важной статье содержатся данные по многим вопросам, обсуждаемым в этой
главе, также подтверждающие выводы о производительности труда.
10. Corbato F. J. Sensitive issues in the design of multi-use systems
// Лекция на открытии Технологического центра электронной обработки данных
компании Honeywell, 1968.
11. W. M. Taliaffero также сообщает о постоянной проиводительности 2400
операторов в год на ассмблере, Fortran и Cobol. См.: Modularity. The key to
system growth potential // Software. 1971. Vol. 1, N 3. July. P. 245-257.
12. В отчете Report TM-3225, Management Handbook for Estimation of
Computer Programming Costs (Nelson E. A. из System Development Corp.)
говорится о росте производительности 3:1 при использовании языка высокого
уровня (стр. 66-67), хотя дисперсия высока.
Глава 9
1. Brooks F. P., Iverson K. E. Automatic Data Processing, System/360
Edition. New York: Wiley, 1969. Ch. 6.
2. Knuth D. E. The Art of Computer Programming. Vols. 1-3. Reading,
Mass.: Addison-Wesley, 1968. ff.
Глава 10
1. Conway M. E. How do committees invent? // Datamation. 1968. Vol.
14, N 4. Apr. P. 28-31.
Глава 11
1. Речь в Оглеторпском университете 22 мая 1932 года.
2. Поучительный отчет об опыте использования MULTICS для создания двух
систем имеется в: Corbaty F. J., Saltzer J. H., Clingen C. T. MULTICS - the
first seven years // AFIPS Proc SJCC. 1972. Vol. 40. P. 571-583.
3. Cosgrove J. Needed: a new planning framework // Datamation. 1971.
Vol. 17, N 23. Dec. P. 37-39.
4. Изменение проекта - сложная проблема, и здесь я ее чрезмерно
упрощаю. См.: Saltzer J. H. Evolutionary design of complex systems // Eckman
D. (Ed.). Systems : Research and Design. New York : Wiley, 1961. Все же,
когда все сказано и сделано, я советую создать опытную систему, которую
планируется выбросить.
5. Campbell E. Report to the AEC Computer Information Meeting. 1970.
Dec. Это явление обсуждается также в: Ordin J. L. Designing reliable