П€И1(Э ешлка Данные Данные для этой таблицы получены на основе специализи-

прштавяйют собой среднее рованных проектов, и эти числа могут иметь мало общего с

значение. Горстка организаций данными проектов, над которыми вы работаете. Однако в ка-

сообщает о яуншем соотнош- честве моментального снимка для отрасли они весьма пока-

нйи ошибок, че« приведенные зательны: число ошибок значительно возрастает при увели-здесь ммнймзшьные &ея1(мииы

Примеры см. в подразделе чении размера проекта, и очень большие проекты имеют до

«Сколько ошибок 8Ы можете четырех раз больше ошибок на 1000 строк кода, чем малень-

найтй?» раздела 22.4. кие. Для достижения одинакового соотношения ошибок в

больших проектах придется приложить больше усилий.

27.4. Влияние размера проекта на производительность

Когда речь заходит о размере проекта, производительность имеет много общего с качеством ПО. При небольших размерах (2000 строк кода и менее) наибольшее влияние на производительность оказывает мастерство отдельного программиста (Jones, 1998). С увеличением размера проекта все больше на производительность начинают влиять численность команды и организация.

Насколько большим должен быть проект, чтобы численность команды раз-HL Рботчиков стала влиять на производительность? В «Prototyping Versus

Specifying: а Multiproject Experiment» Бом, Грей и Сиволдт (Boehm, Gray and Seewaldt) сообщали, что команды меньших размеров выполняли проекты с производительностью на 39% выше, чем более многочисленные команды. Размер команд? Два человека для маленьких проектов и три - для больших (1984). Табл. 27-2 позволяет получить представление о взаимосвязи между размером проекта и производительностью.

Табл. 27-2. Размер проекта и производительность

Число строк кода на человека в год (в скобках указано номинальное Размер проекта (число строк кода) значение Cocomo II*)

IK 2500-25 000 (4000)

lOK 2000-25 000 (3200)

lOOK 1000-20 000 (2600)

1 ОООК 700-10 000 (2000)

lOOOOK 300-5000 (1600)

Источники: Составлено на основе данных из «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 Woridwidc: The State of the Practice* (Cusumano et al., 2003).

Constnactive Cost Model (конструктивная стоимостная модель) - метод оценки затрат на раз-р;ботку ПО. - Прим. перев.

Производительность в значительной степени определяется видом ПО, над которым вы работаете, квалификацией персонала, языком программирования, методологией, сложностью продукта, программной средой, инструментарием, способом подсчета «строк кода», тем, как усилия по поддержке, не относящиеся напрямую к программированию, переводятся в «количество строк кода на человека в год», и другими факторами. Поэтому конкретные цифры в табл 27-2 очень сильно отличаются.

Однако тенденция, представленная этими числами, очень показательна Производительность в малых проектах может быть в 2-3 раза выше, чем в больших, а разница в производительности между самыми маленькими и самыми большими проектами может достигать 5-10 раз.

27.5. Влияние размера проекта на процесс разработки

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

Соотношение между выполняемыми операциями и размер

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

100%

Процентное распределение времени разработки

Системное тестирование

Интеграция

СоШ1Ш й«го

Создание архитектуры

128К

512К

Размер проекта в строках кода

Рис. 27-3. Конструирование преобладает в маленьких проектах Проекты большего размера требуют больших затрат на архитектуру, интеграцию и системное тестирование Работа по составлению технических требований на этой диаграмме не показана, потому что в отличие от других операций эти усгыия не зависят от размера программы напрямую. (Albrecht, 1979; Glass, 1982; Boehm, Gray and Seewaldt, 1984; Boddie, 1987; Card, 1987; McGarry, Waligora and McDermott, 1989; Brooks, 1995; Jones, 1998; Jones, 2000; Boehm et al, 2000)

В малых проектах конструирование является наиболее заметной частью проекта: на него приходится до 65% всего времени разработки. В средних по величине проектах конструирование все еще доминирует, но его доля снижается до 50% от всех трудозатрат. В очень больших проектах архитектура, интеграция и системное тестирование занимают все больше времени, и доля конструирования становится все менее заметной. Короче, при возрастании размера проекта доля конструирования в общих затратах уменьшается. Этот график выглядит так, будто при его продолжении вправо конструирование исчезнет совсем. Поэтому, чтобы не остаться без работы, я ограничился размером в 512К.

Доля конструирования снижается, потому что с ростом размера проекта все составляющие конструирования: проектирование, кодирование, отладка и модульное тестирование - пропорционально масштабируются, однако затраты на другие виды деятельности растут гораздо быстрее (рис. 27-4).

Трудозатраты

Другие виды деятельности

Конструирование

Размер

Рис. 27-4, Объем работ по конструированию ПО - практически линейная функция от размера проекта. Трудозатраты на другие виды работ при увеличении проекта растут нелинейно

В близких по размеру проектах будут выполняться примерно одинаковые операции, однако при расхождении в размерах виды выполняемых действий тоже начнут различаться. Как сказано во вступлении к этой главе, если Gigatron Deluxe в 10 раз больше начального Gigatron, он потребует в 25 раз больше затрат на конструирование, в 25-50 - на планирование, в 30 - на интеграцию и в 40 - на архитектуру и системное тестирование.

........ Соотношение между видами деятельности изменяется, потому что при

JJiyil разных размерах проекта разные виды деятельности становятся критическими. Барри Бом и Ричард Тернер (Barry Boehm and Richard Turner) выяснили, что расходы на проработку архитектуры в пределах 5% от общей стоимости проекта позволяют минимизировать затраты для проектов, содержащих примерно 10 000 строк кода. Но наилучшие результаты можно получить, если в проектах размером в 100 000 строк кода израсходовать на архитектуру 15-20% средств (Boehm and Turner, 2004).

Далее приведены виды деятельности, затраты на которые с ростом размера проекта увеличиваются нелинейно:

взаимодействие;

планирование;

управление;

разработка требований;

функциональное проектирование системы;