Страница:
Тем не менее, учитывая все вышесказанное, я считаю, что микрофиши были удачной находкой, и я мог бы их рекомендовать для очень больших проектов.
Как поступать сегодня? Я считаю, что, располагая сегодняшней системной техникой, имеет смысл хранить рабочие документы в файле с непосредственным доступом и отмечать в нем все изменения и их даты, каждый пользователь сможет обращаться к нему с графического терминала (телетайпы слишком медленны). Ежедневно подготавливаемый обзор всех изменений будет храниться по принципу "вошедший последним выходит первым" в некоторой фиксированной точке обращения. Программист может читать его ежедневно, но если он и пропустит день, то назавтра ему просто придется прочесть больший текст. По мере чтения обзора всех изменений, он может прерываться и обращаться к самому тексту, в который они внесены.
Отметим, что сам рабочий документ при этом не изменяется. Он остается объединением всей документации по проекту и имеет тщательно разработанную структуру. Изменения претерпевают только механизм его распространения и работа с ним. Д. Энгельбарт вместе со своими коллегами из Стэнфордского исследовательского института создали такую систему и использовали ее при разработке и ведении документации по проекту создания сети ARPA.
Д. Парнас из Университета Карнеги - Меллона предложил еще более радикальное решение'). Он выдвинул тезис о том, что программист работает наиболее эффективно, если он не вдается в детали организации других частей системы. Это подразумевает полное и исчерпывающее определение всех сопряжении. Несмотря на то, что это звучит весьма разумно, реализация такой идеи может оказаться затруднительной. Однако хорошо организованная система информации не только выявляет ошибки в сопряжениях, но и стимулирует их исправление.
Организация в больших программистских проектах
Если в проекте занято п работников, то существует (n2-п)/2 сопряжении, по которым в принципе возможна связь, и почти 2n коллективов, внутри которых должна иметь место координация. Задача организации заключается в том, чтобы максимально уменьшить требуемый объем затрат на установление связи и координацию, следовательно, организация представляется радикальным решением вышеупомянутых проблем.
Средствами, с помощью которых уменьшаются затраты на связь, являются разделение труда и специализация функций. Древовидная структура организации отражает все уменьшающуюся потребность в установлении контактов в условиях разделения труда и его специализации.
И действительно, дерево представляет собой структуру власти и ответственности. Принцип, что ни один человек не может служить двум хозяевам сразу, требует, чтобы структура власти имела вид дерева. Но на структуру связи не накладывается таких ограничений, и дерево является не слишком удовлетворительным приближением к структуре связи, которая представляет собой неплоскую сеть. Неадекватность чисто иерархической структуры нашла свое отражение в концепциях рабочих групп, целевых команд, комитетов и даже в организациях матричного типа, используемых во многих технических лабораториях.
Давайте рассмотрим древовидную программистскую организацию и те основные элементы, которые должны входить в каждое поддерево для обеспечения его эффективности. Сюда относятся:
1. Цели и задачи.
2. Продюсер.
3. Технический директор или архитектор.
4. График работ.
5. Разделение труда.
6. Определение сопряжении между отдельными частями.
Все это очевидно и общепринято, за исключением разницы между продюсером и техническим директором. Рассмотрим сначала две эти роли, а затем - связь между ними.
Какова роль продюсера? Он набирает бригаду, распределяет работу и устанавливает график. Он обеспечивает коллектив всеми необходимыми ресурсами и следит за их пополнением. Это означает, что его основные обязанности заключаются в установлении связей за пределами бригады, вверх и в стороны. Он устанавливает структуру связей и отчетности внутри коллектива. И, наконец, он обеспечивает выполнение графика, приводя ресурсы и организацию в соответствие с изменяющимися обстоятельствами.
А что же технический директор? Он разрабатывает проект, идентифицирует его части, определяет, как он будет выглядеть внешне и набрасывает его внутреннюю структуру. Он обеспечивает концептуальное единство и целостность всего проекта и тем самым устанавливает пределы сложности системы. Но мере возникновения отдельных технических проблем он обдумывает их решение или же задает проекту системы нужное направление. Он, по меткому выражению Эла Каппа*), "человек из кочегарки". Все его связи лежат в основном внутри группы. Его работа почти полностью связана с техническим содержанием проекта.
Теперь уже ясно, что эти две роли требуют совершенно разных способностей. Но эти способности проявляются в самых различных сочетаниях; конкретная комбинация, воплощенная в продюсере и директоре, должна руководить отношениями между ними. Схема организации должна выбираться в зависимости от конкретных способностей имеющихся в вашем распоряжении людей, а не наоборот; нельзя подгонять их под теоретическую схему.
Существуют три возможных типа отношений, и каждый из них вполне оправдывает себя на практике.
Одно и то же лицо может быть продюсером и техническим директором. Этот вариант прекрасно оправдывает себя в очень маленьких коллективах, от 3 до 6 программистов. Для больших проектов он малопригоден по двум причинам. Во-первых, очень трудно найти человека, обладающего одновременно талантом руководителя и незаурядными техническими способностями. Мыслители встречаются редко; деятели-реже; а мыслители-деятели-совсем редко. Во-вторых, в больших проектах каждая из этих ролей требует полной отдачи, занимая все рабочее время или даже более того. Продюсеру очень трудно снять с себя часть своих обязанностей с тем, чтобы высвободить время для чисто технических решений. А директору просто невозможно это сделать, не нарушив единства проекта.
Продюсер может быть начальником, а директор - его правой рукой. Трудность здесь заключается в представлении директору права принимать технические решения, не загружая его в то же время административными проблемами.
Очевидно, что продюсер должен признать права директора в принятии технических решений и поддерживать его власть в подавляющем большинстве случаев неизбежной проверки. Это возможно только при условии, если продюсер и директор имеют одинаковые точки зрения на основные технические проблемы. Они должны обсуждать главные вопросы еще до того, как по ним будут приняты решения. И, наконец, продюсер должен с большим уважением относиться к профессиональному мастерству директора.
Менее очевиден тот факт, что продюсер с помощью различных символов статуса (размер кабинета, ковер, мебель и т. д.) может всячески подчеркивать, что директор облечен законодательной властью, хотя формально он и не является руководителем.
Тем самым можно сделать работу очень эффективной. К сожалению, все это практикуется редко. Хуже всего, когда руководители проекта используют в качестве продюсера талантливого специалиста, который не силен в проблемах управления.
Директор может быть начальником, а продюсер - его правой рукой. В книге "Человек, продавший луну", Роберт Хейнлейн выразительно описывает такую организацию.
Костер уронил голову на руки, потом вдруг поднял ее:
"Я в этом разбираюсь. Я знаю, что нужно сделать - но каждый раз, когда я пытаюсь заняться технической проблемой, какой-нибудь идиот требует, чтобы я принял решение насчет грузовиков или телефонов, или другой такой же чертовщины. Простите, мистер Гарриман. Я думал, что смогу справиться со всем этим".
Гарриман сказал очень мягко: "Не принимайте все это так близко к сердцу, Боб! Вы, наверное, не высыпаетесь последнее время? Вот что я вам скажу - мы перехитрим Фергю-сона. Я заберу ваш стол на пару дней и построю вам такую баррикаду, за которой никакие грузовики не страшны. Я хочу. чтобы вы могли спокойно думать о направлении реакции, КПД горячего топлива, об узких местах в проекте и не заботиться о контрактах на грузовики". Гарримап подошел к двери, выглянул в коридор и позвал какого-то человека, по виду напоминавшего старшего клерка. "Эй, Вы! Идите-ка сюда!".
Человек удивленно огляделся, подошел к двери и спросил:
"Да?". "Я хочу, чтобы вот этот стол в углу, и все, что на нем, перенесли в пустой кабинет на этом же этаже, направо по коридору". Он проследил за тем, как стол и вещи Костера перенесли в новый кабинет, позаботился, чтобы там отключили телефон, и, немного подумав, велел принести туда диван. "А вечером поставим проектор, чертежный прибор, шкафы и все остальное",-сказал он Костеру. "Вы только составьте список всего, что вам нужно, чтобы заниматься делом. Если что-нибудь еще потребуется-звоните мне". Он вернулся в кабинет главного инженера и стал размышлять, чего же стоит его организация и что в ней не в порядке?
Часа четыре спустя он пригласил Беркли, чтобы представить его Костеру. Главный инженер спал за столом, положив голову на руки. Гарриман собирался уже уйти, но Костер проснулся. "Простите,- покраснел он,- я, наверное, задремал". "Для этого я и принес вам диван,- сказал Гарриман - на нем удобнее отдыхать. Вот, познакомьтесь с Джеком Беркли. Он ваш новый раб. Вы остаетесь главным инженером и верховным начальником, приказ которого не обсуждается. Джок - это Его Превосходительство Все Что Хотите. Отныне вам абсолютно не о чем беспокоиться - разве, что о такой малости, как создание лунного корабля".
Они пожали друг Другу руки. "Я только об одном вас попрошу, г-н Костер,- сказал Беркли серьезным тоном,- переправляйте ко мне все, что хотите - в конце концов, вам командовать техническим парадом - но, ради бога, записывайте все, чтобы я был в курсе дела. У вас будет кнопка, включающая мой диктофон".
"Отлично"- Костер, как показалось Гарриману, молодел на глазах.
"А если вам понадобится что-нибудь, что не имеет отношения к проблеме, не делайте этого сами. Нажмите на кнопку и свистните - и все будет сделано". Беркли взглянул на Гар-римапа. "Босс говорит, что хочет обсудить с вами настоящее дело. Так что я вас покину". Он вышел.
Гарриман уселся. Костер последовал его примеру и вздохнул: "Уф!".
- Ну как, легче?
- Мне этот парень сразу понравился.
- Ну вот и хорошо, теперь он - ваша тень. Не беспокойтесь, он у меня и раньше работал. Вам покажется, что вы живете в хорошем пансионате2).
Этот отрывок вряд ли нуждается в комментариях. Для эффективной работы такая организация вполне приемлема.
Я считаю, что этот последний метод организации более всего пригоден для маленьких коллективов, таких, как обсуждаются в гл. III "Хирургическая бригада", в то время как продюсер в качестве верховного руководителя - это наиболее приемлемая форма организации для больших поддеревьев действительно крупного проекта.
Вавилонская башня была, возможно, первым инженерным фиаско, но не последним. Установление связи и, как ее следствие, организация наиболее важны для успеха. Методика связи и организации требуют от руководителя столько же способностей и компетенции, как и само создание математического обеспечения.
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).
IX. ДЕСЯТЬ ФУНТОВ В ПЯТИФУНТОВОМ МЕШКЕ
"Автор должен брать пример с Ноя и научиться, как он это делал на своем ковчеге, помещать так много всего в таком малом объеме.
(Сидней Смит "Эдинбургское обозрение")
Размер программы как стоимость
Какова стоимость программы? Если не рассматривать время выполнения программы, то именно ее объем является основным показателем ее стоимости в глазах пользователя. Это справедливо даже для арендуемых программ, где пользователь платит автору сумму, составляющую, по сути, часть стоимости разработки. Рассмотрим диалоговую систему математического обеспечения APL, разработанную фирмой IBM. Она сдается в аренду за 400 долларов в месяц и требует для своего использования по крайней мере 160 тыс. байтов памяти. В модели ЩМ 370/165 стоимость аренды памяти составляет 12 долларов за тысячу байтов в месяц. Если программа работает круглосуточно, то стоимость ее использования составит 400 долларов за математическое обеспечение и 1920 долларов за память. Если система APL используется только 4 часа в день, то стоимость составит 400 долларов арендной платы ва математическое обеспечение и 320 долларов за память в месяц.
Нередко приходится слышать, с каким ужасом воспринимается тот факт, что в машине с памятью 2 млн. байтов операционная' система может занимать 400 тыс. байтов. Ужасаться так же глупо, как критиковать Боинг 747 за то, что он стоит 27 миллионов долларов. Необходимо только задать себе вопрос: а что операционная система делает? Что можно получить аа свои деньги в смысле удобства и производительности (при эффективном использовании системы)? Может быть, 4800 долларов в месяц, затрачиваемые на аренду памяти, более целесообразно истратить на другое оборудование, на программистов, на прикладные программы?
Разработчик системы превращает часть отведенных ему ресурсов оборудования в память с резидентными программами, когда он уверен, что для пользователя это лучше, чем иметь дело с сумматорами, дисками и т. д. Поступать иначе было бы в высшей степени безответственно, и результат должен оцениваться как одно целое. Нельзя критиковать систему программирования за размер как таковой, и в то же время постоянно выступать за все более тесное объединение проектов создания аппаратуры и математического обеспечения.
Поскольку львиная доля затрат пользователя отводится на программу, разработчик комплексного программного продукта должен установить контрольные цифры, следить за их соблюдением и придумывать методы уменьшения размеров программ точно так же, как разработчик аппаратуры устанавливает контрольные значения числа компонент, следит за их соблюдением и изобретает методы их сокращения.
Контроль за размерами программ
Управление размерами программ представляет для руководителя проекта частично техническую, а частично - административную задачу. Для установления размеров предлагаемых систем необходимо изучить потребности пользователей и те прикладные области, в которых они работают. Далее эти системы следует разбить на части и определить контрольные цифры размеров каждой компоненты. Поскольку с изменением размеров программы быстродействие меняется очень резко, установление контрольных цифр требует от руководителя профессиональной ловкости и знания допустимых соотношений в каждой части системы. Кроме того, мудрый руководитель всегда оставляет для себя лазейку, которой он сможет воспользоваться впоследствии. Хотя в OS/360 все это было проделано очень тщательно, не обошлось без болезненных уроков. Во-первых, недостаточно просто установить контрольные цифры размеров оперативной памяти, необходимо учесть все аспекты, связанные с размером программы. Большая часть предыдущих операционных систем размещалась на лентах и поскольку поиск на лентах занимал много времени, это препятствовало их интенсивному вызову из сегментов программы. Система OS/360, как и ее непосредственные предшественники - операционные системы Stretch и DOS IBM 1410/7010, располагалась на дисках. Ее создатели наслаждались свободой дешевого обращения к дискам. Первоначальный результат был катастрофичным для производительности.
При установлении размеров оперативной памяти для каждой компоненты бюджет расхода памяти не устанавливался заранее. Как и предсказывали сверхпроницательные люди, программист, обнаруживая, что его программа выходит за отведенный ему участок оперативной памяти, разбивал ее на сегменты. Тем самым увеличивались общие размеры системы и уменьшалась скорость выполнения. Наша служба административного контроля не выявляла таких случаев. Каждый сообщал, какой объем оперативной памяти он использует, и если программист оставался в пределах контрольных цифр, то никто не беспокоился. К счастью, пришел день, когда начала работать программа, моделирующая производительность OS/360. Первые же результаты показали, что не все благополучно. Фортран Н на машине IBM 360/65 с барабанами транслировался со скоростью пять операторов в минуту. Расследование показало, что модули управляющей программы осуществляли слишком много обращений к дискам. Даже очень часто используемые модули супервизора "ходили к колодцу с наперстками" п результат весьма напоминал непрерывную "лихорадку" памяти.
Как поступать сегодня? Я считаю, что, располагая сегодняшней системной техникой, имеет смысл хранить рабочие документы в файле с непосредственным доступом и отмечать в нем все изменения и их даты, каждый пользователь сможет обращаться к нему с графического терминала (телетайпы слишком медленны). Ежедневно подготавливаемый обзор всех изменений будет храниться по принципу "вошедший последним выходит первым" в некоторой фиксированной точке обращения. Программист может читать его ежедневно, но если он и пропустит день, то назавтра ему просто придется прочесть больший текст. По мере чтения обзора всех изменений, он может прерываться и обращаться к самому тексту, в который они внесены.
Отметим, что сам рабочий документ при этом не изменяется. Он остается объединением всей документации по проекту и имеет тщательно разработанную структуру. Изменения претерпевают только механизм его распространения и работа с ним. Д. Энгельбарт вместе со своими коллегами из Стэнфордского исследовательского института создали такую систему и использовали ее при разработке и ведении документации по проекту создания сети ARPA.
Д. Парнас из Университета Карнеги - Меллона предложил еще более радикальное решение'). Он выдвинул тезис о том, что программист работает наиболее эффективно, если он не вдается в детали организации других частей системы. Это подразумевает полное и исчерпывающее определение всех сопряжении. Несмотря на то, что это звучит весьма разумно, реализация такой идеи может оказаться затруднительной. Однако хорошо организованная система информации не только выявляет ошибки в сопряжениях, но и стимулирует их исправление.
Организация в больших программистских проектах
Если в проекте занято п работников, то существует (n2-п)/2 сопряжении, по которым в принципе возможна связь, и почти 2n коллективов, внутри которых должна иметь место координация. Задача организации заключается в том, чтобы максимально уменьшить требуемый объем затрат на установление связи и координацию, следовательно, организация представляется радикальным решением вышеупомянутых проблем.
Средствами, с помощью которых уменьшаются затраты на связь, являются разделение труда и специализация функций. Древовидная структура организации отражает все уменьшающуюся потребность в установлении контактов в условиях разделения труда и его специализации.
И действительно, дерево представляет собой структуру власти и ответственности. Принцип, что ни один человек не может служить двум хозяевам сразу, требует, чтобы структура власти имела вид дерева. Но на структуру связи не накладывается таких ограничений, и дерево является не слишком удовлетворительным приближением к структуре связи, которая представляет собой неплоскую сеть. Неадекватность чисто иерархической структуры нашла свое отражение в концепциях рабочих групп, целевых команд, комитетов и даже в организациях матричного типа, используемых во многих технических лабораториях.
Давайте рассмотрим древовидную программистскую организацию и те основные элементы, которые должны входить в каждое поддерево для обеспечения его эффективности. Сюда относятся:
1. Цели и задачи.
2. Продюсер.
3. Технический директор или архитектор.
4. График работ.
5. Разделение труда.
6. Определение сопряжении между отдельными частями.
Все это очевидно и общепринято, за исключением разницы между продюсером и техническим директором. Рассмотрим сначала две эти роли, а затем - связь между ними.
Какова роль продюсера? Он набирает бригаду, распределяет работу и устанавливает график. Он обеспечивает коллектив всеми необходимыми ресурсами и следит за их пополнением. Это означает, что его основные обязанности заключаются в установлении связей за пределами бригады, вверх и в стороны. Он устанавливает структуру связей и отчетности внутри коллектива. И, наконец, он обеспечивает выполнение графика, приводя ресурсы и организацию в соответствие с изменяющимися обстоятельствами.
А что же технический директор? Он разрабатывает проект, идентифицирует его части, определяет, как он будет выглядеть внешне и набрасывает его внутреннюю структуру. Он обеспечивает концептуальное единство и целостность всего проекта и тем самым устанавливает пределы сложности системы. Но мере возникновения отдельных технических проблем он обдумывает их решение или же задает проекту системы нужное направление. Он, по меткому выражению Эла Каппа*), "человек из кочегарки". Все его связи лежат в основном внутри группы. Его работа почти полностью связана с техническим содержанием проекта.
Теперь уже ясно, что эти две роли требуют совершенно разных способностей. Но эти способности проявляются в самых различных сочетаниях; конкретная комбинация, воплощенная в продюсере и директоре, должна руководить отношениями между ними. Схема организации должна выбираться в зависимости от конкретных способностей имеющихся в вашем распоряжении людей, а не наоборот; нельзя подгонять их под теоретическую схему.
Существуют три возможных типа отношений, и каждый из них вполне оправдывает себя на практике.
Одно и то же лицо может быть продюсером и техническим директором. Этот вариант прекрасно оправдывает себя в очень маленьких коллективах, от 3 до 6 программистов. Для больших проектов он малопригоден по двум причинам. Во-первых, очень трудно найти человека, обладающего одновременно талантом руководителя и незаурядными техническими способностями. Мыслители встречаются редко; деятели-реже; а мыслители-деятели-совсем редко. Во-вторых, в больших проектах каждая из этих ролей требует полной отдачи, занимая все рабочее время или даже более того. Продюсеру очень трудно снять с себя часть своих обязанностей с тем, чтобы высвободить время для чисто технических решений. А директору просто невозможно это сделать, не нарушив единства проекта.
Продюсер может быть начальником, а директор - его правой рукой. Трудность здесь заключается в представлении директору права принимать технические решения, не загружая его в то же время административными проблемами.
Очевидно, что продюсер должен признать права директора в принятии технических решений и поддерживать его власть в подавляющем большинстве случаев неизбежной проверки. Это возможно только при условии, если продюсер и директор имеют одинаковые точки зрения на основные технические проблемы. Они должны обсуждать главные вопросы еще до того, как по ним будут приняты решения. И, наконец, продюсер должен с большим уважением относиться к профессиональному мастерству директора.
Менее очевиден тот факт, что продюсер с помощью различных символов статуса (размер кабинета, ковер, мебель и т. д.) может всячески подчеркивать, что директор облечен законодательной властью, хотя формально он и не является руководителем.
Тем самым можно сделать работу очень эффективной. К сожалению, все это практикуется редко. Хуже всего, когда руководители проекта используют в качестве продюсера талантливого специалиста, который не силен в проблемах управления.
Директор может быть начальником, а продюсер - его правой рукой. В книге "Человек, продавший луну", Роберт Хейнлейн выразительно описывает такую организацию.
Костер уронил голову на руки, потом вдруг поднял ее:
"Я в этом разбираюсь. Я знаю, что нужно сделать - но каждый раз, когда я пытаюсь заняться технической проблемой, какой-нибудь идиот требует, чтобы я принял решение насчет грузовиков или телефонов, или другой такой же чертовщины. Простите, мистер Гарриман. Я думал, что смогу справиться со всем этим".
Гарриман сказал очень мягко: "Не принимайте все это так близко к сердцу, Боб! Вы, наверное, не высыпаетесь последнее время? Вот что я вам скажу - мы перехитрим Фергю-сона. Я заберу ваш стол на пару дней и построю вам такую баррикаду, за которой никакие грузовики не страшны. Я хочу. чтобы вы могли спокойно думать о направлении реакции, КПД горячего топлива, об узких местах в проекте и не заботиться о контрактах на грузовики". Гарримап подошел к двери, выглянул в коридор и позвал какого-то человека, по виду напоминавшего старшего клерка. "Эй, Вы! Идите-ка сюда!".
Человек удивленно огляделся, подошел к двери и спросил:
"Да?". "Я хочу, чтобы вот этот стол в углу, и все, что на нем, перенесли в пустой кабинет на этом же этаже, направо по коридору". Он проследил за тем, как стол и вещи Костера перенесли в новый кабинет, позаботился, чтобы там отключили телефон, и, немного подумав, велел принести туда диван. "А вечером поставим проектор, чертежный прибор, шкафы и все остальное",-сказал он Костеру. "Вы только составьте список всего, что вам нужно, чтобы заниматься делом. Если что-нибудь еще потребуется-звоните мне". Он вернулся в кабинет главного инженера и стал размышлять, чего же стоит его организация и что в ней не в порядке?
Часа четыре спустя он пригласил Беркли, чтобы представить его Костеру. Главный инженер спал за столом, положив голову на руки. Гарриман собирался уже уйти, но Костер проснулся. "Простите,- покраснел он,- я, наверное, задремал". "Для этого я и принес вам диван,- сказал Гарриман - на нем удобнее отдыхать. Вот, познакомьтесь с Джеком Беркли. Он ваш новый раб. Вы остаетесь главным инженером и верховным начальником, приказ которого не обсуждается. Джок - это Его Превосходительство Все Что Хотите. Отныне вам абсолютно не о чем беспокоиться - разве, что о такой малости, как создание лунного корабля".
Они пожали друг Другу руки. "Я только об одном вас попрошу, г-н Костер,- сказал Беркли серьезным тоном,- переправляйте ко мне все, что хотите - в конце концов, вам командовать техническим парадом - но, ради бога, записывайте все, чтобы я был в курсе дела. У вас будет кнопка, включающая мой диктофон".
"Отлично"- Костер, как показалось Гарриману, молодел на глазах.
"А если вам понадобится что-нибудь, что не имеет отношения к проблеме, не делайте этого сами. Нажмите на кнопку и свистните - и все будет сделано". Беркли взглянул на Гар-римапа. "Босс говорит, что хочет обсудить с вами настоящее дело. Так что я вас покину". Он вышел.
Гарриман уселся. Костер последовал его примеру и вздохнул: "Уф!".
- Ну как, легче?
- Мне этот парень сразу понравился.
- Ну вот и хорошо, теперь он - ваша тень. Не беспокойтесь, он у меня и раньше работал. Вам покажется, что вы живете в хорошем пансионате2).
Этот отрывок вряд ли нуждается в комментариях. Для эффективной работы такая организация вполне приемлема.
Я считаю, что этот последний метод организации более всего пригоден для маленьких коллективов, таких, как обсуждаются в гл. III "Хирургическая бригада", в то время как продюсер в качестве верховного руководителя - это наиболее приемлемая форма организации для больших поддеревьев действительно крупного проекта.
Вавилонская башня была, возможно, первым инженерным фиаско, но не последним. Установление связи и, как ее следствие, организация наиболее важны для успеха. Методика связи и организации требуют от руководителя столько же способностей и компетенции, как и само создание математического обеспечения.
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).
IX. ДЕСЯТЬ ФУНТОВ В ПЯТИФУНТОВОМ МЕШКЕ
"Автор должен брать пример с Ноя и научиться, как он это делал на своем ковчеге, помещать так много всего в таком малом объеме.
(Сидней Смит "Эдинбургское обозрение")
Размер программы как стоимость
Какова стоимость программы? Если не рассматривать время выполнения программы, то именно ее объем является основным показателем ее стоимости в глазах пользователя. Это справедливо даже для арендуемых программ, где пользователь платит автору сумму, составляющую, по сути, часть стоимости разработки. Рассмотрим диалоговую систему математического обеспечения APL, разработанную фирмой IBM. Она сдается в аренду за 400 долларов в месяц и требует для своего использования по крайней мере 160 тыс. байтов памяти. В модели ЩМ 370/165 стоимость аренды памяти составляет 12 долларов за тысячу байтов в месяц. Если программа работает круглосуточно, то стоимость ее использования составит 400 долларов за математическое обеспечение и 1920 долларов за память. Если система APL используется только 4 часа в день, то стоимость составит 400 долларов арендной платы ва математическое обеспечение и 320 долларов за память в месяц.
Нередко приходится слышать, с каким ужасом воспринимается тот факт, что в машине с памятью 2 млн. байтов операционная' система может занимать 400 тыс. байтов. Ужасаться так же глупо, как критиковать Боинг 747 за то, что он стоит 27 миллионов долларов. Необходимо только задать себе вопрос: а что операционная система делает? Что можно получить аа свои деньги в смысле удобства и производительности (при эффективном использовании системы)? Может быть, 4800 долларов в месяц, затрачиваемые на аренду памяти, более целесообразно истратить на другое оборудование, на программистов, на прикладные программы?
Разработчик системы превращает часть отведенных ему ресурсов оборудования в память с резидентными программами, когда он уверен, что для пользователя это лучше, чем иметь дело с сумматорами, дисками и т. д. Поступать иначе было бы в высшей степени безответственно, и результат должен оцениваться как одно целое. Нельзя критиковать систему программирования за размер как таковой, и в то же время постоянно выступать за все более тесное объединение проектов создания аппаратуры и математического обеспечения.
Поскольку львиная доля затрат пользователя отводится на программу, разработчик комплексного программного продукта должен установить контрольные цифры, следить за их соблюдением и придумывать методы уменьшения размеров программ точно так же, как разработчик аппаратуры устанавливает контрольные значения числа компонент, следит за их соблюдением и изобретает методы их сокращения.
Контроль за размерами программ
Управление размерами программ представляет для руководителя проекта частично техническую, а частично - административную задачу. Для установления размеров предлагаемых систем необходимо изучить потребности пользователей и те прикладные области, в которых они работают. Далее эти системы следует разбить на части и определить контрольные цифры размеров каждой компоненты. Поскольку с изменением размеров программы быстродействие меняется очень резко, установление контрольных цифр требует от руководителя профессиональной ловкости и знания допустимых соотношений в каждой части системы. Кроме того, мудрый руководитель всегда оставляет для себя лазейку, которой он сможет воспользоваться впоследствии. Хотя в OS/360 все это было проделано очень тщательно, не обошлось без болезненных уроков. Во-первых, недостаточно просто установить контрольные цифры размеров оперативной памяти, необходимо учесть все аспекты, связанные с размером программы. Большая часть предыдущих операционных систем размещалась на лентах и поскольку поиск на лентах занимал много времени, это препятствовало их интенсивному вызову из сегментов программы. Система OS/360, как и ее непосредственные предшественники - операционные системы Stretch и DOS IBM 1410/7010, располагалась на дисках. Ее создатели наслаждались свободой дешевого обращения к дискам. Первоначальный результат был катастрофичным для производительности.
При установлении размеров оперативной памяти для каждой компоненты бюджет расхода памяти не устанавливался заранее. Как и предсказывали сверхпроницательные люди, программист, обнаруживая, что его программа выходит за отведенный ему участок оперативной памяти, разбивал ее на сегменты. Тем самым увеличивались общие размеры системы и уменьшалась скорость выполнения. Наша служба административного контроля не выявляла таких случаев. Каждый сообщал, какой объем оперативной памяти он использует, и если программист оставался в пределах контрольных цифр, то никто не беспокоился. К счастью, пришел день, когда начала работать программа, моделирующая производительность OS/360. Первые же результаты показали, что не все благополучно. Фортран Н на машине IBM 360/65 с барабанами транслировался со скоростью пять операторов в минуту. Расследование показало, что модули управляющей программы осуществляли слишком много обращений к дискам. Даже очень часто используемые модули супервизора "ходили к колодцу с наперстками" п результат весьма напоминал непрерывную "лихорадку" памяти.