Geum.ru

Фредерик П. Брукс

Вид материалаДокументы
Глава 8. Объявляя удар
Данные Портмана
Данные Арона
Данные Харра
Подобный материал:
1   ...   13   14   15   16   17   18   19   20   ...   48

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


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

ПУБЛИЙ

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

АЛЬМАНАХ БЕДНОГО РИЧАРДСА(Бедный Ричард - образ необразованного, ноздравомыслящего доморощенного философа, созданный Бенджамином Франклином,издававшим в 1732 - 1757 годах ежегодный альманах и использовавшим этотпсевдоним (примеч. перев.).)

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

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

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

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

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

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

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

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



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

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


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

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

Данные Арона


Джоэл Арон (Joel Aron), менеджер IBM по системным технологиям вГейтерсберге, штат Мэриленд, изучал эффективность труда программистов вовремя работы над девятью крупными системами (крупная соответствует более чем25 программистам и 30000 операторов).7 Он классифицирует такие системы всоответствии с интенсивностью взаимодействия между программистами (и частямисистемы) и обнаруживает следующие величины производительности: Очень слабое взаимодействие 10000 инструкций на человека в год Некоторое взаимодействие 5000 инструкций на человека в год Существенное взаимодействие 1500 инструкций на человека в год Человеко-год здесь не учитывает поддержку и системное тестирование,только разработку и программирование. При введении поправки с коэффициентомдва с целью учета системного тестирования эти цифры близко соответствуютданным Харра.

Данные Харра


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

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



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

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

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