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

На нашем литературном портале можно бесплатно читать книгу Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы, Фредерик Брукс . Жанр: Деловая литература. Онлайн библиотека дает возможность прочитать весь текст и даже без регистрации и СМС подтверждения на нашем литературном портале fplib.ru.
Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы
Название: Мифический человеко-месяц или как создаются программные системы
Издательство: неизвестно
ISBN: нет данных
Год: неизвестен
Дата добавления: 23 февраль 2019
Количество просмотров: 243
Читать онлайн

Помощь проекту

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

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

Для человека, влюбленного в компьютеры, трудно было бы придумать иное время, когда так радостно было жить. От механических устройств до вакуумных ламп, транзисторов и интегральных схем шло бурное развитие технологии. Первый компьютер, на котором я работал сразу после выпуска из Гарварда, был суперкомпьютер IBM Stretch. Этот компьютер царствовал над миром как самый быстрый с 1961 по 1964 годы; было изготовлено 9 экземпляров. Мой сегодняшний Macintosh Powerbook не только быстрее, с большей памятью и большим диском, но и в тысячу раз дешевле (в пять тысяч раз дешевле с учетом инфляции). Мы были свидетелями того, как поочередно произошли компьютерная революция, революция электронных компьютеров, революция миникомпьютеров и революция микрокомпьютеров, в результате каждой из которых компьютеров становилось на порядки больше.

Область связанных с компьютерами знаний претерпела взрыв, как и соответствующая технология. Будучи аспирантом в середине 50-х, я мог прочесть все журналы и труды конференций. Я мог оставаться на современном уровне во всей научной дисциплине. Сегодня же мне в моей интеллектуальной жизни приходится с сожалением расставаться с интересами то в одной, то в другой подобласти, поскольку количество документов превысило всякую возможность справиться с ними. Масса интересов, масса замечательных возможностей для учебы, исследований, размышлений. Чудесное затруднение! Не только конца не видно, но и шаг не замедляется. В будущем нас ожидают многие радости.

Примечания и ссылки

Глава 1

1.1. А. П. Ершов полагает, что это не только печаль, но отчасти и радость. A. P. Ershov. Aesthetics and the human factor in programming // CACM. 1972. Vol. 15, N 7. July. P. 501-505

Глава 2

2.1. В. А. Высоцкий из Bell Telephone Laboratories считает, что большой проект может выдержать до 30% прироста числа сотрудников в год. При большем увеличении затрудняется и даже подавляется развитие важной неформальной структуры и ее коммуникационных связей, о чем говорится в главе 7. Ф. Дж. Корбато из МТИ отмечает, что в длительном проекте следует ожидать ежегодной смены 20% сотрудников, и новые работники должны как получить техническую подготовку, так и влиться в формальную структуру.

2.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.

2.3. Рисунками 2.5-2.8 я обязан Джерри Огдину, который, цитируя мой пример из более ранней публикации этой главы, значительно улучшил иллюстрации. Ogdin, J. L. The Mongolian hordes versus superprogrammer // Infosystems. 1972. Dec. P. 20-23.

Глава 3

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.

3.2. Mills H. Chief programmer team, principles, and procedures // IBM Federal Systems Division Report FSC 71-5108. Gaithersburg, Md., 1971.

3.3. Baker F. T. Chief programmer team management of production programming // IBM Sys. J. 1972. Vol. 11, N 1.

Глава 4

4.1. Eschapasse M. Reims Cathedral, Caisse Nationale des Monuments Histiriques. Paris, 1967.

4.2. Brooks F. P. Architectural Philosophy // Buchholz W. (Ed.). Planning a Computer System. New York: McGraw-Hill, 1962.

4.3. Blaauw G. A. Hardware requirements for the fourth generation // Gruenberger F. (ed.). Fourth Generation Computers. Englewood Cliffs, N. J.: Prentice-Hall, 1970.

4.4. Brooks F. P., Iverson K. E. Automatic Data Processing, System/360 Edition. New York: Wiley, 1969. Ch. 5.

4.5. Glegg G. L. The Design of Design. Cambridge : Cambridge Univ. Press, 1969: «На первый взгляд кажется, что мысль о том, чтобы наложить на творческий ум какие-то правила или принципы, скорее помешает ему, чем окажет помощь, но на практике это совершенно неверно. Дисциплинированное мышление скорее концентрирует вдохновение, чем подавляет его».

4.6. Conway R. W. The PL/C Compiler // Proceedings of a Conf. on Definition and Implementation of Universal Programming Languages. Stuttgard, 1970.

4.7. Хорошее обсуждение необходимости программных технологий см.: Reynolds C. H. What’s wrong with computer programming management? // Weinwurm G. F. (Ed.). On the Management of Computer Programming. Philadelphia : Auerbach, 1971. P. 35-42.

Глава 5

5.1. Strachey C. Review of Planning a Computer System // Comp. J. 1962. Vol. 5, N 2. July. P. 152-153.

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

5.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

6.1. Neustadt R. E. Presidential Power. New York: Wiley, 1960. Ch. 2.

6.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.

6.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.

6.4. Iverson K. E. A Programming Language. New York: Wiley, 1962. Ch. 2.

6.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.6. Bell C. G., Newell A. Computer Structures. New York: McGraw-Hill, 1970. P. 120-136, 517-541.

6.7. Bell C. G. Частное сообщение.

Глава 7

7.1. Parnas D. L. Information distribution aspects of design methodology. Carnegie-Mellon Univ., Dept. Of Computer Science Technical Report. 1971. February.

7.2. Copyright 1939, 1940 Street & Smith Publications; Copyright 1950, 1967 Роберта А. Хайнлайна (Robert A. Heinlein). Публикуется по соглашению с Spectrum Literary Agency.

Глава 8

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.

8.2. Nanus B., Farr L. Some cost contributors to large-scale programs // AFIPS Proc. SJCC. Spring 1964. Vol. 25. P. 239-248.

8.3. Weinwurm G. F. Research in the management of computer programming // Report SP-2059, System Development Corp. Santa Monica, 1965.

8.4. Morin L. H. Estimation of resources for computer programming projects // M. S. thesis. Chapel Hill: Univ. Of North Carolina, 1974.

8.5. Portman C. Частное сообщение.

8.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.)

8.7. Aron J. Частное сообщение.

8.8. Доклад, сделанный на совещании и включенный в AFIPS Proceedings.

8.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. В этой недавней важной статье содержатся данные по многим вопросам, обсуждаемым в этой главе, также подтверждающие выводы о производительности труда.

8.10. Corbato F. J. Sensitive issues in the design of multi-use systems // Лекция на открытии Технологического центра электронной обработки данных компании Honeywell, 1968.

8.11. W. M. Taliaffero также сообщает о постоянной проиводительности 2400 операторов в год на ассмблере, Fortran и Cobol. См.: Modularity. The key to system growth potential // Software. 1971. Vol. 1, N 3. July. P. 245-257.

8.12. В отчете Report TM-3225, Management Handbook for Estimation of Computer Programming Costs (Nelson E. A. из System Development Corp.) говорится о росте производительности 3:1 при использовании языка высокого уровня (стр. 66-67), хотя дисперсия высока.

Глава 9

9.1. Brooks F. P., Iverson K. E. Automatic Data Processing, System/360 Edition. New York: Wiley, 1969. Ch. 6.

9.2. Knuth D. E. The Art of Computer Programming. Vols. 1-3. Reading, Mass.: Addison-Wesley, 1968. ff.

Глава 10

10.1. Conway M. E. How do committees invent? // Datamation. 1968. Vol. 14, N 4. Apr. P. 28-31.

Глава 11

11.1. Речь в Оглеторпском университете 22 мая 1932 года.

11.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.

11.3. Cosgrove J. Needed: a new planning framework // Datamation. 1971. Vol. 17, N 23. Dec. P. 37-39.

11.4. Изменение проекта — сложная проблема, и здесь я ее чрезмерно упрощаю. См.: Saltzer J. H. Evolutionary design of complex systems // Eckman D. (Ed.). Systems : Research and Design. New York : Wiley, 1961. Все же, когда все сказано и сделано, я советую создать опытную систему, которую планируется выбросить.

11.5. Campbell E. Report to the AEC Computer Information Meeting. 1970. Dec. Это явление обсуждается также в: Ordin J. L. Designing reliable software // Datamation. 1972. Vol. 18, N 7. July. P. 71-78. Мнения моих опытных знакомых делятся примерно на равные части в отношении того, опускается ли кривая в конце.

11.6. Lehman M., Belady L. Programming systems dynamics. Представлено на ACM SIGOPS Third Symposium on Operating Systems Principles в октябре 1971 г.

11.7. Lewis C. S. Mere Christianity. New York : Macmillan, 1960. P. 54.

Глава 12

12.1. См. также: Pomeroy J. W. A guide to programming tools and techniques // IBM Sys. J. 1972. Vol. 11, N 3. P. 234-254.

12.2. Landy B., Needham R. M. Software engineering techniques used in the development of the Cambridge Multiple-Access System // Software. 1971. Vol. 1, N 2. Apr. P. 167-173.

12.3. Corbato F. J. PL/I as a tool for system programming // Datamation. 1969. Vol. 15, N 5. May. P. 68-76.

12.4. Hopkins M. Problems of PL/I for system programming // IBM Research Report RC 3489. 1971, August 5. Yorktown Heights, N. Y.

12.5. Corbato F. J., Saltzer J. H., Clingen C. T. MULTICS – the first seven years // AFIPS Proc SJCC. 1972. Vol. 40. P. 571-582. «Лишь около полудюжины кусков, написанных на PL/I, были перепрограммированы на машинном языке, чтобы выжать максимальную скорость. Несколько программ, первоначально написанных на машинном языке, были переписаны на PL/I, чтобы облегчить их сопровождение.»

12.6. Цитирую статью Корбато (ссылка 3 настоящей главы): «PL/I уже есть, а альтернативы пока не проверены». Однако совершенно противоположный и обоснованный взгляд представлен в Henricksen J. O., Merwin R. E. Programming language efficiency in real-time software systems // AFIPS Proc SJCC. 1972. Vol. 40. P. 155-161.

12.7. Не все с этим согласны. Гарлан Миллз отмечает в частном сообщении: «Опыт начинает подсказывать мне, что в промышленном программировании за терминал нужно посадить секретаря. Программирование следует сделать более общественным занятием при общем рассмотрении участников команды, а не частным занятием».

Комментариев (0)
×