VIII. ОБЪЯВЛЕНИЕ ЦЕЛИ
«Практика — лучший учитель».
(Публилиус)
«Опыт — хороший учитель, но и он ничему не научит дурака».
(Альманах «Бедный Ричард»)
Сколько времени занимает решение задачи системного программирования? Сколько усилий потребуется? И как все это оценивать?
Выше я уже предлагал соотношения для определения затрат времени на проектирование, написание программ, отладку компонент и комплексную отладку. Во-первых, необходимо отметить, что нельзя оценивать задачу в целом, взяв только данные о времени, затрачиваемом на написание программ и распространив их на остальные этапы работы. Написание программ составляет примерно только одну шестую всей задачи, и ошибки в оценке этого этапа или в соотношении его с другими могут привести к смехотворным результатам.
!' Во-вторых, необходимо отметить, что данные, относящиеся к созданию отдельных маленьких программ, не приложимы к комплексному программному продукту. Так, например, Сакмен, Эриксон и Грант приводят среднее время на написание и отладку программы объемом около 3200 слов — 178 часов для одного программиста, что дает производительность в 35 800 команд в год. В два раза меньшая программа требует в четыре раза меньше времени, так что средняя производительность получается равной почти 80 000 команд в год '). Сюда следует, однако, прибавить затраты времени на проектирование, документирование, отладку, объединение в систему, обучение и всякие перерывы. Экстраполяция таких малых цифр не имеет смысла. Так, если экстраполировать время, показываемое бегуном на дистанции в 100 ярдов, то получится, что человек может пробежать милю быстрее, чем за 3 минуты.
Но п'режде чем отбросить эти данные, отметим, однако, что эти числа, хотя и не годятся для строгого сравнения, показывают, что затраты растут квадратично с увеличением объема программы, даже когда нет викакого взаимодействия с другими людьми, если не считать обращения человека к своей памяти.
На рис. 8.1 показаны начальные результаты исследования, проведенного Нанусом и Фарром2) в фирме System Development. Здесь появляется показатель степени 1,5, т. е., затраты == (константа) X, X (число команд)''5.
В других исследованиях, проведенных этой же фирмой и опубликованных Вайн-вурмом3), также приводится показатель степени, близкий к 1,5.
Производительность программистов неоднократно бы- р„, g.l. Программировала предметом изучения, пред- ние как функция разме-лагались различные методы ров программы. ее оценки. Моурин подготовил обзор публикаций4) по этой тематике. Здесь я коснусь только некоторых фактов, представляющих особый интерес.
Данные Портмана
Чарльз Портман, руководитель Северного отделения системного программирования фирмы ICL в Манчестере, высказал другую интересную точку зрения.
Он обнаружил, что его коллективы программистов не укладывались в график почти наполовину — каждая задача занимала в два раза больше времени, чем ей отводилось по плану, несмотря на то, что оценки были очень тщательны (их делали опытные люди, которые определили затраты в человеко-часах для нескольких сотен подзадач с помощью схем PERT). Когда выявилось отставание от графика, Портман попросил своих сотрудников вести подробные ежедневные записи расхода времени. Эти записи показали, что ошибочная оценка полностью объясняется тем фактом, что коллективы тратили только 50% рабочего времени собственно на программирование и отладку. Остальное врем"я уходило на побочные, но срочные дела, совещания, За работу с бумагами, общественные дела, болезни, личные нужды, а также терялось из-за простоев машины. Короче говоря, при составлении графика было сделано нереальное предположение о том, какая часть времени затрачивается непосредственно на работу. Мой собственный опыт полностью подтверждает это заключение.
Данные Арона
Джоель Арон, руководитель отдела системной технологии фирмы IBM в Гейтесбурге (штат Мэриленд), изучал производительность программистов, принимавших участие в разработке девяти больших систем (большой считалась система объемом более 30 тыс. команд, в создании которой участвовало более 25 программистов)7). Он классифицировал системы по числу сопряжении между программистами (и тем самым, по числу отдельных частей системы) и получил следующие значения производительности одного программиста:
Очень мало сопряжения 10000 команд в год
Среднее число сопряжения 5000 » »
Много сопряжении 1500 » »
Но в этих данных учитывается только время на проектирование и написание программ. Если же разделить их на коэффициент два, покрывая тем самым затраты на системную отладку, то эти данные окажутся вполне сопоставимыми с данными Харра.
Данные Харра
Джон Харр, руководитель работ по программированию системы электронной коммутации фирмы Bell Telephone Laboratories обобщил свой опыт в докладе^ представленном в 1969 г. на осенней объединенной конференции по вычислительной технике8). Эти данные приведены в табл. 8.1 и на рис. 8.2 и 8.3.
Таблица 8.1
Табл. 8.1 является очень поучительной. Первые две задачи — это управляющие программы; две последние — трансляторы. Производительность определяется как число команд, отлаженных за человеко-год. Сюда включается написание программ, отладка компонент и системная отладка. Неясно, насколько здесь учитывались затраты на проектирование, а также на обслуживание машины, документирование и т. д.
Производительность разбивается на две категории:
для управляющих программ она составляет около 600 команд на человеко-год,
а для трансляторов — около 2200 команд на человеко-год.
Отметим, что все четыре программы примерно одного размера — различия в величине рабочих групп, в сроках и в чпсле модулей. Что здесь причина и что следствие? Потому ли создание управляющих программ требует больше людей, что они сложнее? Или же требуется больше модулей и больше человеко-месяцев именно потому, что заранее было больше занято людей? Потому ли требуется больше времени, что задача более сложная, или это происходит из-за большего числа занятых в ней людей? Определенный ответ дать достаточно трудно. Управляющие программы действительно более сложны. Однако если не принимать во внимание такие неопределенности, то вышеприведенные цифры описывают реальную производительность, достигнутую в большой системе с использованием современных методов программирования. И в этом аспекте они имеют достаточно важное значение.
Рис. 8.2. Предсказываемая и реальная скорости программирования системы электронной коммутации.
Рис. 8.3. Предсказываемая и реальная скорости отладки системы электронной коммутации.
На рис. 8.2 и 8.3 приводятся некоторые интересные данные о скорости программирования и отладки по сравнению с предсказаниями.
Данные по OS/360
Опыт разработки OS/360, не учитывавший данных Харра, тем не менее подтверждает их. Производительность групп, занимавшихся управляющими программами, составила 600 — 800 отлаженных команд на человеко-год. Производительности в 2000 — 3000 отлаженных команд на человеко-год достигли группы, разрабатывавшие языковые трансляторы. Сюда входит проектирование на уровне групп, написание программ отладка компонент, комплексная отладка и некоторые вспомогательные операции. Насколько я могу судить, ати данные вполне сопоставимы с данными Харра.
Данные Арона, Харра и OS/360 подтверждают существенные различия в производительности программистов в зависимости от сложности и трудности самой задачи. Чтобы не увязнуть в трясине определения этой сложности, я предлагаю придерживаться следующего правила: трансляторы в три раза сложнее обычных прикладных программ, а операционные системы в три раза сложнее трансляторов9).
Данные Корбато
Данные Харра и фирмы IBM относятся к программированию на языке ассемблера. Данные о производительности программирования на языках высокого уровня, кажется, еще не публиковались. Корбато из проекта MAC Массачусетского технологического института сообщает среднюю производительность в 1200 отлаженных операторов на PL/I для системы Multics (объемом один, два миллиона команд)10). :
Эта цифра очень показательна. Так же как и другие проекты, Multics содержит управляющие программы и трансляторы. Как и другие, он производит комплексный программный продукт, отлаженный и снабженный документацией. Поэтому данные должны быть сравнимы по затраченным усилиям. И действительно, эта производительность представляет собой хорошую среднюю величину между производительностью разработчиков управляющей программы и тех, кто писал трансляторы в других проектах.
Но цифры Корбато говорят об операторах на человеко-год, а не о командах! Каждый оператор в его системе соответствует приблизительно трем-пяти словам ручной программы. Отсюда два важных вывода:
производительность представляется константой на уровне элементарных операторов, т. е. по отношению к затратам на осмысление операторов и к ошибкам, которые они могут содержать '');
производительность программирования можно увеличить по крайней мере в пять раз путем использования подходящего языка высокого уровня12).
|
