.

5.1. Размер проекта.

Важнейшим фактором влияния в оценке программного обеспечения является размер разрабатываемой программы, потому что он подвержен наибольшему разнообразию по сравнению со всеми остальными факторами. На рис. 5.1 показана зависимость роста объема работ в среднем проекте бизнес-системы при увеличении размера проекта с 25 ООО до 1 ООО ООО строк кода. Размер проекта на рисунке выражается в строках программного кода (LOC), но динамика останется одной и той же независимо от того, в чем измеряется размер — в функциональных пунктах, длине списка требований, количестве веб-страниц или любых других показателях, выражающих те же диапазоны.

Как видно из диаграммы, система, состоящая из 1 ООО ООО строк кода, потребует гораздо большего объема работы, чем система, состоящая из 100 ООО строк.

Утверждение о том, что размер проекта является основным фактором, определяющим затраты, покажется кому-то тривиальным, однако многие организации часто нарушают этот основополагающий принцип в двух отношениях:.

• затраты, объем работы и сроки оцениваются без информации о размере проекта;.

• затраты, объем работы и сроки не регулируются при сознательном увеличении размера проекта (то есть в ответ на запросы о внесении изменений).

Рис. 5.1. Рост объема работ в типичном проекте бизнес-системы. Конкретные числовые показатели имеют смысл только для средних бизнес-систем, но общая динамика применима к программным проектам всех типов.

СОВЕТ № 24 -.

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

Почему в книге размер задается в количестве строк программного кода?.

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

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

Издержки масштаба.

Мы часто полагаем, что на построение системы, в 10 раз большей другой, потребуется в 10 раз больше усилий. Однако объем работы для системы в 1 ООО ООО строк превышает 10-кратный объем работы для системы в 100 ООО строк, а последний более чем в 10 раз превышает объем работы для системы в 10 000 строк.

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

. Динамика роста показана на рис. 5.2.

Рис. 5.2. Количество коммуникационных путей в проекте возрастает пропорционально квадрату числа участников.

Следствием экспоненциального роста количества коммуникационных каналов (наряду с другими факторами) является экспоненциальный рост трудоемкости с увеличением размера проекта. Данное явление называется издержками масштаба (diseconomy of scale).

Вне области программного обеспечения мы обычно говорим об экономии масштаба, а не об издержках масштаба. Экономия масштаба означает примерно следующее: «Если построить больший обрабатывающий завод, мы сможем сократить стоимость единицы товара». Другими словами, чем больше объем, тем ниже стоимость.

С издержками масштаба дело обстоит наоборот — с увеличением масштаба системы стоимость каждой единицы повышается. Если бы в области программного обеспечения проявлялся эффект экономии масштаба, то стоимость системы в 100 ООО строк была бы меньше 10-кратной стоимости системы из 10 ООО строк. На практике почти всегда наблюдается обратное явление.

На рис. 5.3 продемонстрированы типичные издержки масштаба в области программного обеспечения по сравнению с увеличением объема работы, ассоциируемого с линейным ростом.

Рис. 5.3. Издержки масштаба в типичных проектах бизнес-систем от 10 ООО.

до 100 000 строк кода.

Как видно из графика, в данном примере на систему в 10 000 строк кода потребуется 13,5 человеко-месяцев. Если бы объем работ возрастал линейно, то система в 100 000 строк потребовала бы 135 человеко-месяцев, но в действительности она требует 170 человеко-месяцев.

На рис. 5.3 эффект издержек масштаба не выглядит особенно впечатляющим. Действительно, в диапазоне от 10 000 до 100 000 строк он не так уж силен. Тем не менее два фактора способны сделать эффект издержек масштаба более радикальным. Один фактор — это большие различия в размерах проекта, а другой — условия проекта, снижающие производительность при росте размера проекта. На рис. 5.4 изображен диапазон результатов для проектов в интервале от 10 ООО до.

1 ООО ООО строк. Кроме номинальных издержек масштаба, на графике также показаны издержки в наихудшем случае.

Рис. 5.4. Издержки масштаба в проектах с большими различиями в размерах, а также.

издержки в худшем случае.

Из графика видно, что объем работы при худших издержках растет гораздо быстрее, чем при номинальных, а при больших размерах проекта эффект выражен гораздо ярче. В соответствии с кривой номинального роста, объем работы для 100 ООО строк кода превышает объем работы для 10 ООО строк не в 10, а в 13 раз. При 1 ООО ООО строк кода объем работы превышает объем работы для 10 000 строк уже не в 100, а в 160 раз.

С худшими издержками дело обстоит еще хуже. Объем работы для худшего случая при 100 000 строк кода в 17 раз превышает объем для 10 000 строк, а при.

1 000 000 строк он больше не в 100, а в целых 300 раз!.

В табл. 5.1 продемонстрирована общая связь между размером проекта и производительностью.

Цифры, приведенные в таблице, действительны только для сравнения между диапазонами размеров. Тем не менее представленная ими общая тенденция весьма важна. Производительность в мелких проектах в 2-3 раза превышает.

производительность в крупных проектах, а между тем самый мелкий проект может превосходить самый крупный по производительности в 5-10 раз.

Таблица 5.1. Связь между размером проекта и производительностью

Источник: По данным «Measures for Excellence» (Putnam and Meyers 1992), «Industrial Strength Software» (Putnam and Meyers 1997), «Software Cost Estimation with Cocomo II» (Boehm et al. 2000) и «Software Development Worldwide: The State of the Practice» (Cusumano etal. 2003).

СОВЕТ № 25 -.

He следует предполагать, что объем работ линейно зависит от размера проекта. Рост происходит по экспоненте.

В том, что касается издержек масштаба, имеются как положительные, так и отрицательные стороны. Начнем с отрицательных: при существенных различиях в размере проектов новый проект нельзя оценивать применением простого масштабного коэффициента к объему работ, известному по предыдущим проектам. Скажем, если объем работ для предыдущего проекта в 100 ООО строк кода составил 170 человеко-месяцев, можно предположить, что производительность составляет 100 000/170, то есть 588 строк кода на человеко-месяц. Данное предположение может быть разумным для другого проекта примерно такого же размера, но если новый проект в 10 раз больше, такая оценка производительности может оказаться смещенной на величину от 30 до 200 %.

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

СОВЕТ № 26 -.

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

Когда можно смело игнорировать издержки масштаба.

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

использовать простой масштабный коэффициент — скажем, количество строк кода на человеко-месяц. На рис. 5.5 показаны относительно малые различия при линейном и экспоненциальном росте в конкретном диапазоне размеров.

Рис. 5.5. Различия между оценками, полученными с применением простых коэффициентов, и оценками с учетом издержек масштаба, в одном диапазоне размеров будут более.

или менее минимальными.

СОВЕТ № 27 -.

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

Важность издержек масштаба при оценке программных проектов.

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

5.2. Тип программы.

После размера проекта наибольшее влияние на оценку оказывает тип создаваемой программы. Если вы работаете над критически важным проектом, к которому предъявляются особые требования, проект потребует гораздо большего объема работ, чем проект бизнес-системы аналогичного размера. В табл. 5.2 приведены примеры производительности (в строках кода на человеко-месяц) для проектов разных типов.

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

Иапочник: По данным «Measures for Excellence» (Putnam and Meyers 1992), «Industrial Strength So/tmim» (Putnam and Meyers 1997) и «Him Core Metrics* (Putnam and Meyers 2003).

Как пидно.на таблицы, группа, разрабатывающая интрасетевую систему для внутреннего использования, может генерировать код в 10-20 раз быстрее, чем группа, работающая над проектом управления авиационным оборудованием, системой реального времени или встроенной системой. Таблица также в очередной раз демонстрирует издержки масштаба: в проектах на 100 ООО строк код генерируется гораздо менее эффективно, чем в проектах на 10 000 строк, а в проектах на 250 000 строк эффективность оказывается еще ниже.

Область, для которой создается программное обеспечение, можно учесть тремя способами.

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

• Используйте модель оценки (такую, как Cocomo И) и отрегулируйте параметры оценки в соответствии со спецификой разрабатываемой программы. Если вы пойдете по этому пути, вспомните предостережения из главы 4.

о чрезмерном количестве регуляторов.

• Используйте данные, полученные ранее вашей организацией; тем самым в оценку автоматически включаются факторы разработки, действующие в вашей отрасли. Данный способ однозначно является лучшим из трех. Использование исторических данных более подробно рассматривается в главе 8.

СОВЕТ № 28 .-.

В своей оценке учитывайте тип разрабатываемой программы — в отношении влияния на объем работы и сроки этот фактор является вторым по значимости.

5.3. Факторы персонала.

Факторы, связанные с подбором персонала, также оказывают значительное влияние на результат проекта. В соответствии с данными Cocomo II, в проекте на 100 ООО строк кода суммарный эффект всех факторов персонала способен изменить оценку проекта в 22^эаза! Другими словами, если проект получает наихудший показатель в каждой категории, показанной на рис. 5.6 (светлые полосы), на его реализацию уйдет в 22 раза больше времени, чем на проект с лучшими показателями по каждой категории (темные полосы).

Рис. 5.6. Зависимость объема работы над проектом от факторов персонала. В зависимости от силы или слабости каждого фактора результаты проекта могут изменяться на указанную величину, то есть если выработкой требований будут заниматься худшие аналитики, объем работы возрастает на 42 % по сравнению с номиналом, а при лучших аналитиках он снижается на 29 %.

различия от 10:1 до 20:1 в производительности отдельных участников и целых групп (Sackman, Erikson, and Grant 1968; Weinberg and Schulman 1974; Curtis 1981; Mills 1983; Boehm, Gray, and Seewaldt 1984; DeMarco and Lister 1985; Curtis et al 1986; Card 1987; Boehm 1987b; Boehm and Papaccio 1988; Valett and McGarry 1989; Boehm et al. 2000).

Одно из следствий подобных расхождений заключается в том, что точная оценка проекта невозможна без некоторого представления о том, кто будет заниматься его выполнением, потому что производительность работников может отличаться в 10 раз и более. Тем не менее в рамках одной конкретной организации такого разброса, скорее всего, не будет, потому что разработчики как верхнего, так и нижнего уровня обычно склонны выбирать организации, в которых работают другие люди аналогичного уровня (Mills 1983, DeMarco and Lister 1999).

Есть и другое следствие: выбор метода, обеспечивающего наиболее точную оценку, зависит от того, знаете ли вы, кто именно будет выполнять оцениваемую работу. Эта тема обсуждается в главе 16.

5.4. Язык программирования.

Язык программирования, используемый в проекте, влияет на оценку по меньшей мере в четырех отношениях.

Во-первых, как видно из рис. 5.6, опыт работы группы с конкретным языком и инструментарием, используемыми в проекте, способен изменить общую производительность в проекте до 40 %.

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

Таблица 5.3. Относительная функциональность команд языков высокого уровня по сравнению с эквивалентным кодом С

Если используемый язык программирования заранее известен, этот пункт не относится к вашей оценке. Но если вы обладаете некоторой свободой выбора языка программирования, из таблицы видно, что такие языки, как Java, C# и Microsoft Visual Basic, обычно превосходят по продуктивности С, Cobol или макроассемблер.

Третий фактор, также относящийся к языкам, — широта возможностей инструментария и рабочих сред. Согласно данным Cocomo II, слабый инструментарий и рабочая среда способны увеличить объем работы над проектом примерно на 50 % по сравнению с сильными инструментариями и рабочими средами (Boehm et al. 2000). Также следует понимать, что выбор языка программирования может определить выбор инструментария и рабочей среды.

Последний фактор, связанный с языком программирования, заключается в том, что разработчики, использующие интерпретируемые языки, обычно работают продуктивнее тех, кто применяет компилируемые языки — выигрыш составляет до 2 раз (Jones 1986а, Preschelt 2000).

Концепция объема функциональности на строку кода будет рассматриваться далее в разделе 18.2.

5.5. Другие факторы.

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

В табл. 5.4 перечислены рейтинги 17 множителей объема работы в модели Cocomo II. В столбце «Очень низкие» представлена величина, на которую следует отрегулировать оценку объема работы для лучшего (или худшего) воздействия данного фактора. Например, если группа обладает крайне низким опытом работы в прикладной области, номинальная оценка объема работы Cocomo II умножается на 1,22. Если же группа очень хорошо разбирается в предметной области, оценка вместо этого умножается на 0,81.

В крайнем правом столбце «Влияние» показана степень влияния каждого отдельно взятого фактора на общую оценку рабочего времени. Скажем, у фактора квалификации в предметной области в этом столбце стоит значение 1,51; это означает, что проект, выполняемый группой с очень низкой квалификацией в этой области, потребует в 1,51 раза больший объем работы, чем у группы с очень высокой квалификацией (влияние вычисляется делением наибольшего значения на наименьшее — например, 1,51 = 1,22/0,8).

На рис. 5.7 изображено другое представление факторов Cocomo II; факторы упорядочиваются по убыванию влияния.

Рис. 5.7. Факторы Cocomo И по убыванию значимости. Относительная длина полос представляет чувствительность оценки к различным факторам.

На рис. 5.8 те же факторы представлены в зависимости от своего потенциала к увеличению (светлые полосы) или снижению (темные полосы) общего объема работы.

Рис. 5.8. Факторы Cocomo Ц по способности увеличивать (светлые полосы) или уменьшать (темные полосы) общий объем работы.

Некоторые замечания по поводу этих факторов приведены в табл. 5.5.

Таблица 5.5. Регулирующие факторы Cocomo И

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

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

5.6. Снова об издержках масштаба.

Регулирующие факторы Cocomo II позволяют взглянуть на издержки масштаба с новой интересной точки зрения. Пять из факторов, изображенных на рис. 5.9, называются масштабными факторами — это те факторы, которые вносят свой вклад.

5.6. Снова об издержках масштаба 87.

в издержки масштаба программного проекта. Они в разной степени влияют на проекты разных размеров. На рис. 5.9 масштабные факторы выделены светлым.

Рис. 5i9. Факторы Cocomo И; масштабные факторы выделены светлым.

Приведены данные для проекта на 100 ООО строк кода.

Ни один из факторов, вносящих вклад в издержки масштаба проекта, не находится в верхней половине факторов, упорядоченных по значимости. Более того, 4 из 5 наименее значимых факторов являются масштабными. Тем не менее, поскольку масштабные факторы вносят разный вклад в зависимости от размера проекта, диаграмма должна составляться для проекта конкретного размера. Данные на рис. 5.9 приведены для проекта на 100 ООО строк кода. На рис. 5.10 показано, что происходит при пересчете факторов для гораздо большего проекта на 5 000 000 строк кода.

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

Рис. 5.10. Факторы Cocomo II; масштабные факторы выделены светлым. Приведены данные для проекта на 5 ООО ООО строк кода