Д. А. Градусов а. В. Шутов теоретические вопросы разработки программного обеспечения учебное пособие

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 

жүктеу/скачать 2,75 Mb.

Достарыңызбен бөлісу: