Закон Брукса – СД в разработке программного обеспечения


Автор:

manlaptol.jpg

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

(По мотивам книги “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 дне

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

image

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


5 отзывов

  • By Serhiy Yevtushenko, July 4, 2008 @ 7:01 pm

    Ребята, по поводу анализа закона Брукса посмотрите Jerry Weinberg “Quality Software Management. Volume 1 – System Thinking”. Там динамика обсуждается подробно.

    Ответить

    Bayram Annakov Ответ:

    Сергей, а у вас нет в электронном виде этой книги случайно?

    Ответить

  • By Bayram, July 5, 2008 @ 1:47 pm

    Сергей, спасибо за ссылку! Посмотрю. По-моему Madachy в своей книге ссылается на Вейнберга

    Ответить

  • By Павел, January 13, 2014 @ 4:58 pm

    0,06n^2, где n – количество людей в команде

    Я правильно понял, что затраты вычисляются в процентах?

    Ответить

Ссылки на эту статью

  1. Red Hen » Йордон о моделировании процессов разработки ПО — November 6, 2008 @ 5:02 am

Оставить отзыв

WordPress Themes