Джозеф Фокс - Программное обеспечение и его разработка

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

Нам не известно, как надо измерять производительность труда при программировании или разработке программного обеспечения. Мы только начинаем разрабатывать терминологию и средства измерения. Многого мы еще не понимаем. Для описания трудности работы мы используем такие термины, как «тяжелая» или «очень тяжелая», «большая» или «огромная». От таких терминов особой помощи ждать не приходится.

Более полезным оказывается способ измерения, связанный с подсчетом числа команд или строк текста программы (СТП). Используя это понятие, мы, например, говорим, что данная работа или функция — скажем, составление платежной ведомости — требует 50 тыс. строк программы.

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

Наше измерение в строках текста за единицу времени приводит к поощрению неэффективного проектирования или небрежного программирования. Программист А работает по плохому проекту и имеет «рыхлую» программу и поэтому за единицу времени смог написать больше строк текста программы.

В этой области можно собрать весьма интересные статистические данные. Те, кто утверждает, что знаком со средними цифрами производительности, ошибаются; для определения средних величин производительности труда еще не собрано достаточно данных.

Строки текста можно уподобить числу мазков, которые наносит маляр при покраске дома. То, что один маляр нанес меньше мазков, чем второй, не означает ровным счетом ничего до тех пор, пока мы не сравним результаты работы обоих.

Когда я захотел представить группу, добившуюся колоссальной производительности труда при работе над проектом для газеты «Нью-Йорк таймс», к премии за выдающиеся достижения, я обнаружил, что во всей фирме IBM не имелось данных о производительности труда.

Мы решили, что начнем измерять строки программ. У нас уже были, в наших отчетах по контракту, записи о часах работы каждого члена группы, времени, использованном на каждую работу, о категориях всех наших сотрудников (руководитель, аналитик, программист и т. д.) и об их заработной плате. У нас были сведения обо всем — так мы думали. И почти сразу же мы обнаружили, что никто из нас не имел точного определения «строки программы»! А также и «человеко-месяца»!

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

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

Полезно знать или иметь оценки числа строк исходной программы, которые помогают измерять и оценивать производительность труда, или число программистов, необходимых для выполнения данной работы. Исходные программы обычно пишутся на языках высокого уровня.

И, хотя строка программы, написанной на языке высокого уровня, обычно называется оператором, мы редко используем число операторов, написанных за день, как меру производительности труда, в качестве стандартной меры мы предпочитаем строку программы. Обе меры полезны — и число исходных строк, и число строк рабочей программы, но следует быть осторожными и по небрежности не путать их между собой. Каждая из них полезна для своих целей.

Итак, термин «строка программы» имеет два значения, причем полезными оказываются оба значения: