И. Соммервилл - Инженерия программного обеспечения (1133538), страница 122
Текст из файла (страница 122)
Онн также мопт включать макрокоманды, которые состоят из нескольких строк кода, С другой стороны. в одной строке может находиться нс один, а несколько операторов. Таким образом, соотношения между операторами и строками в листинге могут быть достаточно сложными. Одни моголы подсчста строк основываются только на выполгшсмь>х операторах; дру. гнс подсчитывают эьщолняемыс операторы и объявления данных; третьи ведут подсчет всех строк программы, независимо от их содсржииого. Были предложены опрсдслснныс стандарты подсчета строк в различных лзыкзх программирования [269], однако онн пс приобрели широкой ноп>лярности.
Поэтому практически невозможно сравнивать производительность различных компаний-разработчиков, если только все они пс используют один и тот жс метод подсчсзн строк кода. 23. Оценка стоимости программного продукта 473 Также может ввести в заблуждение и сравнение производительности программистов, пишущих на разных языках программирования.
Чем выразительнее язык, теи ниже производительность. Это "странное" утверждение объясняется тем, что при оценивании производительности создания ПО берется во внимание вся деятслыюсгь по разработке программного продукта, тогда как даппал система намерения основывается лишь на оценивании процесса программирования. Для примера возьмем систему, которая должна быть написана с помощью кода ассемблера (5000 строк) или с помощью языка высокого уровня (1500 строк).
Время выполнения различных этапов создания ПО показано в табл. 23.2. Специалист, программирующий на языке ассемблера, будет иметь пронзволительность 714 строк в месяц, а у программиста, работающего с языкои высокого уровня, производительность будет в два раза ниже — 300 строк в месяц. И это несмотря на то, что программирование на лзыке высокого уровня стоит дешевле и занимает меньше времени.
Таблица 23.2. Время выполнения этапов разработки программной системы Анализ Проектирование Кодирование Тестирование Документирование (недели) (недели) (недели) (недели) (недели) 10 Язык ас- 3 семблера Язык вы- 3 сокого уровня Размер (строки Затраченное время Производительность (строк в месяц) кода) (недели) Язык ас.
5000 семблера 300 20 Язык вы- 1500 сокого уровня Альтернативой показателю размера при оценивании производительности может служить функциональный показатель. В этом случае можно избежать тех "аномалий" в оценке производительности, которые встречаются при использовании показателя размера, так как функциональность нс зависит от языка программирования.
В статье [228) дастся краткое описание и сравнение способов оценки производительности, основанных на функ. ционзльных показателях. Одним из наиболее распространенных методов этого типа являетсл метод функциональных точек. Впервые он был прслложен в работе [б], а затем его усовершенствованный вариант был представлен в статье [7). Функциональные точки не зависят от приме. няеиого языка программирования, благодаря чему появилась возможность сравнения производительности разработки программных систем, написанных на различных языках программирования. Критерием оценки производительности выступает количество функциональных точек, созданных за человеко-месяц.
Ф>'нкциональная точка — это пе какаяцо отдельная характеристика программного продукта, а целая комбинация его свойств. Под. 474 Яасть 3Г1. Управление счет общего количества функциональных точек в программе проводится путем измерения или оцсни валия следующих свойств программы. ° Интенсивность использования ввода и вывода внешних данных.
° Взаимодействие системы с пользователем. ° Внешние интерфейсы. ° Файлы, использ>смыв системой. Сложность каждого из указанных критериев оценивается отдельно, в результате каждому критерию присваивается определенная весовая величина, которал может колебатьсл от 3 (лля простого вводэ данных) до 15 баллов за использование сложных внутренних файлов. Можно использовать весовые величины, предложенные в статье [7]. или величины, осноиишые на личном опыте. Пескоррсктпрованный подсчет ф>ззкциональных точек (ппаг]пмсб Гппсйоп-ро!пг соппг — 1)ГС) выполняется путем вычисленил суммы произведений оценки каждого фактора (количество элементов, составляющих данный фактор) на выбранную весовую величину этого фактора: 0гС = Е (количество элементов данного типа) х (весоввя величина). Первоначальный метод полсчста функциональных точек был в дальнейшем усовершенствован путем добавления тех факторов, значение которых зависит от общей сложно.
сти проекта. Злссь принимастсл во внимание степень распределенности обработки данных, лгногократпостг использования программных элементов, качество функционирования и т.п. Значение, получегшое при пескорсктироваппом подсчете функциональных точек, нужно умножить на факторы, определяющие сложность проекта, в результате будет получено итоговое значение. Вместе с тем в [330] отмечено, что оценка сложности несет в себе также и с>бъективный фактор, так как подсчет функциональных точек зависит от лица, проводящего оцени.
вапис. Люли имеют разные понятия о сложности. Так как подсчет функциональных точек зависит от мнения оценивающего, существует множество вариаций подсчета функциональных точек. Это приводит к разнылг взгллдалг на значимость функциональных точек [122], Однако многие заявляют, что, несмотря на вес недостатки, на практике этот метод себя оправдывает [! 96].
Лльтсрнатиной функциональным точкам являются объектные точки [19], особенно если при разработке ПО используется язык программирования четвертого поколения. Метод объелтиьгх точек прилгенлстся в модели оцспиэанил СОСОМО 2, которая рассматрнваетсл далее в главе. (Объектныс точки — это отнюдь не классы объектов, которые производятся в результате применения объектно.ориентировашюго подхода в работе над програмлюй', что можно было бы прслположить, исходя из названия.) Количество объектных точек в программе можно получить путем предварителыюго подсчета ряда элементов.
1. Количество изображений па дисплее. Простые изображения принимаются за 1 объектную точку, изображения умеренной сложности принимаются за 2 точки, а очень сложные изображения принято считать за 3 точки. 2. Количество представленных отчетов. Для простых отчетов назначаются 2 объектпгяс точки, умеренно сложным отчетам назначаются 5 точек. Написание сложных отчетов оценивается в 8 точек. 3. Количество мол>лей, которые написаны па языюзх третьего поколенпл и разрабатаны в Лоиолиснг!с к коду. написанному на языке программнровашш четвертого поколения. Казмый молул ь иа л зыке третьего поколения считается зз 1О объектных точек.
23. Оценка стоимости программного продукта 475 Преимущество данного метода состоит в том, что объектные точки легко оценить исходя из высокоуровневой спецификации программного продукта, поскольку опи связаны с конкретными объектами — изображениями, отчетами и модулями иа языках программирования третьего поколения. Количество функциональных и объектных точек можно оценить уже на ранней стадии выполнения проекта. Оценку этих параметров можно начинать сразу после разработки внешних вэаимосвлзей системы.
Именно иа этой стадии очень сложно провести точную оценку размера программы, беря за основу только строки кода. Более того, язык програль мирования на этом этапе может быть еще не выбран. Вместе с тем оценка па рацией стадии особенно необходима, если используются модели алгоритмического оцсниэания себестоимости, которые рассматриваются далее. Подсчет функциональных точек можно проводить параллельно с методом подсчета количества строк кода. Количество функциональных точек при этом используетса для оценивания окончательной величины кода На основе анализа выполнения предыдуших программных проектов для определенных языков программирования можно оценить среднее количество строк кода [аиегайе пцтЬег оГ йпез оГ себе — АЧС], необходимых для реализации одной функциональной точки.
В этом случае получим оценку рэзиер кода нового проекта, рассчитанную следующим образом: размер кода = АЧС х количество Функциональных точек. Значение АЧС варьируетсл от 200 до 300 строк кода на одну функциональную точку в языке ассемблера и от 2 до 40 строк кода для языков программирования четвертого поколения. Производительность отдельных программистов, работающих в организации-разработчике, зависит от множества фисгоров, влияющих иа их работу. Некоторые иэ наиболее значимых факторов представлены в табл.
23.3. Однако различия в индивидуальных способностях про. граммнсгов намного важнее всех этих факторов. В исследовании ранних этапов программнро. ванна [305] отмечено, что производительность некоторых программистов в 10 раз выше, чем у других. Это наблюдение подтверждается и моим личным опытом. Большие команды, члены которых имеют необходимый набор личностных качеств и способностей, будуг иметь "среднюю" производнтельносгь. Вместе с тем в командах небольшого размера общая пронзво. дительносгь во многои зависит от индивидуальных умений и навыков каждого члена команды, Должен отметить, что не сущесгвует какой-либо величины, определяющей "среднюю" производительность программиста, которую можно было бы применять в разных оргапнзациях и при создании разных програмлгных продуктов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
