Размер проекта
Важнейшим фактором влияния в оценке программного
обеспечения является размер разрабатываемой программы, потому
что он подвержен наибольшему разнообразию по сравнению со всеми
остальными факторами.
На рис. 5.7 показана зависимость роста объема работ в среднем
проекте бизнес-системы при увеличении размера проекта с 25 000 до
1 000 000 строк кода. Размер проекта на рисунке выражается в
строках программного кода (LOC), но динамика остается неизменной
независимо от того, в чем измеряется размер – в функциональных
пунктах, длине списка требований, количестве веб-страниц или
любых других показателях, выражающих те же диапазоны.
109
1000
5000
4000
2000
3000
6000
0
Объем работы
(человеко-месяцы)
50
0
00
50
0
00
0
45
0
00
0
40
0
00
0
35
0
00
0
30
0
00
0
25
0
00
0
20
0
00
0
15
0
00
0
10
0
00
0
90
0
00
0
85
0
00
0
80
0
00
0
75
0
00
0
70
0
00
0
65
0
00
0
60
0
00
0
55
0
00
0
1
00
0
00
0
95
0
00
0
Размер проекта
(строк кода)
Линейный рост
Типичный рост
Worse Case
Рис. 5.7 - Динамика роста объема проекта
Как видно из диаграммы, система, состоящая из 1 000 000 строк
кода потребует гораздо большего объема работы, чем система,
состоящая из 100 000 строк. Казалось бы, на построение системы, в 10
раз большей другой, потребуется в 10 раз больше усилий. Однако
объем работы для системы в 1 000 000 строк превышает 10-кратный
объем работы для системы в 100 000 строк. Основная проблема
заключается в том, что крупные проекты требуют координации
между большим количеством групп, которым приходится общаться
между собой. С ростом размера проекта число коммуникационных
путей между людьми растет в квадратичной зависимости от
количества
участников
проекта
(
)
1
(
n
n
).
Следствием
экспоненциального роста количества коммуникационных каналов
является экспоненциальный рост трудоемкости с увеличением
размера проекта. Данное явление называется издержками масштаба
(diseconomy of scale). C увеличением масштаба системы стоимость
каждой единицы повышается.
Также на рис. 5.7 продемонстрированы типичные издержки
масштаба по сравнению с увеличением объема работы,
110
ассоциируемого с линейным ростом. Кроме номинальных издержек
масштаба, на графике также показаны издержки в наихудшем случае.
Из графика видно, что объем работы при худших издержках растет
гораздо быстрее, чем при номинальных, а при больших размерах
проекта эффект выражен гораздо ярче.
В издержках масштаба имеются как положительные, так и
отрицательные стороны. Начнем с отрицательных: при существенных
различиях в размере проектов новый проект нельзя оценивать
применением простого масштабного коэффициента к объему работ,
известному по предыдущим проектам. Скажем, если объем работ для
предыдущего проекта в 100 000 строк кода составил 170 человеко-
месяцев, можно предположить, что производительность составляет
100000/170, то есть 588 строк кода на человеко-месяц. Данное
предположение может быть разумным для другого проекта примерно
такого же размера, но если новый проект в 10 раз больше, такая
оценка производительности может оказаться смещенной на величину
от 30 до 200%.
Издержки масштаба можно смело игнорировать, когда новый
проект по размеру мало отличается от прошлых проектов, поскольку
при его оценке вполне можно использовать простой масштабный
коэффициент – например, количество строк кода на человеко-месяц.
И, как правило, большинство проектов, которыми занимается
организация, имеют сходные размеры.
В описании графика в качестве единицы измерения
использованы строки кода. Вообще существуют различные
показатели размера программных проектов, в том числе:
-
функции;
-
требования;
-
сценарии использования;
-
функциональные пункты;
-
web-страницы;
111
-
компоненты GUI (окна, диалоговые окна, отчеты и т.д.);
-
таблицы баз данных;
-
определения интерфейсов;
-
классы;
-
строки программного кода.
Но стандартными метриками оценки размера, используемыми в
моделях, являются строки программного кода и функциональные
пункты. И те, и другие обладают разными достоинствами и
недостатками и, как правило, создание оценок по разным метрикам и
проверка их схождения или расхождения обеспечивает самые точные
результаты.
На практике для оценки чаще всего используются именно
строки программного кода (LOC). Такая оценка имеет как
положительные, так и отрицательные стороны. С одной стороны, есть
ряд преимуществ:
1.
данные по количеству строк кода в прошлых проектах легко
собираются при помощи служебных программ;
2.
во многих организациях уже наработан большой объем
исторических данных, выраженных в строках кода;
3.
объем работы на строку кода остается более или менее
постоянным для разных языков программирования;
4.
измерения
в
строках
кода
позволяет
выполнить
межпроектные сравнения и оценивать будущие проекты по данным
прошлых;
5.
в большинстве коммерческих оценочных программ оценки
объема работ и сроков в конечном счете основываются на строках
кода.
С другой стороны, строки кода также создают определенные
трудности при оценке размера:
1.
упрощенные модели вида «количество строк кода на
человеко-месяц» подвержены ошибкам из-за издержек масштаба и
112
заметных различий в скорости кодирования для разных типов
программного обеспечения;
2.
строки кода не могут использоваться в качестве основы для
оценки задач, порученных отдельным программистам, из-за
огромных различий в производительности;
3.
если проект требует более сложного кода по сравнению с
проектом, использовавшимся для калибровки предположений о
производительности, это может нарушить точность оценки;
4.
применение метрики LOC при оценке работы по постановке
требований, проектированию и других действий, предшествующих
созданию кода, выглядит противоестественно;
5.
строки кода трудно оценивать напрямую и их обычно
приходится оценивать опосредованно;
6.
необходимо заранее тщательно определить, что именно
следует считать строкой кода.
Многие эксперты возражают против использования строк кода в
качестве метрики размера из-за проблем, возникающих при попытке
анализа производительности в проектах с разными типами,
размерами, языками программирования и предлагают использовать в
качестве альтернативы LOC функциональные пункты. Это
синтетическая метрика размера программы, которая может
применяться для оценки размера проекта на ранних стадиях.
Функциональные пункты проще вычислять по спецификации
требований, чем строки кода; кроме того, они формируют основу для
вычисления размера в строках кода. Существует много разных
методов для вычисления функциональных пунктов. Стандарт
подсчета функциональных пунктов поддерживается группой
International Function Point Users Group (IFPUG).
Однако, проблемы, аналогичные проблемам использования
строк кода, встречаются и при использовании других метрик
размеров, включая функциональные пункты.
113
Достарыңызбен бөлісу: |