Transcript Document

Software Estimation
Software Estimation
 Direct measurement
 LOC
 Indirect measurement




Heuristics
Function point
Feature point
3D Function point
2
Lines of Code (LOC)
 Lines of Code (LOC)
 Most traditionally used metric for project sizing
 Most controversial
 Count comments?
 Declaring variables?
 Efficient code vs. code bloat
 Language differences
 Easier to count afterwards than to estimate
3
Lines of Code (LOC)
LOC/pm
$/LOC
Cost
Functions
estimated LOC
Effort (months)
UICF
2340
315
14
32,000
7.4
2DGA
5380
220
20
107,000
24.4
3DGA
6800
220
20
136,000
30.9
DSM
3350
240
18
60,000
13.9
CGDF
4950
200
22
109,000
24.7
PCF
2140
140
28
60,000
15.2
300
18
151,000
28.0
655,000
145.0
DAM
Totals
8400
33,360
4
Software Estimation
 Heuristics
 Rules of thumb approach to estimating
 Require a predictable percentage of the overall effort
 30% planning
 20% coding
 25% component testing
 25% system testing
 Estimating Software Costs -Capers
5
Function Points
 Function Points
 analysis based on evaluation of data and transactional
types:
 Internal Logical File (ILF)
 External Interface File (EIF)
 External Input (EI)
 External Output (EO)
 External Inquiry (EQ)
6
The Application Boundary for
Function Point Analysis
7
Function Points
 Application Boundaries
 The application is planned to be developed in multiple
stages, using more than one development project
should be counted, estimated, and measured as separate
projects, including all inputs, outputs, interfaces and
inquiries crossing all boundaries.
 The application is planned to be developed as a single
application using one development project, but it is so
large divide it into subapplications
8
Function Points
 Application Boundaries (con’t)
 The subapplications should be counted separated, but
none of the inputs, outputs, interfaces, and inquiries
crossing the arbitrary internal boundaries should be
counted.
 The function points of the subapplications should be
summed to give the total function points of the
application.
9
Function Points- Steps
 Classify and count the five user function types
 3 level of complexity
 Adjust for processing complexity
 Make the function point calculation
10
Function Points
Weight Factor
measurement parameter
count
simple
count average count complex
number of user inputs
x
3
+
x 4 +
x 6
=
number of user outputs
x
4
+
x 5 +
x 7
=
number of user inquiries
x
3
+
x 4 +
x 6
=
number of user files
x
7
+
x 10 +
x15
=
number of ext. interfaces
x
5
+
x 7 +
x10
=
count = total
complexity multiplier
function points
11
Function Points
 External Input Types are screen or forms through
which human users of an application or other
programs add new data or update existing data.
 Count each unique user data or user control input
type that enters the external boundary of the
application being measured, and adds or changes
data in a logical internal file type.
 An external input type should be considered unique
if it has a different format, or requires a processing
logic different from other external input types of
the same format.
12
Function Points
 External Input Type
 Simple: few data element types included in the
external input type, and few logical internal file
types are referenced by the external input type.
User human factors considerations are not
significant in the design of the external input type.
 Average: is not clearly either simple or complex
 Complex: many data element types are included in
the external input type, and many logical internal
file types are referenced by the external input type.
User human factors considerations significantly
affect the design of the external input type.
13
Function Points
 External Output Types are screens or reports, or
messages which the application produces for humans
use or for other programs.
 Count each unique user data or control output type that
leaves the external boundary of the application being
measured.
 An external output type should be considered unique if it
has a different format, or requires a processing logic
different from other external output types of the same
format
14
Function Points
 External Output Type
 Simple: one or more columns, simple data element
transformation
 Average: multiple columns with subtotals, multiple data
element transformation
 Complexity: intricate data element transformations,
multiple and complex file references to be correlated,
significant performance considerations.
15
Function Points
 Logical Internal File Types are logical collections of
records which the application modifies or updates.
 Count each major logical group of user data or control
information in the application, include logical file, or
within a data base, each logical group of data from the
viewpoint of the user, that is generated, used, and
maintained by the application.
16
Function Points
 Logical Internal File Types
 Simple: few record types, few data element types, no
significant performance or recovery considerations.
 Average: is not clearly either simple or complex
 Complex: many record types, many data element types,
performance and recovery are significant considerations.
17
Function Points
 External Interface File Types are files passed or shared
with other applications.
 Count each major logical group of user data or control
information that enters or leaves the application.
 Complexity classification: use definition similar to those
for logical internal file types.
18
Function Points
 External Inquiries Types are screens which allow users
to interrogate the application and ask for assistance or
information.
 Count each unique input/output combination, where an
input causes and generates an immediate output.
 An external inquiry type should be considered unique if
it has a format different from other external inquiry
types in either its input or output parts, or requires a
processing logic different from other external inquiry
type of the same format.
19
Function Points
 External Inquiry Types
 classify the input part using definitions similar to the
external input type
 classify the output part using definition similar to the
external output type.
 The complexity of the external inquiry type is the
greater of the two classifications.
20
IFPUG File Type Complexity
Num ber of record types Num ber of data types
< 20
20-50
> 50
1
low
low
Avg.
2-5
low
Avg.
high
>5
Avg.
high
high
21
IFPUG External Input Complexity
Num ber of file types
accessed
Num ber of data types
accessed
<5
5-15 > 15
0 or 1
low
low
Avg.
2
low
Avg.
high
>2
Avg.
high
high
22
IFPUG External Output Complexity
Num ber of file types
Num ber of data types
<6
6-19
> 19
0 or 1
low
low
Avg.
2 or 3
low
Avg.
high
>3
Avg.
high
high
23
Processing Complexity
 Estimate the degree of influence of each of the 14
general characteristics
 Sum the 14 degree of influences and develop an
adjustment factor
 Multiply the adjustment factor to the work-product
measure
24
14 General Characteristics
 Data Communications
 Distributed Data
Processing
 Performance
 Heavily Used
Configuration
 Transaction Rate
 Online Data Entry








End User Efficiency
Online Update
Complex Processing
Reusability
Installation Ease
Operational Ease
Multiple Sites
Facilitate Change
25
GSC and Total Adjusted Function
Point
General System
Characteristic
Degree of
Influence
General System Characteristic
Degree of
Influence
Data communication
3
Facilitate change
2
Distributed data processing
2
Total degree of influence
40
Performance
4
VAF = (40*.01)+.65 = 1.05
Heavily used configuration
3
Transaction rate
3
Total adjusted FP = 200*1.05 =
210
On-line data entry
4
End user efficiency
4
Online update
3
Complex processing
3
Reusability
2
Installation ease
3
Operational ease
3
Multiple sites
1
26
Function Point - Calculation
M
 Adjustment factor = 0.65 + 0.01 X
Fi
 Function Point = count-total X adjustment factor
27
Example
Sensors
User
password
zone inquiry
panic button
sensor inquiry
activate/
deactivate
SafeHome
User
Interface
Function
messages
sensor status
Password, sensor, …
System configuration data
User
Monitoring
& Response
Subsystem
28
Feature Points
 Feature Points were originally invented to solve the
measurement problems of classical MIS.
 Feature Point measure accommodates applications in
which algorithmic complexity is high such as real time
software, systems software, embedded software.
 Algorithm is defined as the set of rules which must be
completely expressed to solve a significant
computational problem.
29
Example: Feature Points Approach
measurement parameter
weight
count
number of user inputs
40
x
4
=
160
number of user outputs
25
x
5
=
125
number of user inquiries
12
x
4
=
48
number of files
4
x
7
=
28
number of ext.interfaces
4
x
7
=
28
algorithms
60
x
3
=
180
count-total
0.25 p-m / FP = 120 p-m
569
complexity multiplier
.84
feature points
478
30
3D Function Point
 Data dimension is evaluated in the same way as Function Point
(inputs, outputs, inquiries, logical files, interface files)
 Functional dimension is measured by considering the number of
internal operations required to transform input to output data.
 Input and output data may be either internal to the application,
external application , or both.
 Level of complexity of each transformation is a function of the
number of processing steps and the number of semantic statements
that control the processing steps.
31
3D Function Point
 Functional dimension
 transformation is viewed as a series of processing steps
and semantic statements that cooperate to transform one
set of input data into a set of output data.
 semantic statements the predicated and the pre- and
post-conditions for each step of the process.
 Input and output do not necessarily refer to the input and
output transactions that are part of the data dimension.
 Processing that changes only the structure, format, or
order of the data is not a transformation.
32
3D Function Point
 Control dimension is measured by summing the counts
of both states and transitions.
 A state is a set that contains one and only one- value for
each condition of interest in the application. Any time
the value of any data element in the internal data
structure changes, the state of the application also
changes.
 A transition is a valid path from one state to another, or
to the same state
33
Internal Data Structure and
Interface
1-19
DET
20-50
DET
51+
DET
1
RET
L
L
A
2-5
RET
L
A
H
6+
RET
A
H
H
34
Level of Complexity Table for
Input
1-4
DET
5-15
DET
16+
DET
0-1
FTR
L
L
A
2
FTR
L
A
H
3+
FTR
A
H
H
35
Level of Complexity Table for Output
1-5
DET
6-19
DET
20+
DET
0-1
FTR
L
L
A
2-3
FTR
L
A
H
4+
FTR
A
H
H
36
Level of Complexity Table for
Transformations
1-5
Semantic
Statement
6-19
Semantic
Statement
20+
Semantic
Statement
1-10
Steps
L
L
A
11-20
Steps
L
A
H
21+
Steps
A
H
H
37
State Transition Diagram
full and start
invoke manage-copying
reading
operator
commands
copies done
invoke read-op-input
making copies
full
invoke read-op-input
empty
invoke reload paper
reloading paper
jammed
invoke problem-diagnosis
problem state
not jammed
invoke read-op-input
38
Weights to Calculate 3 D Function Point
Weight Factor
measurement parameter
count
count average count complex
simple
Inputs
x
3
+
x 4 +
x 6
=
Outputs
x
4
+
x 5 +
x 7
=
Inquiries
x
3
+
x 4 +
x 6
=
Internal Data
x
7
+
x 10 +
x15
=
External Data
x
5
+
x 7 +
x10
=
Transformation
x
7
+
x 10 +
x15
=
Transition
x N/A
+
x 3 +
x N/A =
Total 3D Function Point
39
Backfiring
 Technique for converting function point count to
LOC
P rog ramm in g
L a ng u ag e
LO C p e r F un c tion p oin t
av g .
me d ia n
low
h igh
Ada
154
-
104
205
A s semb ler
C
C ++
337
162
66
315
109
53
91
33
29
694
704
178
C O BOL
Java
JavaSc ript
77
63
58
77
53
63
14
77
42
400
75
Pe rl
P L /1
P o wer b uild er
S AS
Sma llta lk
SQ L
60
78
32
40
26
40
67
31
41
19
37
22
11
33
10
7
263
105
49
55
110
Visua l B asic
47
42
16
158
40
COCOMO –
COnstructive COst MOdel
 Developed at TRW, a US defense contractor
 Based on a cost database of more than 60 different
projects
 Exists in three stages
 Basic - Gives a 'ball-park' estimate based on product
attributes
 Intermediate - modifies basic estimate using project and
process attributes
 Advanced - Estimates project phases and parts
separately
41
COCOMO MOdel
 Project Types
 Organic mode small teams, familiar environment,
well-understood applications, no difficult nonfunctional requirements (EASY)
—Semi-detached mode Project team may have
experience mixture, system may have more
significant non-functional constraints, organization
may have less familiarity with application
(HARDER)
—Embedded Hardware/software systems, tight
constraints, unusual for team to have deep
application experience (HARD)
42
COCOMO MOdel
 Basic Formulas




Organic – Person-Months = 2.4 x (KDSI)1.05
Semi-detached– Person-Months = 3.0 x KDSI1.12
Embedded– Person Months = 3. 6 x KDSI1.20
KDSI = thousands of delivered source instructions, i.e.
LOC
43
COCOMO Examples
 Organic mode project, 32KLOC
— PM = 2.4 (32) 1.05 = 91 person months
— TDEV = 2.5 (91) 0.38 = 14 months
— N = 91/15 = 6.5 people
 Embedded mode project, 128KLOC
— PM = 3.6 (128)1.2 = 1216 person-months
—TDEV = 2.5 (1216)0.32 = 24 months
— N = 1216/24 = 51
44
COCOMO MOdel
 Duration Formulas
 Organic
 Semidetached
 Embeded
TDEV=2.5(MM)0.38
TDEV=2.5(MM)0.35
TDEV=2.5(MM)0.32
45
COCOMO MOdel
 Intermediate Formulas
 Organic
PM = 3.2 x (KDSI)1.05 * EAF
 Semi-detached
PM = 3.0 x KDSI1.12 * EAF
 Embedded–
PM = 2.8 x KDSI1.20 * EAF
 EAF =Effort Adjustment Factor
46
Cost Driver Attributes
 Personnel attributes





Analyst capability
Virtual machine experience
Programmer capability
Programming language experience
Application experience
 Product attributes
 Reliability requirement
 Database size
 Product complexity
47
Cost Driver Attributes
 Computer attributes




Execution time constraints
Storage constraints
Virtual machine volatility
Computer turnaround time
 Project attributes
 Modern programming practices
 Software tools
 Required development schedule
48
49
50
51
52
53
COCOMO II
 COCOMO II recognizes different approaches to
software development such as prototyping,
development by component composition, use of 4GLs,
etc.
 Levels are associated with activities in the software
process so that initial estimates may be made early in
the process with more detailed estimating carried out
after the system architecture has been defined.
54
COCOMO II
 Models
 The Early Prototyping Level (Application
Composition)
 Size estimates are based on object points
 The Early Design Level
 Estimates are based on function points
 The Post-architecture Level
 Estimates use more extensive set of multipliers.
55
The Early Prototyping Level
 Size estimates are based on object points and a
simple size/productivity formula is used to
estimate the effort required.
 This level supports software developed by
composing existing components.
56
The Early Prototyping Level
 Formula:
PM = (NOP x (1 - %reuse/100))/PROD
PM = person-months
NOP = New Object Point
%reuse = the percentage of reuse that is
expected
PROD = productivity
 Object Point
 Screens
 Reports
 Components
57
The Early Prototyping Level
58
The Early Prototyping Level
59
The Early Prototyping Level
60
The Early Design Level
 Size estimates are based on FP and multipliers
 This estimate refers to the code that is implemented
manually rather than generated or reused.
 Formula:
Effort = A x SizeB x M
A = 2.5
B = 1.01 + 0.01
Wi
M = PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED
61
The Early Design Level
 Automatically Translated Code
 Formula:
Effort = A x SizeB x M + Pmauto
Pmauto = (ASLOC x (AT/100))/ATPROD
ASLOC
= Amount of software to be adapted
AT = % of the code that is reengineered by automatic
translation
ATPROD = 24000
62
Rating Scheme for The COCOMO 2 Scale
Factors
63
Exponent Computation
 Precedentedness:
 similar to several previous developed projects
 Development Flexibility:
 need for software conformance with pre-established
requirements,
 need for software conformance with external interface
specification
64
Exponent Computation
 Architecture/Risk Resolution:
 Risk management plan identifies all critical risk item
 Schedule budget compatible with risk management plan
 % of development schedule devoted to establishing
architecture
 % of required top software architects available to project
 Tool support
 Number of risk items
65
Exponent Computation
 Team Cohesion:
 Consistency of stakeholder objectives
 Ability, willingness of stakeholders to accommodate
other stakeholder’s objectives
 Experience of stakeholders in operating as a team
 Stakeholder team building to achieve shared vision
and commitments
 Process Maturity:
 5 levels of CMM
66
The Early Design Level 7 Multipliers







PERS = Personal Capability
RCPX = Reliability and Complexity
RUSE = Reuse Required
PDIF = Platform Difficulty
PREX = Personal Experience
FCIL = Support Facilities
SCED = Schedule
67
The Post-architecture Level
 The estimates are based on the same basic formula that
is used in the early design estimates.
 This stage uses a more extensive set of multipliers.
 Formula:
Effort = A x SizeB x ESLOC x M + Pmauto
ESLOC = ASLOC x (AA+SU+0.4DM+0.3CM+0.3IM)/100
ESLOC = Equivalent number of new instructions
Pmauto = (ASLOC x (AT/100))/ATPROD
AT = % of the code that is reengineered by automatic
translation
ATPROD = 2400
68
ESLOC
 ASLOC = Amount of software to be adapted
 AA = The assessment and assimilation increment
 Determine whether a reused software module is
appropriate to the application, and to integrate its
description into the overall product description
 SU = The software understanding increment
 Software is structured and clear, self descriptiveness
 DM = The percentage of design modification
 CM = The percentage of code modification
 IM = The percentage of the original integration effort
required for integrating the reused software.
69
AA = The Assessment and
Assimilation Increment
70
Percentage of Automated Reengineering
71
SU = The Software Understanding
Increment
72
The Post-architecture Level- 17
Multipliers









RELY = Required Software Reliability
DATA = Data Base Size
CPLX = Product Complexity
RUSE = Required Reusable
DOCU = Documentation match to life-cycle needs
TIME = Execution Time Constraint
STOR = Main Storage Constraint
PVOL = Platform Volatility
ACAP = Analyst Capability
73
The Post-architecture Level- 17
Multipliers








PCAP = Programmer Capability
AEXP = Applications Experience
PEXP = Platform Experience
LTEX = Language and Tool Experience
PCON = Personnel Continuity
TOOL = Use of Software Tools
SITE = Multisite Development
SCED = Required Development Schedule
74
Development Schedule
Estimates
 Initial baseline schedule equation for all 3 COCOMO
II
 TDEV=[3.0x(PM)(0.33+0.2x(B-1.01)]xSCED%/100
 SCED = cost driver rating
75