Яке безпосередній вплив надає рівень взаємодії розробників на виконання проекту? Найбільш очевидним параметром є час завершення проекту. Якщо одним фахівцям регулярно доводиться чекати інших для вирішення будь-яких питань, то затримки неминучі. Вони виникають і при звичайній, нерозподіленого, розробці, але бувають значно меншими за часом. Опитування розробників декількох десятків компаній з Великобританії та Німеччини, проведене дослідницьким підрозділом Lucent Technologies, дав наступні результати. При роботі в межах одного будинку кожен реципієнт стикався в середньому з 2,1 затримки в місяць при тривалості кожної 0,9 робочого дня. При розподіленої розробці виникало 1,9 затримки на місяць, але їх середня тривалість становила вже 2,1 дня. Отже, різниця в кількості затримок при локальній і розподіленої розробці несуттєва, тоді як різниця в їх тривалості досить відчутна. p align="justify"> Приблизно ті ж результати отримані при аналізі запитів на зміну проекту в цілому. У середньому при локальної розробці на одну істотну зміну в проекті (виправлення помилок або додавання нових функцій) було потрібно 5 днів (з початку реальної роботи до внесення останніх змін в код - це називається В«робочим інтерваломВ»). Якщо у створенні програмних продуктів брали участь декілька віддалених колективів, такий інтервал збільшувався до 12,7 дня (тобто більш ніж у два з половиною рази). Ситуація з повним інтервалом (часом з моменту надходження запиту на зміну до внесення останньої зміни в код; цей інтервал дещо більше робочого, оскільки включає в себе час, необхідний для аналізу запиту, призначення пріоритету тощо) аналогічна: 20,5 дня проти 12,7.
Кількість і тривалість затримок залежать від ряду параметрів, що характеризують кожен проект створення програмного забезпечення. Виявлення залежності цих параметрів від затримок допоможе звести останні до мінімуму. З використанням статистичних даних, отриманих, у тому числі при опитуванні декількох сотень розробників, було проаналізовано вплив наступних параметрів на тривалість затримок. p align="justify"> В· Число зайнятих у проекті розробників. Логічно припустити, що при збільшенні числа розробників зростає кількість і тривалість затримок.
В· Розподіл змін по віддалених об'єктах. Чим більше кількість модулів системи, уражених змінами (особливо якщо ці модулі розробляються в різних місцях), тим більш ймовірні затримки.
В· Масштаб змін. Чим більше змін вноситься, тим більше ймовірність затримок.
В· Час першої модифікації вихідного коду. Вважається, що час, що витрачається на зміну продукту з метою виправлення помилок, відрізняється від часу зміни при додаванні нових функцій.
В· Серйозність змін. Даний фактор можна розглядати як анал...
