Глава 8. Объявляя удар

Практика - лучший учитель.

ПУБЛИЙ

Опыт - дорогой учитель, но для глупцов иного нет.

АЛЬМАНАХ БЕДНОГО РИЧАРДА¹

Сколько времени потребует задача системного программирования? Сколько сил понадобится? Как можно это оценить?

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

Во-вторых, нужно учитывать, что оценки, полученные при создании отдельных небольших программ, нельзя применять для больших системных продуктов. К примеру, для программы, насчитывающей 3200 слов, Сакман, Эриксон и Грант оценивают суммарное время написания программ и отладки для одного программиста в 178 часов, что экстраполируется до 35 800 операторов в год. Вдвое меньшая программа потребовала меньше четверти указанного времени, что при экстраполяции дает производительность, близкую уже к 80 000 операторам в год.² Необходимо добавить затраты времени на планирование, составление документации, тестирование, системную интеграцию и обучение. Линейная экстраполяция данных, относящихся к коротким задачам, бессмысленна. Если экстраполировать время, за которое можно пробежать стометровку, то окажется, что можно пробежать милю менее чем за три минуты.

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

Показанные на рис.8.1 данные вызывают грустные чувства. График демонстрирует результаты, полученные в исследовании, проведенном Нанусом (Nanus) и Фарром (Farr)³ в System Development Corporation. В нем выявляется зависимость с показателем степени 1,5:

Объем\ работы=(константа)\times(количество\ команд)^{1,5}.

В другом исследовании, проведенном в этой компании, о котором сообщает Вайнвурм (Weinwurm)⁴, также получен показатель, близкий к 1,5.

Есть несколько исследований относительно производительности труда программиста, в которых предложен ряд технологий оценивания. Есть обзор опубликованных данных, подготовленный Моурином (Morin).⁵ Я приведу здесь лишь несколько наиболее показательных результатов.

Рис.8.1. Затраты на программирование как функция размера программы

Данные Портмана

Чарльз Портман (Charles Portman), менеджер отдела программирования ICL - Computer Equipment Organization (Northwest) в Манчестере, предлагает свое понимание проблемы, которое может оказаться полезным.⁶

Он обнаружил, что его команды программистов отстают от графиков примерно наполовину, т.е. каждое задание выполняется примерно вдвое дольше, чем предполагалось. При этом оценки очень тщательно проводились группами опытных экспертов, оценивавших в человеко-часах трудоемкость нескольких сотен подзадач с помощью диаграмм ПЕРТ. Когда выявлялось отставание от графика, он просил вести подробные ежедневные журналы использования времени. Из них выяснилось, что ошибка оценок полностью объясняется тем, что его команды использовали на программирование и отладку лишь 50 процентов рабочего времени. Остальное время терялось из-за отказов машины, на небольшие срочные посторонние задания, совещания, писание бумаг, дела фирмы, болезни, личное время и т.д. Короче оценки исходили из нереалистичного предположения о том, какая часть рабочего времени отводится непосредственно работе.⁷

Данные Арона

Джоэл Арон (Joel Aron), менеджер IBM по системным технологиям в Гейтерсберге, штат Мэриленд, изучал эффективность труда программистов во время работы над девятью крупными системами (крупная соответствует более чем 25 программистам и 30 000 операторов).⁸ Он классифицирует такие системы в соответствии с интенсивностью взаимодействия между программистами (и частями системы) и обнаруживает следующие величины производительности:

Очень слабое взаимодействие	10 000 инструкций на человека в год
Некоторое взаимодействие	5000 инструкций на человека в год
Существенное взаимодействие	1500 инструкций на человека в год

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

Данные Харра

Джон Харр (John Harr), менеджер по программированию Electronic Switching System, входящей в состав Bell Telephone Laboratories, сообщил о своем собственном опыте и других известных ему данных в докладе на Объединенной конференции по компьютерам весной 1969 года.⁹ Эти данные приведены на рисунках 8.2, 8.3 и 8.4.

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

	Число программных блоков	Число программистов	Затрачено лет	Человеко-лет	Количество слов в программе	Слов/человеко-год
Операционная	50	83	4	101	52 000	515
Обслуживающая	36	60	4	81	51 000	630
Компилятор	13	9	2¼	17	38 000	2230
Транслятор (ассемблер)	15	13	2½	11	25 000	2270

Рис.8.2. Сводка по четырем важнейшим программным проектам, осуществленным в ESS

Производительность разбивается на два класса: для управляющих программ составляет около 600 слов на человека за год, для трансляторов - около 2200. Обратите внимание, что все четыре программы приблизительно одного размера, различие состоит в размере рабочих групп, продолжительности работы и количестве модулей. Что является причиной, а что - следствием? Была ли сложность причиной того, что для управляющих программ требовалось больше людей? Или же большее число модулей и человеко-месяцев обусловлено большим числом людей, привлеченных к работе? Была ли большая продолжительность выполнения вызвана сложностью проблем или многочисленностью занятых людей? Трудно сказать с уверенностью. Конечно, управляющие программы были более сложными. Если оставить в стороне эти неопределенности, то цифры описывают реальную производительность при создании больших систем, и потому представляют ценность.

На рисунках 8.3 и 8.4 показаны некоторые интересные данные о фактической скорости программирования и отладки в сравнении с прогнозом.

Данные OS/360

Опыт OS/360 подтверждает данные Харра, хотя данные по OS/360 не столь подробны. В группах разработки управляющей программы производительность составила 600-800 отлаженных команд в год на человека. В группах разработки трансляторов производительность достигла 2000-3000 отлаженных команд в год на человека. При этом учитывается планирование, тестирование компонентов, системное тестирование и некоторые затраты на поддержку. Насколько я могу судить, эти данные согласуются с результатами Харра.

Рис.8.3. Предсказанная и фактическая скорость программирования

Рис.8.4. Предсказанная и фактическая скорость отладки

Данные Арона, Харра и OS/360 дружно подтверждают резкие различия в производительности в зависимости от сложности и трудности самой задачи. В работе оценивания сложности я придерживаюсь той линии, что компиляторы втрое хуже обычных пакетных прикладных программ, а операционные системы втрое хуже компиляторов.¹⁰

Данные Корбато

Данные Харри и OS/360 относятся к программированию на языке ассемблера. Есть немного публикаций относительно производительности системного программирования с использованием языков высокого уровня. Корбато (Corbato) из проекта MAC Массачусетского технологического института сообщает о средней производительности 1200 строк отлаженных операторов PL/I на человека в год при разработке операционной системы MULTICS (от 1 до 2 миллионов слов).¹¹

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

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

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

1 Бедный Ричард - образ необразованного, но здравомыслящего доморощенного философа, созданный Бенджамином Франклином, издававшим в 1732-1757 годах ежегодный альманах и использовавшим этот псевдоним (примеч.перев.).

2 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 Nanus B., Farr L. Some cost contributors to large-scale programs // AFIPS Proc. SJCC. Spring 1964. Vol.25. P.239-248.

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

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

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

7 В неопубликованном исследовании 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 Aron J. Частное сообщение.

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

10 Wolverton R.W. The cost of developing large-scale software // IEEE Trans. On Computers. 1974. Vol.C-23, N 6. June. P.615-636. В этой недавней важной статье содержатся данные по многим вопросам, обсуждаемым в этой главе, также подтверждающие выводы о производительности труда.

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

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

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

сделать озонотерапию

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