О некоторых характеристиках личной производительности труда программистов

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

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

В данном исследовании использовались данные, полученные в результате хронометража труда одного программиста в течение восьми лет. С начала своей программистской деятельности и до сего времени автор вел ежедневный учет личного времени (как рабочего, так и внерабочего) с точностью от 5 до 30 минут. Для оперативного управления бюджетом времени и для проведения различных статистических исследований была создана система I - личный банк данных, функционирующий в ОС ЕС. В настоящее время в базе данных находится более 50 тыс. записей о затратах времени, в том числе и о затратах времени на девять программных систем и десять одиночных программ. Для каждого из этих программных проектов была получена следующая информация: общие затраты времени (в минутах, человеко-днях и "реальных" человеко-днях, т. е. днях, в которые действительно велась работа над данным проектом); то же с разбивкой на категории: проектирование, программирование и отладка, вспомогательная работа, коммуникации, документация; а также процентные соотношения затрат времени по категориям и относительные затраты (минут в человеко-день, минут на единицу длины и т. д.).

Поскольку исследовалась в основном личная производительность труда, время, затраченное на проект, учитывалось не в человеко-днях, а в минутах (количество человеко-дней зависит от загрузки машины, организации программистского коллектива и т. д.). Длина программы подсчитывалась по методике Холстеда (Холстед М. Начала науки о программах.- М.: Финансы и статистика, 1981.- 128 с.), т. е. складывалось количество операций и операндов. Основной исследуемой величиной было отношение количества минут, затраченных на проект, к длине программы, т. е. величина, обратная личной производительности труда. Поскольку фактически это стоимость (в минутах) единицы длины программы, эта величина была названа В-стоимостью.

Ниже показан характер изменения В-стоимости в зависимости от опыта . Опытность (лет) В-стоимость по системам В-стоимость по одиночным программам

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

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

Все это действительно так, но имеется два неожиданных факта. Во-первых, применение метода "хирургической бригады" не дало существенного уменьшения В-стоимости. При шестилетнем стаже работы автором параллельно создавались две системы: одна в одиночку, другая - "хирургической бригадой". Для первой В-стоимость равна 3,40, а для второй - 2,50, т. е. всего в полтора раза ниже. Если учесть, что на главного программиста работало четыре человека, то получается, что в целом проект обошелся дороже. По-видимому, бригадный метод, повышая надежность системы, обеспечивая концептуальную целостность, производительность труда существенно не повышает, а только перераспределяет личное время главного программиста.

Распределение затрат времени по категориям приведено ниже.

Этим подтверждается, что то время, которое ушло при одиночной работе на программирование, отладку и вспомогательную работу, просто уходит на общение при бригадном методе. Во-вторых, в 1979 г. (что соответствует третьему - четвертому году опыта) автор кардинально переменил свой стиль программирования - от так называемого беспорядочного к нисходящему и структурному. Это должно было вызвать резкое падение В-стоимости (по различным источникам "хорошее", т, е. структурное и нисходящее программирование повышает производительность труда в 3 - 5 раз). Однако никакого скачка нет. Чтобы объяснить это явление, были выдвинуты две гипотезы.

1. Хорошее программирование не уменьшает время, требуемое для реализации программы, а только перераспределяет его (например, время, раньше уходившее на отладку, теперь уходит на проектирование).

2. Хорошее программирование пропорционально сокращает и время и текст программы, поэтому В-стоимость не меняется. Эта гипотеза вполне правдоподобна, так как хорошая программа проще, а значит, короче. Кроме того, после отладки в хорошей программе остается меньше "заплат", а это тоже сокращает длину программного текста.

Чтобы проверить эти гипотезы, нужно замерить время и длину для одной и той же программы, написанной неструктурно и структурно. Такие данные были у автора, так как он дважды переписал все свои модули системы ДЕЛЬТА " причем второй раз - структурно Время на разработку неуклонно падало: 41430 минут на первую версию, 31440 минут на вторую и 26289 на третью. Если первое уменьшение времени можно объяснить тем, что система уже знакома и приемы наработаны, то второе уменьшение в основном вызвано, по-видимому, структурным написанием. Таким образом, гипотеза 1 не подтверждается.

Несмотря на то, что функциональная мощность модулей по крайней мере не уменьшалась, а для некоторых модулей возросла, общая длина их также неуклонно падает: 7696 единиц длины по Холстеду на первую версию, 7593 на вторую, и около 5000 единиц на третью, Вообще говоря, полученная по методике Холстеда длина третьей версии 6918 единиц, но эта версия была написана не на ассемблере, как предыдущие, а на структурном ассемблере, для которого методика Холстеда завышает длину в среднем на 30 %. Поэтому длина третьей версии была приведена к ассемблерному эквиваленту.

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

Однако из всего сказанного следует вывод, что критерий "время/длина", даже измеренный максимально точно (в минутах), может давать большие погрешности (в полтора - два раза). Это подтверждается и практикой конкурсов программистов, которые ежегодно проводятся в г. Красноярске. Программисты решают одну и ту же задачу при одинаковых ресурсах времени и равной оценке по количеству прогонов и исправлений, однако длины их программ существенно различаются (иногда на порядок).

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

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

Это соображение становится особенно понятным, если вспомнить, что единственным отличием программного изделия от промышленного является легкое изготовление копии. Следовательно, перенося промышленные стандарты в программирование, следует исходить не из принципов изготовления (копирования), а из принципов разработки (проектирования). Тогда сразу становится понятным, что использовать для оценки количества программной продукции длину или любую другую характеристику программы - это то же самое, что оценивать труд проектировщиков промышленного изделия размерами или сложностью его чертежей.

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

Опубликовано: Управляющие системы и машины, 1985 Nо 6
© Алексей Бабий 1985