Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

424 Глава 8

• потребители FSM смогут оценить особенности функциональных требова-

ний к собственным ПС и классифицировать их по принадлежности к одной или

больше функциональным областям;

• потребители смогут выбрать метод FSM, зарекомендовавший себя как

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

оценивается размер;

• разработчики метода FSM будут способны четко определить функцио-

нальные области, для которых их метод может использоваться эффективно;

• оценщики методов и эксперты по методам FSM будут обеспечены четки-

ми руководствами для определения функциональных областей, применительно к

которым нужно определять эффективность методов;

• разработчики ПС смогут использовать эталонные требования в качестве

ориентира для проверки полноты набора исходных функциональных и нефункцио-

нальных требований пользователя разрабатываемых ПС определенного класса.

Часть 6 стандарта – дает краткий обзор смежных стандартов, касающихся

определения функционального размера по методологии FSM, и устанавливает

взаимосвязь между:

- серией стандартов ISO/IEC 14143, предоставляющих определения и понятия

в области измерения функционального размера и правила обеспечения совмести-

мости и проверки методов, разработанных в рамках методологии FSM, и

- собственно стандартизованными FSM-методами, представленными отдель-

ными стандартами - ISO/IEC 19761, ISO/IEC 20926, ISO/IEC 20968 и ISO/IEC

24570.

Эта часть определяет также процесс, предназначенный для оказания помощи

потребителям в выборе Метода FSM, отвечающего их требованиям, и, кроме того,

обеспечивает руководство по использованию оценок функционального размера.

Предполагается, что часть 6 стандарта будет востребована как потребителями

оценок функционального размера, так и разработчиками методов FSM.

Стандарт ISO/IEC 14143 продолжает эволюционировать. О его текущем со-

стоянии (а также состоянии других проектов стандартов) можно узнать на сайте

подкомитета SC7: http://www.sqi.gu.edu.au/sc7/mirror/index_e_frameset.html.

8.4.2. Стандартизованные методы измерения объема функциональности

Наряду с разработкой стандарта ISO/IEC 14143 рабочая группа WG12 прове-

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

ного размера программного обеспечения требованиям ISO/IEC 14143 и стандарти-

зации этих методов.

Нужно отметить, что стандартизованы методы расчета только функциональ-

ного размера без учета сложности реализации нефункциональных требований (т.е.

стандартизованы методы получения так называемых не скорректированных (unad-

justed) оценок).

Первым методом, который признан полностью соответствующим требовани-

ям стандарта ISO/IEC 14143, стал метод COSMIC Full Function Points (версия 2.2),

представленный в разделе 8.2. Он оформлен как следующий стандарт

• ISO/IEC 19761:2003 “COSMIC-FFP - A Functional Size Measurement

Method”.

Глава 8 425

За ним последовали стандарты методов IFPUG FPA (версия 4.1), Mark II FPA

(версия 1.3.1) и NESMA FPA (версия 2.1).

• ISO/IEC 20926:2003 “IFPUG 4.1 Unadjusted functional size measurement

method - Counting practices manual”

• ISO/IEC 20968:2002 “Mk II FPA - Counting Practices Manual”.

• ISO/IEC 24570:2005 “Software Engineering - NESMA FSM- method version

2.1 - Definitions and counting guidelines for the application of FPA”.

8.4.3. Использование эталонных данных для определения размера

С применение методов FSM связаны три проблемы: квалификация специали-

стов, выполняющих оценки размера (или зрелость организации в целом), использо-

вание данных других фирм-разработчиков ПО, если отсутствуют собственные дан-

ные об измерении размера ПС в УЕФ, и конвертирование в SLOC полученных оце-

нок в УЕФ для их применения в моделях оценивания затрат, надежности и др.

Решить первую проблему достаточно сложно, так как, в отличие от многих

других стран, в Украине пока не создана соответствующая учебная база (нет орга-

низаций и сообществ пользователей (наподобие национальных FPUG), имеющих

официальные права готовить и аттестовать специалистов по методам FSM). Хотя

освоить FSM-методы вполне можно самостоятельно, используя доступные в Ин-

тернет материалы, в частности полные руководства по IFPUG 4.1 и 4.2, COSMIC

2.2 и MK II FPA 1.3.1, ссылки на которые были даны в соответствующих разделах

данной главы.

Для решения второй проблемы можно воспользоваться обширными сведе-

ниями об опыте определения размера, размещенными в Интернет известными ор-

ганизациями, центрами и лабораториями. Однако это отрывочные сведения, поль-

зоваться которыми можно только в том случае, если есть уверенность в идентично-

сти характеристик проектов, по которым они получены, и конкретных отечест-

венных проектов, для которых они должны применяться. Данные о характеристи-

ках проектов обычно размещаются (наряду с полученными оценками) в базах дан-

ных фирм, которые их публикую. Доступ к этим БД строго ограничен. В любом

случае все используемые модели оценивания нуждаются в калибровке по истори-

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

Нужно заметить, что существует международная группа по стандартизации

эталонных данных о разработке ПО ISBSG (от International Software Benchmarking

Standards Group), которой создан репозиторий проектных данных и регулярно вы-

полняется их специальных анализ (http://www.isbsg.org/isbsg.nsf/weben/Special

%20Analyses). Однако отчеты предоставляются только по предоплате.

Третья проблема касается коэффициента расширения кода для различных

языков программирования, то есть соотношения оценок в УЕФ и SLOC. Со време-

ни появления FPA было опубликовано немало таблиц пересчета оценок, составлен-

ных известными специалистами в данной проблематике, например, Дж. Кейперсом

(1996 год, адрес http://www.theadvisors.com/langcomparison.htm). Даже в этой главе

представлено две таких таблицы (таблица 8.7 и таблица 8.41)

. Таблицы пересчета

Для уточнения адресов используйте строку запроса информации на поисковом сер-

вере в Интернет: “Function point” “Languages table”

426 Глава 8

составляются на основе анализа данных большого числа завершенных проектов

(как правило, более 500). Однако, данные в них все ж существенно отличаются.

С недавних пор регулярное опубликование соотношений FP/SLOC начал

Quality Software Management, Inc.. Так, в апреле 2005 года QSM представил третью

версию подготовленной им таблицы пересчета [33].

Таблица составлена по данным 2597 завершенных проектов, сведения о кото-

рых хранятся в базе данных QSM. Чтобы обеспечить высокое качество оценок FP и

SLOC, для анализа были выбраны только одно- языковые проекты (в которых не

использовались смеси языков программирования). Наряду с усредненными оценка-

ми коэффициентов расширения кода QSM опубликовал диапазоны значений, чтобы

можно было увидеть разброс оценок по проектам, а также медиану, чтобы точнее

отразить основную тенденцию в изменении оценок.

Кроме собственных данных QSM в таблице представлены «свежие» данные

David Consulting, Inc. (таблица 8.43).

Таблица 8.43. Коэффициенты расширения кода. QSM, версия 3.0

SLOC/FP (данные QSM) Язык программи-

рования

Среднее Медиана От До

SLOC/FP (данные

David Consulting)

Access

38 15 47 -

Ada

154

- 104 205 -

APS

83 20 184 -

APP

62 32 127 -

Assembler

172

157 86 320 575-базовый, 400 макро

148

104 9 704 225

C++

53 29 178 80

59 51 66 -

Clipper

39 27 70 60

COBOL

77 8 400 175

Dbase III

- - - 60

Dbase IV

- - - 55

Easytrive+

34 25 41 -

Excel

46 31 63 -

Focus

42 32 56 60

FORTRAN

- - - 210

FoxPro

35 25 35 -

HTML

42 35 53 -

Ideal

52 34 203 -

IEF/Cool, Gen

31 10 180 -

Informix

31 24 57 -

J2EE

50 50 100 -

Java

59 14 97 80

JavaScript

54 44 65 50

JCL

48 21 115 400

JSP

- - - -

Lotus Notes

22 15 25 -

Mantis

27 22 250 -

Mapper

118

81 16 245 -

Natural

52 22 141 100

Oracle

29 4 122 60

Глава 8 427

SLOC/FP (данные QSM) Язык программи-

рования

Среднее Медиана От До

SLOC/FP (данные

David Consulting)

Oracle Developer 2K

30 21 100 -

Oracle FORMS

30 23 100 -

Pacbase

48 26 60 -

PeopleSoft

32 30 40 -

Perl

- - - 50

PL/1

58 22 92 126

PL/SQL

31 14 110 -

PowerBuilder

24 7 105 -

REXX

- - - -

PRG II/III

49 24 155 120

SabreTalk

89 54 99 -

SAS

41 33 49 50

Siebel Tools

13 5 20 -

Slogan

82 66 100 -

SmallTalk

32 17 55 -

SQL

35 15 143 -

VBScript

34 27 50 50

Visual Basic

42 14 276 -

VPF

95 92 101 -

Web Scripts

15 9 114 -

Литература к главе 8

1. Park R. Software Size Measurement: A Framework for Counting Source Statements // Tech.

Report CMU/SEI-92-TR-020. – Software Eng. Inst., Pittsburgh, 1992. – 242 p.

2. Santillo L. Early FP Estimation and the Analytic Hierarchy Process // ESCOM-SCOPE 2000,

Munich, Germany, April 18-20. – 2000. – 9 p.

3. Jones C., A short history of Function Points and Feature Points // Cambridge, Massachusetts:

Software Productivity Research, Inc.- 1988.- 45 p.

4. Symons C., Software Sizing and Estimating: Mk II FPA // Chichester: John Willey &Sons

Ltd.- 1991.-57 p.

5. Whitmire S., An Introduction to 3D Function Points // Sottware Development - 1995.- V.3,

N.4.- P. 43-53.

6. Whitmire S., Applying function points to object-oriented software models // in Software Engi-

neering productivity handbook, ed. J.Keyes.- McGraw-Hill.-1992.- P. 229-244.

7. Karner G. Resource estimation for objectory projects // Objectory Systems.-1993.

8. Use case points // www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/use_case_po-ints.pdf

9. Fetcke T., Abran A., Nguyen T-H. Mapping the OO-Jacobson approach into FPA // in Proc. of

TOOLS-23’97,August 1997 - http://www.fetcke.de/papers/Fetcke1997.pdf

10. Kammelar J. A Sizing Approach for OO-environments - http://www.iro.umontreal.ca/

~sahraouh/qaoose/papers/Kammelar.pdf

11. Teologlou G. Measuring object oriented software with predictive object points // proceedings

of ESCOM SCOPE 99 Conference, Herstmonceux, England, Shaker Publishing.- 1999.

12. Abrahão S, Poels G., Pastor O. A Functional Size Measurement Method for Object-Oriented

Conceptual Schemas: Design and Evaluation Issues // www.feb.ugent.be/Fac/Research/WP/

Papers/wp_04_233.pdf

428 Глава 8

13. Banker D. et al., Automation Output Size and Reuse Metrics in a Repository-Based CASE

Environment // IEEE Trans. Soft. Eng. - 1994.- SE - 20, N.3.- P. 169-186.

14. Santillo L.,Meli R. Early Function Points: some practical experiences of use // ESCOM-

ENCRESS 98, Project Control for 2000 and Beyond, Rome, Italy, May 27-29. –1998. – 13 p.

15. Full Function Points: Counting Practices Manual / St-Pierre D., Maya M., Abran A., Deshar-

nais J.-M., Bourque P.// Technical Report 1997-04, Quebec, Montreal, Canada.-1997.

16. The Common Software Measurement International Consortium (COSMIC) -

http://www.cosmicon.com

17. Measurement Manual, The COSMIC Implementation Guide for ISO/IEC 19761:2003, Ver-

sion 2.2, January 2003. COSMIC Measurement Practices Committee. -

http://www.gelog.etsmtl.ca/cosmic-ffp/private/CFFP_MM_v2.2e.pdf

18. Meli R., Abran A. et al. On the applicability of COSMIC-FFP for measuring software

throughout its life cycle // ESCOM-SCOPE 2000, April 18-20. – 2000. – 10 p.

19. Applying COSMIC FFP to Business Application Software, version 1.0 – 2005. -

http://www.gelog.etsmtl.ca/cosmic-ffp/updates/b.pdf

20. Pastor O. Functional size measurement for Web Application - http://www.ifi.uni-klu.ac.at/

IWAS/HM/Staff/Heinrich.Mayr/Teaching/FSM.pdf

21. Reifer D.J. Web development: Estimating Quick-to-Market Software // IEEE Software. –

nov/dec. – 2000. – P. 57-64.

22. Cleary D. Web-Based Development and Functional Size Measurement // in Proc. of IFPUG

Annual Conf., San Diego, USA, 2000 – www.charismatek.com.au/_public1/pdf/ webfsm.pdf

23. Abrahão S. On the Functional Size Measurement of Object-Oriented Conceptual Schemas:

Design and Evaluation Issues // www.dsic.upv.es/~sabrahao/PhDThesis_SilviaAbrahao.pdf

24. Reifer D.J. Estimating Web Development Costs: There Are Differences

//www.stsc.hill.af.mil/Crosstalk/2002/06/reifer.html

25. Abrahão, S., Pastor, O. Measuring the Functional Size of Web Applications // International

Journal of Web Engineering and Technology.-2003.-V. 1, N. 1, P. 5-16.

26. Pastor O., Gomez J., Insfran E., Pelechano V. The OO-Method Approach for Information

Systems Modeling: From Object-Oriented Conceptual Modeling to Automated Programming

// Information Systems.-2001.-V. 26.-N.7.- P. 507–534.

27. ISO/IEC 14143-1:1998.

Information technology -- Software measurement -- Functional size

measurement -- Part 1: Definition of concepts.

28. ISO/IEC 14143-2:2002. Information technology -- Software measurement -- Functional size

measurement -- Part 2: Conformity evaluation of software size measurement methods to

ISO/IEC 14143-1:1998.

29. ISO/IEC TR 14143-3:2003. Information technology -- Software measurement -- Functional

size measurement -- Part 3: Verification of functional size measurement methods.

30. ISO/IEC TR 14143-4:2002. Information technology -- Software measurement -- Functional

size measurement -- Part 4: Reference model.

31. ISO/IEC TR 14143-5:2004. Information technology -- Software measurement -- Functional

size measurement -- Part 5: Determination of functional domains for use with functional size

measurement.

32. ISO/IEC 14143-6:2006. Information technology -- Software measurement -- Functional size

measurement -- Part 6: Guide for use of ISO/IEC 14143 series and related International Stan-

dards.

33. QSM function point programming languages table. Version 3.0, april 2005 -

http://www.qsm.com/FPGearing.html.

429

Глава 9. ОЦЕНКА ЗАТРАТ НА РАЗРАБОТКУ

ПРОГРАММНЫХ СИСТЕМ

9.1. Обзор основных методов оценки затрат

9.1.1. Классификация методов и моделей оценки затрат

Хотя существует немало моделей и методов, предназначенных для прогнози-

рования трудоемкости, продолжительности и стоимости создания ПС, разработчи-

ки программных систем все еще часто руководствуются одним из двух законов:

- законом Паркинсона, который гласит: «любая работа стремится захва-

тить все доступные ресурсы» (сколько бы много их не было), или

- законом конкурентных цен, согласно которому «если не воспользоваться

предложением выполнить работу в заданные сроки и по заданной цене - этим пред-

ложением воспользуются другие» (независимо от того, приемлемы ли условия).

Основные категории методов оценивания затрат были названы Б. Бо-

эмом еще в 1981 году [1] и кратко охарактеризованы ниже.

Методы экспертных оценок. В этих методах решение о факторах, влияющих

на затраты ПС, и степени этого влияния принимается экспертом или группой экс-

пертов. Примерами методов служат метод Delphi и его расширение (Wideband

Delphi). Их основное преимущество - учет опыта предыдущих разработок, а недос-

таток - большая зависимость от компетентности экспертов. Эти методы применя-

ются для

экспертных оценок в любых областях, связанных с неопределенностями,

в частности, для оценки размера и трудозатрат в тех случаях, когда отсутствуют

исторические данные о соответствующих измерениях в прошлых проектах.

Метод оценивания «сверху-вниз». Этот метод основывается на учете харак-

теристик проекта ПС в целом и применяется на ранних стадиях планирования ПС.

Он прост в использовании и требует минимум знания деталей проекта. Его пре-

имущества - тщательное оценивание общесистемных работ, связанных с интегра-

цией, документированием, контрольными функциями, управлением конфигурацией

и др. Однако метод страдает неточностью и приводит к недооценке компонентов

на нижних уровнях проекта, а, кроме того, не содержит механизмов для настройки

параметров оценок в ходе ЖЦ ПС.

Метод оценивания «снизу-вверх». Этот метод предусматривает идентифика-

цию и оценивание каждого отдельного программного компонента (или отдельной

задачи) и последующее комбинирование результатов для получения оценок всего

проекта ПС. Преимущества метода - возможность тщательного оценивания, недос-

татки - недооценка общесистемных работ, большая трудоемкость и сложность

применения на ранних стадиях ЖЦ из-за отсутствия данных.

Метод аналогий. Представляет собой сопоставление характеристик предло-

женного к разработке проекта ПС и завершенных программных проектов-аналогов.

Оценка по аналогам возможна как на уровне всего проекта ПС, так и на уровне от-

дельных компонентов. Основные достоинства метода - использование реальных

данных проектов и накопленного опыта разработки и оценивания. Сложность при-

менения обусловлена трудностью выявления и оценки отличий нового проекта от

430 Глава 9

завершенных проектов. Точность метода зависит от достоверности исторических

данных об аналогах.

Методы параметрических уравнений - наиболее распространенные методы

оценки затрат на ПС, основанные на использовании математических моделей.

Параметрами этих моделей являются, с одной стороны, исторические данные

о классе проектов, к которым принадлежит оцениваемый проект, а с другой - рас-

считанные значения объема ПС и числа выполняемых им функций, а также такие

факторы стоимости, как язык программирования, методология проектирования,

опыт разработчиков и другие.

Достоинства методов этой категории - возможность повторения оценок (вы-

полнение расчетов по моделям), простота модификации входных данных и на-

стройки формул с учетом условий разработки конкретных проектов (калибровка

моделей). Однако результаты оценок по существующим моделям проблематичны

при оценке проектов, разрабатываемых по новым технологиям и в новых условиях.

В этом случае оценке обязательно должна предшествовать калибровка моделей.

По классификации Б.Боэма [1] математические модели подразделяются

на:

• линейные - модели, в основе которых уравнение прямой, построенной по

входным данным модели:

хахахааРасходы ⋅++⋅+⋅+= ...

22110

где x

...x

- переменные факторов стоимости, а a

…a

- последовательность коэф-

фициентов, полученных по данным о завершенных проектах;

• мультипликативные - модели, в которых оценки стоимости имеют вид:

хх

ааааРасходы ⋅⋅⋅⋅= ...

210

где x

...x

- переменные стоимостных факторов, а a

…a

- последовательность ко-

эффициентов, полученных по данным о завершенных проектах;

• аналитические - модели, имеющие вид некоторых функций (f), не яв-

ляющихся ни линейными, ни мультипликативными:

),...,,(

21 n

хххfРасходы =

Особенностью аналитических моделей является то, что они содержат не-

большое количество переменных и, следовательно, не могут учесть все разнообра-

зие факторов, влияющих на стоимость ПС;

• табличные - модели, представляющие зависимость между факторами

стоимости и расходами в виде матриц;

• композиционные - модели, использующие комбинацию всех или некото-

рых из упомянутых методов.

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

с их помощью можно охватить широкий спектр ситуаций при разработке ПС. Кро-

ме того, эти модели позволяют определить четкие алгоритмы действий по оцени-

ванию ПС, и, таким образом, обеспечить инструментальную поддержку определе-

ния входных данных и расчетов расходов на разработку ПС.

Помимо перечисленных выше методов и моделей, классифицированных

Б.Боэмом, для оценки затрат применяются современные методы:

Глава 9 431

- нейронные сети,

- байесовские сети,

- методы имитационного моделирования и др.[2].

В этой главе кратко представлены наиболее известные методы и модели оце-

нивания затрат на разработку ПС, в частности, семейство моделей COCOMO (раз-

дел 9.2), а также указаны ссылки на доступные источники для получения дополни-

тельной информации об этих и других методах и моделях. Поскольку многие мето-

ды реализованы в инструментах оценивания затрат (как коммерческих, так и бес-

платных), в разделе 9.3 приведен перечень основных инструментов и их изготови-

телей.

9.1.2. Математическая модель SLIM

Математическая модель SLIM (

Software Life Cycle Model) была разрабо-

тана

Л. Патнамом в 1978 году [3]. В этой модели предполагается, что трудозатра-

ты на разработку ПО распределяются по закону, описываемому кривой лорда Рэлея

(Lord Rayleigh).

Количество персонала, занятого в проекте по месяцам, представляется про-

изводной от функции общих затрат на проект и выражается уравнением вида:

)exp(2

tataK

⋅−⋅⋅⋅⋅=

где

dy t

( )

интенсивность использования персонала (количество занятого персонала

по месяцам), К – общие трудозатраты на проект от его начала до завершения

(включая сопровождение), а – параметр (константа), определяющий наклон кри-

вой, t – общая продолжительность ЖЦ проекта.

На рисунке 9.1 изображен график кривой Рэлея, на котором область под кри-

вой представляет функцию общих трудозатрат и, соответственно, может быть вы-

ражена в виде:

y t

dy t

K e

( )

( )= = × −

∫

−

Очевидно, что при t → ∞, y(t)=K.

1 3 5 7 9 11 13 15 17 19 21

Время (t)

количество персонала (y)

Рис. 9.1. Форма кривой Рэлея (К=1, а=0.02)

432 Глава 9

Поскольку ЖЦ проекта обычно делится на фазы, каждая из которых может

моделироваться кривой Рэлея, общие результаты будут представлять сумму част-

ных кривых (рисунок 9.2).

Рис. 9.2. Семейство кривых Рэлея по стадиям проекта

Точка на оси времени, в которой

dy t

( )

максимальна

соответствует

⋅

где t

– время, истекшее от начала проекта.

В модели SLIM производительность персонала собственно разработки Р

определяется из уравнения

где S – размер ПС (в SLOC), E – трудозатраты на разработку.

По эмпирическим данным реальных проектов в модели определено, что Е

примерно равно 40% от К, т.е.

KE 4.0

Степень загрузки персонала ассоциируется со сложностью (трудностью)

проекта D, определяемой по формуле:

)(

D =

Связь между производительностью персонала Р и сложностью проекта D

описывается уравнением:

)3/2(−

= DaP

После несложных преобразований легко получить уравнение условного

«объема» (размера проекта):

3/43/1

)()(4.0

tKaS =

а из этого уравнения - общие трудозатраты на жизненный цикл ПС:

Глава 9 433

)(

K =

где С = 0.4α – константа, называемая индексом производительности, которая ис-

пользуется для учета стоимостных атрибутов - таких как методы разработки и

управления проектом, инструменты разработки, квалификация и опыт персонала,

сложность проекта и др. Ее значения могут варьироваться от 610 до 57314.

Тогда трудозатраты на разработку: E = 0.4К или:

)(

4.0

E ⋅













Как видно из этого уравнения, трудозатраты увеличиваются в кубической за-

висимости от размера S при постоянном времени. При фиксированном размере,

трудозатраты изменяются в обратной зависимости от времени.

Оптимальное время разработки (выпуска ПС) определяется следующим

уравнением:

3/1

4.2 Et

Описанная модель реализована в наборе инструментов управления проектом

под общим названием SLIM (Software Lifecycle Management), в состав которого

входят [4]:

– Slim-Estimate – планирование и оценивание проекта;

– SLIM-Control - отслеживание проекта;

– SLIM-Metrics - репозиторий для хранения метрик и исторических (эта-

лонных) данных о проектах.

9.1.3. Математическая модель SEER-SEM

Математическая модель SEER-SEM (System Evaluation and Estimation of Re-

sources – Software Estimating Model) была разработана на основе моделей Jensen и

COCOMO в начале 90-х годов [5].

Подобно другим моделям, основными исходными данными для нее служат

размер оцениваемого проекта (в строках кода или единицах функционального раз-

мера). Оценки размера переводятся во внутреннюю унифицированную меру разме-

ра S

, называемую «эффективным размером», которая вычисляется по следующей

общей формуле:

= NewSize + ExistingSize·(0.4*Redesign +0.25·Reimpl + 0.35·Retest)

где NewSize – размер нового исходного кода, ExistingSize – размер повторно ис-

пользуемого кода, Redesign, Reimpl, Retest – размеры изменяемого кода в связи с

повторным проектированием, повторным кодированием и повторным тестировани-

ем, соответственно.

Как видно из этой формулы, S

линейно растет с ростом нового кода и объе-

ма переделок существующего кода. Оценки размера в этом случае указываются в

строках исходного кода (SLOC).

Модель позволяет использовать (взамен SLOC) меру размера в условных

единицах функционального размера ПС. Предполагается, что размер определяется

по методологии FPA и учитываются только функциональные требования (т.е. про-