Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Тех-экон. обоснование.doc
Скачиваний:
58
Добавлен:
26.03.2015
Размер:
366.59 Кб
Скачать

6. Производительность труда в группе разработчиков

Возможные подходы к оценке производительности труда группы разра­ботчиков

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

К сожалению, среди менеджеров все еще существует представление о том, что при нарушении сроков выполнения работ, всегда можно добавить не­которое количество программистов и наверстать потерянное время. На прак­тике человеко-месяц как единица измерения объема работы для менеджера проекта крайне опасная и неверная. Дело в том, что человек и месяц взаимозаменяемы только тогда, когда работу можно распределить между несколь­кими независимо работающими исполнителями. На практике работа коллекти­ва людей даже при достаточно четком разделении решаемых ими функцио­нальных задач, относящихся к общей проблеме создания программного про­дукта, требует постоянного их взаимодействия: согласования возникающих вопросов, уточнения технических требований и т. д. Подключение дополни­тельных исполнителей в процессе работы над проектом приводит к дополни­тельным непроизводительным затратам времени. Новые люди должны быть обучены, ознакомлены с системой, принятыми методами и средствами проек­тирования, а те, кто их будет обучать, должны будут оторваться от работы, которую они выполняют в соответствии с планом. Пока проходит обучение, работа не выполняется и отставание проекта растет.

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

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

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

Второй подход основан на использовании для расчетов установленной эмпирической закономерности - производительность труда отдельного работника падает пропорционально корню кубическому из n. Это так называемый закон Филиппа.

Третий подход использует модель Путнема, в которой (также на осно­вании опытных данных) представлена взаимосвязь основных параметров про-' граммного проекта. В результате использования этой модели также появляет

ся возможность выявить зависимость производительности труда от числа исполнителей n.

Ниже представлено описание использования этих трех методик для оценки производительности труда группы разработчиков:

  1. учет взаимосвязей людей в группе (две модификации);

  2. учет закона Филиппа при оценке производительности труда;

  3. использование модели Путнема для оценки параметров проектов при отклоненениях от оптимальных сроков разработки.

Рассмотрим эти подходы к оценке производительности труда коллек­тива разработчиков более подробно.