Специфические проблемы при оценке объема работ

Специфические проблемы при оценке объема работ

Область применения методов этой главы
Неформальное сравнение с прошлыми проектами
Оценочные.
программы
Диаграммы среднеотраслевых объемов работ
Метод ISBSG
Что оценивается
Объем работ
Объем работ
Объем работ
Объем работ
Размер проекта
МС-
М С Б
МС-
МС-
Стадия разработки
Ранняя-средняя
Ранняя-средняя
Ранняя
Ранняя
Итеративный или.
последовательный.
стиль
Оба
Оба
Последова¬.
тельный
Последова¬.
тельный
Возможная точность
Средняя
Высокая
Низкая-средняя
Низкая-средняя
В большинстве проектов объем работ оценивается по подробному списку задач. Однако на ранней стадии проекта наиболее точными оказываются оценки объема работ, вычисленные по оценкам размера. В этой главе описаны некоторые способы вычисления этих ранних оценок.
19.1. Факторы, влияющие на объем работ.
Наибольшее влияние на объем работ оказывает размер создаваемой программы. Вторым по важности фактором является производительность вашей организации.
В табл. 19.1 представлены сведения о диапазонах производительности между разными программными проектами. Данные в таблице демонстрируют опасности, возникающие при использовании среднеотраслевых данных и при игнорировании эффекта издержек размера. Во встроенных программных проектах (таких, как проекты Lincoln Continental и IBM Checkout Scanner) код обычно генерируется медленнее, чем в коммерческих проектах вроде Microsoft Excel. При использовании «средних» данных производительности для неподходящего типа проекта оценка может оказаться ошибочной на порядок и более.
В пределах одной отрасли также возможны значительные различия в производительности. Так, для Microsoft Excel 3.0 код генерировался примерно в 10 раз быстрее, чем для Lotus 123 v.3, хотя оба проекта были направлены на создание схожих продуктов и проводились примерно в один период времени.
Даже в рамках одной организации производительность может различаться из-за влияния издержек масштаба и других факторов. Так, в проектах Microsoft Windows NT код генерировался гораздо медленнее, чем в других проектах Microsoft, потому что это были системные, а не прикладные проекты, и они отличались гораздо большими размерами.
Таблица 19.1. Примеры различий в производительности среди разных типов программных проектов (* = Оценка)
Продукт
Эквивалент в новых строках кода
Челове-.
ко-лет
Год.
созда¬.
ния
Приблизительная стоимость в долларах 2006 г.
ч*.
О.
п
LOC/.
чело-.
веко-.
год
IBM Chief Programmer Team Project
83 000
9
1968
1 400 000*
$17
9200
Lincoln Continental
83 000
35
1989
2 900 000*
$35
2400
IBM Checkout Scanner
90 000
58
1989
4 900 000
$55
1600
Microsoft Word for Windows 1.0
249 000
55
1989
8 500 000*
$34
4500
NASA SEL Project
249 000
24
2002
3 700 000*
$15
10 000
Lotus 123 v.3
400 000
263
1989
36 000 000
$90
1500
Microsoft Excel 3.0
649 000
50*
1990
7 700 000
$12
13 000
Citibank Teller Machine
780 000
150
1989
22 000 000
$28
5200
Windows NT 3.1 (первая версия)
2 880 000
2000*
194
200 000 000
$70
1400
Космический шаттл
25 600 000
22 096
1989
2 000 000 000
$77
1200
Источники: «Chief Programmer Team Management of Production Programming» (Baker 1972), «Microsoft Corporation: Office Business Unit» (Iansiti 1994), «How to Break the Software Logjam» (Schlender 1989), «Software Engineering Laboratory (SEL) Relationships, Models, and Management Rules» (NASA, 1991), «Microsoft Secrets» Cusumano and Selby 1995).
Согласно табл. 19.1, наименьшая производительность в строках кода на человеко-год наблюдалась при разработке программного обеспечения космического шаттла, но называть эту группу разработчиков непроизводительной было бы ошибкой. Для проектов такого размера вероятность полного провала превышает 50 % (Jones 1998). Тот факт, что проект был завершен, сам по себе является крупным достижением. По производительности он всего на 15 % уступал проекту Windows NT, несмотря на то, что программное обеспечение шаттла в 10 раз превышало по размеру проект Windows NT.
Если вы не располагаете историческими данными о производительности вашей организации, можно использовать среднеотраслевые цифры для разных типов программ: внутренних бизнес-систем, критических систем, игр, драйверов устройств и т. д. При этом следует остерегаться 10-кратных различий в производительности разных организаций в пределах одной отрасли. Если вы располагаете историческими данными производительности в вашей организации, лучше используйте их для преобразования оценки размеров в оценку объема работ, вместо того, чтобы использовать среднеотраслевые данные.
19.2. Вычисление объема работ по размеру.
Занявшись вычислением оценки объема работ по оценке размера, мы начнем сталкиваться с некоторыми слабостями неформальных методов и будем вынуждены в большей степени задействовать научные методы.
Вычисление оценки объема работ посредством неформального сравнения с прошлыми проектами.
Если исторические данный проектов лежат в узком диапазоне размеров (скажем, верхняя граница отличается от нижней не более чем в 3 раза), вероятно, вы можете воспользоваться линейной моделью для вычисления оценки объема работ нового проекта по результатам похожих прошлых проектов. В табл. 19.2 представлен пример данных прошлых проектов, которые могут стать основой для такой оценки.
Таблица 19.2. Пример данных о производительности прошлых проектов, заложенных в основу для оценки объема работ
Проект
Размер.
(LOC)
Срок.
(календарные.
месяцы)
Объем работ.
(человеко-.
месяцы)
Производительность (LOC/ человеко-месяц)
Комментарии
Проект А
33 842
8/2
21
1612
Проект В
97 614
12,5
9
986
Проект С
7444
4,7
2
3722
Не используется — слишком мал для сравнения
Проект D
54 322
11,3
40
1358
Проект Е
340 343
24,0
533
639
Не используется — слишком велик для сравнения
Предположим, вы оцениваете эффективность новой бизнес-системы. По вашей оценке, размер нового продукта составит от 65 ООО до 100 ООО строк кода Java, с наиболее вероятным размером в 80 ООО строк. Проект С слишком мал, чтобы использоваться в целях сравнения, потому что его размер составляет менее 1/3 от нижней границы диапазона. Проект Е слишком велик для использования в целях сравнения, потому что он более чем в 3 раза превышает верхнюю границу. Таким образом, ваши исторические данные производительности лежат в диапазоне от 986 строк кода на человеко-месяц (проект В) до 1612 строк кода на человеко-месяц (проект А). Деление нижней границы диапазона размера на максимальную производительность дает нижнюю оценку в 40 человеко-месяцев, а деление на минимальную производительность — верхнюю оценку в 101 человеко-месяц. Таким образом, оценка объема работ представляет собой диапазон от 40 до 101 человеко-месяца.
Хорошее рабочее предположение заключается в том, что диапазон включает 68 % возможных результатов (то есть ±1 стандартное отклонение, если только у вас нет причин предполагать иное). По табл. 10.6 можно проверить другие вероятности, входящие в диапазон от 40 до 101 человеко-месяца.
Какой объем работ включается в эту оценку?.
Поскольку оценка создавалась по историческим данным, в нее включен тот объем работ, который задействован в исторических данных. Если в исторические данные включались работы только по разработке и тестированию и только для части проекта от завершения требований до тестирования системы, — именно они будут отражены в оценке. Если в исторические данные также вошли работы по постановке требований, управлению проектом и подготовке документации — значит, они тоже будут присутствовать в оценке.
В общем случае оценки, основанные на среднеотраслевых данных, включают всю техническую работу, но не работу по управлению и все операции разработки, кроме требований. На практике данные, включаемые в вычисления среднеотраслевых показателей, не всегда следуют этим предположениям; отчасти это объясняет такой разброс в среднеотраслевых данных.
19.3. Вычисление оценки объема работ научными методами.
Научные методы оценки дают несколько иные результаты, чем неформальные сравнения с прошлыми проектами. Если ввести те же предположения в Construx Estimate (то есть воспользоваться приведенными историческими данными для калибровки оценки), вы получите ожидаемый результат в 80 человеко-месяцев; он лежит в середине диапазона, полученного менее формальным методом. Construx Estimate дает оценку лучшего случая (достоверность 20 %) в 65 человеко-месяцев и оценку худшего случая (достоверность 80 %) в 94 человеко-месяца.
Если откалибровать Construx Estimate среднеотраслевыми данными вместо исторических, он выдает номинальную оценку в 84 человеко-месяца и гораздо более широкий диапазон 20-80 % от 47 до 216 человеко-месяцев. Это лишний раз показывает, как важно использовать исторические данные там, где это возможно.
СОВЕТ № 85 -.
Используйте оценочные программы, основанные на формальных методах оценки, для более.
точного вычисления оценки объема работ по имеющейся оценке размера.
19.4. Среднеотраслевые графики объема работ.
Если вы не располагаете собственными историческими данными, для грубой оценки объема работ можно воспользоваться графиком — примеры таких графиков приведены на рис. 19.1-19.9. Светлая линия на этих рисунках представляет общий объем технических работ проекта (включая разработку, контроль качества и тестирование) при среднеотраслевом уровне производительности. Верхняя черная линия представляет объем работ, на единицу стандартного отклонения превышающий средний. Я не стал приводить аналогичную линию на единицу стандартного отклонения ниже среднего. Если вы не располагаете собственными историческими данными и используете эти графики, это говорит о том, что разработка организована в лучшем случае на среднем уровне. В таких случаях лучше проявить умеренность в оценке и использовать среднеотраслевые или более низкие показатели производительности.
Строки кода.
Рис. 19.1. Средние объемы работ для проектов реального времени.
На графиках представлены проекты размером до 250 ООО строк кода, а максимальный объем работ по некоторым из них превышает 10 ООО человеко-месяцев. Для проектов такого размера следует понимать, что применение более мощных и точных методов оценки способно улучшить планирование и обеспечить экономию сотен тысяч долларов. Эксперт в области оценки Кейперс Джонс неоднократно отмечал, что применение ручных методов для оценки проектов свыше 1000 функциональных пунктов или 100 000 строк кода создает существенную ошибку, а отказ от применения оценочных программ в проектах свыше.
5000 функциональных пунктов или 500 000 строк кода должно рассматриваться как признак некомпетентности в управлении (Jones 1994, Jones 2005).
Рис. 19.2. Средние объемы работ для встроенных систем
Рис. 19.3. Средние объемы работ для телекоммуникационных проектов
Строки кода.
Рис. 19.4. Средние объемы работ для системных программ и драйверов
Рис. 19.6. Средние объемы работ для коммерческих программных проектов
Рис. 19.7. Средние объемы работ для публичных проектов интернет-систем
Строки кода.
Рис. 19.8. Средние объемы работ для интрасетевых проектов
СУроки кода.
Рис. 19.9. Средние объемы работ для бизнес-систем.
Математическая база таких графиков достаточно сложна, поэтому формулы в книге не приводятся. Объемы работ по графикам отсчитываются по логарифмической шкале. Первая строка над 100 означает 200, вторая — 300, первая строка над 1000 — 2000 и т. д.
Графики получаются похожими друг на друга, но внимательный анализ точек данных показывает, что в действительности они весьма различны. Например, сравните средние и стандартные отклонения над 100 000 строк кода, и вы увидите, что объемы работ в человеко-месяцах сильно различаются.
По среднеотраслевым графикам мы можем пересмотреть оценку примера, приведенного в разделе 19.2. Напомню, что это был проект бизнес-системы, а его размер составлял от 65 000 до 100 000 строк кода. Согласно рис. 19.9, средний объем работ для бизнес-системы в 65 000 строк составляет около 85 человеко-месяцев. Средний объем работы для системы в 100 000 строк составит около 170 человеко-месяцев. Если бы вместо среднего значения мы использовали верхнюю границу, оценка бы лежала в диапазоне от 300 до 600 человеко-месяцев.
СОВЕТ № 86 -
-.
Используйте среднеотраслевые графики для получения грубой оценки объема работ в широкой части конуса неопределенности. Помните, что в крупных проектах затраты, связанные с применением более мощных методов оценки, быстро окупаются.
19.5. Метод ISBSG.
Группа ISBSG (International Software Benchmarking Standard Group) разработала интересную и полезную методику вычисления объема работ, основанную на трех факторах: размере программного проекта в функциональных пунктах, типа среды разработки и максимальном размере группы (ISBSG 2005). Далее приводятся восемь формул для оценки объема работ для разных типов проектов. Формулы выдают оценку в человеко-месяцах в предположении, что один человеко-месяц составляет 132 часа плотной работы над проектом (то есть за исключением отпусков, выходных, обучения, собраний и т. д.). Первая формула общего назначения, пригодная для проектов любых типов, базируется на калибровочных данных примерно 600 проектов. Другие категории калибровались по данным от 63 до 363 проектов.
Тип: общий.
ФОРМУЛА № 9 -.
ЧеловекоМесяцы = 0,512 х ФункциональныеПункгы
х МаксимальныйРазмерГруппы
Тип проекта: проект для больших компьютеров (мейнфреймов).
ФОРМУЛА № 10 -.
ЧеловекоМесяцы = 0,685 х ФункциональныеПункгы
х МаксимальныйРазмерГруппы
Тип: проект среднего диапазона.
ФОРМУЛА № 11 -.
ЧеловекоМесяцы = 0,472 х ФункциональныеПункты
х МаксимальныйРазмерГруппы
Тип: настольная система.
ФОРМУЛА № 12 -.
ЧеловекоМесяцы = 0,157 х ФункциональныеПункты
х МаксимальныйРазмерГруппы
Тип: языки третьего поколения.
ФОРМУЛА № 13 -.
ЧеловекоМесяцы = 0,425 х ФункциональныеПункты
х МаксимальныйРазмерГруппы
Тип: языки четвертого поколения.
ФОРМУЛА № 14 -.
ЧеловекоМесяцы = 0,317 х ФункциональныеПункты
х МаксимальныйРазмерГруппы
Тип: доработка существующих проектов.
ФОРМУЛА № 15 -.
ЧеловекоМесяцы = 0,669 х ФункциональныеПункты
х МаксимальныйРазмерГруппы
Тип: новая разработка.
ФОРМУЛА № 16 -.
ЧеловекоМесяцы = 0,520 х ФункциональныеПункты
х МаксимальныйРазмерГруппы
Предположим, вы создаете оценку объема для настольного бизнес-приложения в 1450 функциональных пунктов на языке Java (та же система, которую мы уже оценивали в этой главе), а максимальный размер группы составляет 7 человек. Формула для настольных приложений подсказывает, что объем работы составит 56 человеко-месяцев:.
0,157 х 1,450
*
х 7
Формула для языков третьего поколения дает оценку в 58 человеко-месяцев:.
0,425 х 1,450
х 7
Интересная особенность метода ISBSG заключается в том, что формулы для объема работ зависят от максимального размера группы, а команды меньшего размера уменьшают общий объем. Изменение максимального размера группы в этом примере с 5 до 10 человек приводит к изменению оценки с 43 до 75 человеко-месяцев. С точки зрения оценки это создает неопределенность. С точки зрения управления проектом эти различия могут заставить вас использовать группу меньшего размера вместо большей (эта тема дополнительно рассматривается в подразделе «Сокращение срока и размер группы» раздела 20.6).
СОВЕТ № 87 -.
Используйте метод ISBSG для получения грубой оценки объема работ. Сравните его с другими методами и проанализируйте схождение или расхождение оценок.
19.6. Сравнение оценок объема работ.
Для проверки реалистичности этих оценок можно сравнить четыре разных метода оценки объема работ, представленные в этой главе:.
• неформальные сравнения с прошлыми проектами;.
• использование оценочных программ;.
• использование среднеотраслевых графиков;.
• метод ISBSG.
На рис. 19.10 показано, как выглядят диапазоны оценок, полученных этими методами.
Рис. 19.10. Диапазоны оценок, полученных методами, рассматриваемыми в этой главе. Относительные размеры точек и толщина линий представляют весовые коэффициенты, которые я присвоил каждому из представленных методов.
На графике показан диапазон оценок от 40 до 110 человеко-месяцев. Как в методе ISBSG, так и на среднеотраслевых графиках используются среднеотраслевые данные, поэтому я присвоил им меньший вес, чем методам, основанным на исторических данных. При неформальном сравнении с прошлыми проектами я присваивал наибольший вес самым похожим проектам (включая максимальное сходство размеров).
С учетом всех факторов в данном случае я бы представил оценку от 65 до 100 человеко-месяцев с ожидаемым результатом в 80 человеко-месяцев. Можно было бы предположить, что ожидаемый результат попадет в середину диапазона 65-100, но объем работ часто смещается к нижней границе диапазона из-за воздействия факторов, описанных в разделе 1.4.