Empatika

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

(По мотивам книги “Software process dynamics” Raymond Madachy)

Скачать модель

В легендарной книге “Мифический человеко-месяц” Фредерик Брукс как-то сказал, что добавление новых разработчиков в опаздывающий проект еще больше затягивает окончание проекта. Брукс объяснял этот феномен тем, что при расширении команды “старожилам” проекта приходится обучать “новичков”, а также то, что нелинейно возрастает объем коммуникаций внутри команды.

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

Реализацией требований занимаются разработчики, которых мы поделим на 2 категории “Новички” и “Старожилы”. Это деление необходимо, чтобы смоделировать суть закона Брукса о введении новых разработчиков. “Новички” ассимилируются со “Старожилами” (т.е. опустошается резервуар новичков и пополняется резервуар старожилов) в течение 20 дней (для разных проектов это могут быть разные значения).

Интенсивность потока разработки ПО зависит от производительности программистов. Производительность новичков примем равной 80% средней производительности, а производительность старожилов - 120% средней производительности.

Но, производительность старожилов снижается за счет того, что приходится тратить время на обучение новичков (примем, что в среднем 25% времени старожилам нужно тратить на обучение до тех пор, пока новички не станут старожилами). А также производительность всей команды снижается за счет затрат на коммуникацию и координацию работы. Функция зависимости затрат на комуникацию от размера команды нелинейна и мы возьмем её формулировку из известной модели управления проектами Абдель-Хамида (Abdel Hamid) = 0,06n^2, где n - количество людей в команде.

Возьмем проект размером 500 функциональных единиц (распространенная мера размера проектов ПО) и проведем следующие эксперименты:

1. Без добавления новых программистов
2. С добавлением 5 новых программистов на 110 дне
3. С добавлением 10 новых программистов на 110 дне

Результаты можно увидеть на графике ниже:

На графике мы можем заметить, что при 1м эксперименте все требования реализованы за 274 дня, при 2м - за 271 день, а при 3м - за 296 дней. Эта модель демонстрирует, что закон Брукса работает только в определенных случаях (но Брукс и не говорил, что закон работает всегда). Поэтому, переформулировав закон Брукса, можно сказать, что добавление новых разработчиков в опаздывающий проект еще больше затягивает финиш проекта при условии, что слишком поздно и слишком много их добавлено.

Вы можете оставить свои комментарии ниже или сослаться на этот пост в своем блоге. Для это используйте эту ссылку - trackback