cse 7315 - sw project management / module 14 - size estimating notes and reuse copyright 1995-2004,...

CSE 7315 - SW Project Management / Module 14 - Size Estimating Notes and ReuseCopyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Slide 1

CSE7315M14

January 11, 2004

SMU CSE 7315 / NTU SE 584-NPlanning and Managing a

Software Project

Module 14Size Estimating Notes and

Reuse

Slide # 2 January 11, 2004

CSE 7315 - SW Project Management / Module 14 - Size Estimating Notes and

ReuseCopyright © 1995-2004, Dennis J. Frailey,

All Rights ReservedCSE7315M14

Objectives of This Module• To discuss some general points

about size estimating• To discuss how to deal with reuse

when estimating





Detailed Planning - Processes

EstimateScheduleEvaluate

Source InformationStatement of Work

RequirementsConstraintsStandardsProcesses

Historyetc.

WBS Size

Effort &

Cost

Schedule

OKCompleteDetailedPlanning

Revise &Negotiate

Not OK

EstimateSize

EstimateEffort and

Cost





What Method if No Data?• What if you have absolutely no data

on the code to be written?– no prior experience– no expertise available

• You may be able to try something like function points if you know the functional requirements

• Or wideband Delphi• Or just count requirements





Risk Management

The less you know when estimating, the more you need to plan on several updated estimates as you learn more





What About Non-Software WBS Tasks that do Not Influence Size?

• Some of these may depend on size– Number and size of documents

required– Management costs– Number of reports– Magnitude of support functions– Cost of inspections

• Such tasks will be estimated (for effort or cost) AFTER size is estimated (see later)





What about Non-software WBS Tasks that do Not Influence Size? (continued)

• Other tasks may be independent of size but dependent on effort or headcount– Number of workstations– Number of copies needed for

compilers, tools– etc.





Other Non-Software WBS Tasks • Some tasks may be independent of

size or effort– Travel to attend reviews and

meetings with customer– Legal fees for setting up contracts– etc.

All of these non-software tasks will be addressed during effort and cost

estimating

January 11, 2004




Final Notes1) Use more than one method and resolve

discrepancies– No method is reliable enough in most cases– When two methods disagree, it tells you you

are missing some facts

Method 1 WidebandDelphi

Resolution?

Method 3

Method 2Statistical Analysis

OK

(Revise Estimates)

Not OK

January 11, 2004




Final Notes(continued)

2) Include data declarations in size estimates

3) Include all functions - many are easy to overlook or underestimate– Control– Power up– Power failure– Diagnostics– Operating Systems

January 11, 2004





4) Select products (software items) carefully– Simplify interfaces – Minimize impact on support & maintenance– Fit the hardware in a reasonable fashion– Size should be manageable– One geographic area (preferably one

organization) for development– Allow incremental builds

Continued...

January 11, 2004





4) Select products (software items) carefully– Consider design and documentation

requirements– Too many SIs results in management

overhead and potentially higher cost– Too few SIs increases risk (less

visibility; harder to test; harder to maintain)





5) Don’t under-scope what you don’t understand– built-in test requirements– control panels– displays– .....


The biggest estimating errors are errors of

ignorance

“I didn’t realize that this part of the software was so complex.”






6) Consider the design methodology carefully– newer methods can be more

productive– but older ones often have less

risk due to experience, availability of tools, etc.






7) Account properly for reuse– do it - reuse can save lots of

money– don’t consider it to be free

January 11, 2004




Spreadsheet

CoCoMo BasedEffort Estimate

Other EffortEstimates ...

Size / Reuse Effort Effort & Cost Schedules

Final EffortEstimate

ProductivityBased Effort

Estimate

Generic Schedule

Effort Schedule

Labor Schedule

Cost Schedule

Analogy basedSize Estimate

SoftwareReuse

Analysis

Other SizeEstimates ...

Final SizeEstimate

Expert BasedSize Estimate





Dealing with Reuse• Many software programs are

derived from previous programs• This MAY result in savings of cost

and/or time• It MAY also result in increased

qualityBUT

• Reuse can also cost more and take longer and yield lower quality

January 11, 2004




Quality = x Reused:Quality = x

New:Quality = y

Old Software New Software

• Quality of new software depends on x and y.• If old software has poor quality it brings down

the quality of the new software.• But if it has high quality, it brings quality up.

Reuse Quality Diagram





What Can be Reused? ... ...Just About Anything

• Code• Test Code• Test Cases and Procedures• Documentation• Design Specifications• Designs

January 11, 2004




Reuse is Almost Never “Free”• Because you seldom have everything

you need– You typically need to create tests or

documents or other things• And you need to design the software to

incorporate the “reused” components• And you need to integrate the “reused”

components with everything else

January 11, 2004




Reuse TerminologyLegacy Code Code developed for a previous application &

BELIEVED TO BE OF USE for new applicationModified Code Code developed for a previous application

that is suitable for a new application after a MODEST AMOUNT OF MODIFICATION

Reused Code Code developed for previous application

suitable WITHOUT CHANGE OF ANY KIND

January 11, 2004




Legacy Code vs. Reusable Code

Legacy Code• Designed for a

Specific Application• Lax Standards for

– Documentation– Test Procedures– Test Cases

Like looking in a junkyard to find something of use

Reusable Code• Designed for Several

Applications• Good Standards for

– Documentation– Test Procedures– Test Cases

Like looking in a library to find something of use

January 11, 2004




Documenting Reuse Estimates

I tem NewLOC

ModifiedLOC

ReusedLOC

TotalLOC

Component #1 1233 0 0 1233Component #2 0 988 0 988Component #3 0 0 781 781Component #4 560 245 0 805Component #5 345 549 420 1314Total 2138 1782 1201 5121

• The total LOC column is total delivered lines of code

• This could be applied equally to function points or other measures

January 11, 2004




How Do You Count How Much of a Component is Modified or

Reused?• Consider Component #4 and

Component #5 on the previous slide• A Rule of Thumb:

– Go to the smallest level known• Unit or module (typically about 100 LOC)

– If the unit is not changed, it is “reused”– If the unit is changed, it is “modified”– If more than 50% of the unit is

changed, it is “new”

January 11, 2004




Incorporating Several Distinct Kinds of Modified Code

I tem NewLOC

ModifiedType 1

ModifiedType 2

ReusedLOC

TotalLOC

Component #1 1233 0 0 0 1233Component #2 0 988 0 0 988Component #3 0 0 0 781 781Component #4 560 0 245 0 805Component #5 345 302 247 420 1314Total 2138 1290 492 1201 5121

January 11, 2004




TotalDelivered

SizeConversion

Process EquivalentSize

ReuseInformation

Calculating the Benefit of Reuse

• After estimating size, and before estimating effort, you must convert reused code to “equivalent” new code

January 11, 2004




How Do You Convert?• The conversion factor is based on

how much less effort you will expend for reused or modified code than for new code

• Assuming you have historical justification of the conversion factors, you can do a simple calculation

January 11, 2004




Conversion Factor Example• Equivalent size can be estimated

directly via “reuse factors,” e.g.: – Reused code takes about 30% as much

effort as new code– Modified code takes 60% as much effort

as new code

I tem New Modified Reused TotalTotal 2,138 1,782 1,201 5,121Factor 100% 60% 30%Net 2,138 1,069 360 3,568

January 11, 2004




Example Concluded• This says that the total effort to

develop these 5121 lines of code will be comparable to that of producing 3567 lines of new code.

• The same approach can be used for function points or other measures of software size.

January 11, 2004




Where Did Those “Reuse Factors”

Come From?• Experience!– Over many hundreds of projects– But these are averages, and they vary a lot

• Your experience may vary from mine– You must keep track in order to know

• Different kinds of modified code may have different factors

January 11, 2004




Typical Reuse FactorsEase of Using Reused

Modifi ed

Concurrent (*) .5-1% 1-3% Easy 10% 25% Average 30% 60% Hard 40% 75%

(*) See later slides for information on concurrent reuse

January 11, 2004




We Can Get More Accurate• If we are willing to look more closely

at the– Process &– Reuse Characteristics,

• Then we can gain a deeper understanding of the reuse impact

• We can also use this information to calculate the reuse factors used in the previous example

January 11, 2004




First Examine the Process• List the steps of the process• Then determine the % of the total

effort expended in each step, when developing new code

• Note that this is effort, not time• Example:

Requirements Design Code & Test I ntegration18% 25% 25% 32%





Next Develop a Factor to Represent the Reuse Benefit

in Each Process StepRequire-ments

Design Code and Unit

Test

Integration

Relative Effort

18% 25% 25% 32%

Reuse Factor

10% 15% 5% 75%

Modified Factor

40% 35% 55% 80%

January 11, 2004




For Example …• Let RM be the % of the requirements

effort for this reused software– We must analyze requirements to see if

reused code can be used• Let DM be the % of the design effort for

this reused software– We may have to plan to test the software

and maybe design the rest of the software in a special way

Continued...

January 11, 2004




For Example (continued)

• Let CM be the % of the coding and unit testing effort required for this reused software– Normally 0 for “pure reused” code,

but not for modified code• Let IM be the % of the integration

effort required for this code – often 50-100% even for pure reused

January 11, 2004




Applying the More Accurate Method

• For each phase of the process– Determine % Effort for – Determine the Effect of Reuse

Process StepReqs DesignCode I ntegrationPercent 18% 25% 25% 32%

Delivered Equivalent2,138 New 100% 100% 100% 100% 2,1381,782 Modified 20% 40% 70% 100% 1,1241,201Reused 10% 0% 0% 100% 4065,121 Total 3,668

January 11, 2004




• Once again, the method can be used for any measure of size, such as function points, feature points, etc.

• For truly reused code– CM is probably 0, but maybe you must do

some test code, so perhaps it is not – RM and DM are probably > 0

• It takes effort to analyze and determine whether reused code will work

– IM is generally not 0 • You have to run the integration tests ...

Notes

January 11, 2004




Why is it “Modified” if You Change it Only a Little Bit

• Totally reused code has:– Identical documentation– Identical test procedures, code, etc.– One master copy to maintain in the

configuration management library– One part number for record keeping,

inventory, etc.Continued...

January 11, 2004




Why is it “Modified” if you Change it Only a Little Bit

(continued)• Even if you change 1 comment line

– You need to maintain two copies in the CM library (of code, test code, etc.)

• And if you change 1 line of executable code– You need to change tests and

documentation

January 11, 2004




What About Concurrent Reuse?

• “Concurrent” reuse is reusing something multiple times within the same software product– For example, if the same subroutine is used

in each of several system components• It has very low cost, but it is not “free”

– You have to integrate and test each component

– And if you find a problem, you must fix it multiple times





Reuse Factor To Use for Concurrent Reuse

• Typically, a concurrent reuse situation calls for a factor no larger than 5%– If the initial code is new or heavily

modified, the second and subsequent uses (concurrent reuse) tend to need factors of about 2-4%

– If the initial code is reused or lightly modified, the proper factor tends to run from 0.5% to 2%





Concurrent Reuse ExampleItem New Modified Reuse

dConcurren

t ReuseTotal

Total 2,138

1,782 1,201 2,000 7,121

Factor 100%

60% 30% 1%

Net 2,138

1,069 360 20 3,588





Maintenance vs Reuse?• If you have a large amount of code

and are modifying only a part of it, as in a maintenance situation, is this a form of reuse? If so, what reuse factor is appropriate?– Typically the factor would be very small– Often, people estimate maintenance

with a bottom-up technique rather than as a form of “reuse”

January 11, 2004




More Notes on Reuse• The earlier in the process you

reuse, the more leverage you get– Reusing an architecture or a design

will support multiple target machines, languages, etc.

Requirements

Design

Code

Test

January 11, 2004




A Final Note on Reuse• The most important factor in

planning reuse is application domain– A series of products in the same

domain will get more reuse than a series of unrelated products

– And it will be easier to find what you need when you need it

– And the staff are more likely to be familiar with the old code and how it can be used again





Summary of Size Estimating• History is your best ally• Use multiple methods

– to learn– to reduce risk

• Target memory size is handled differently from source code size, although the two are generally related

• Account for reuse





Module Summary• There are many special cases and

issues to consider when estimating size

• Reuse is accounted for by computing an equivalent size, based on the gains from reuse– These are estimated by conversion

factors based on past experience





END OFMODULE 14

cse 7315 - sw project management / module 14 - size estimating notes and reuse copyright 1995-2004,...

Documents