Get documents about "PowerPoint Presentation
Document Sample
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)
Functions e stimate d LOC LOC/pm $/LOC Cost 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
DAM 8400 300 18 151,000 28.0
Tota ls 33,360 655,000 145.0
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 + x 15 =
number of ext. interfaces x 5 + x 7 + x 10 =
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
Number of record types Number 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
Number of file types Number of data types
accessed accessed
< 5 5-15 > 15
0 or 1 low low Avg.
2 low Avg. high
>2 Avg. high high
22
IFPUG External Output Complexity
Number of file types Number 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
End User Efficiency
Data Communications Online Update
Distributed Data Complex Processing
Processing Reusability
Performance Installation Ease
Heavily Used Operational Ease
Configuration Multiple Sites
Transaction Rate Facilitate Change
Online Data Entry
25
GSC and Total Adjusted Function
Point
General System Characteristic Degree of
General System Degree of Influence
Characteristic 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 Total adjusted FP = 200*1.05 =
Transaction rate 3 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
Adjustment factor = 0.65 + 0.01 X Fi
M
Function Point = count-total X adjustment factor
27
Example
Sensors
password
zone inquiry SafeHome messages
panic button User
User sensor status User
sensor inquiry Interface
activate/ Function
deactivate
Password, sensor, … Monitoring
& Response
Subsystem
System configuration data
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 count weight
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
0.25 p-m / FP = 120 p-m
number of ext.interfaces 4 x 7 = 28
algorithms 60 x 3 = 180
count-total 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 20-50 51+
DET DET 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 5-15 16+
DET DET DET
0-1
L L A
FTR
2
L A H
FTR
3+
FTR A H H
35
Level of Complexity Table for Output
1-5 6-19 20+
DET DET DET
0-1
L L A
FTR
2-3
L A H
FTR
4+
FTR A H H
36
Level of Complexity Table for
Transformations
1-5 6-19 20+
Semantic Semantic Semantic
Statement Statement Statement
1-10
L L A
Steps
11-20
L A H
Steps
21+
Steps A H H
37
State Transition Diagram
full and start
invoke manage-copying reading
operator
commands
full
copies done invoke read-op-input
invoke read-op-input
making copies reloading paper
empty
invoke reload paper
jammed
invoke problem-diagnosis
not jammed
problem state invoke read-op-input
38
Weights to Calculate 3 D Function Point
Weight Factor
measurement parameter count simple count average count complex
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 + x 15 =
External Data x 5 + x 7 + x 10 =
Transformation x 7 + x 10 + x 15 =
Transition x N/A + x 3 + x N/A =
Total 3D Function Point
39
Backfiring
Technique for converting function point count to
LOC
Programming LO C per Function point
Language avg. median low high
Ada 154 - 104 205
As semb ler 337 315 91 694
C 162 109 33 704
C++ 66 53 29 178
COBOL 77 77 14 400
Java 63 53 77 -
JavaSc ript 58 63 42 75
Perl 60 - - -
PL/1 78 67 22 263
Powerbuilder 32 31 11 105
SAS 40 41 33 49
Smalltalk 26 19 10 55
SQL 40 37 7 110
Visua l Basic 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 non-
functional 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 TDEV=2.5(MM)0.38
Semidetached TDEV=2.5(MM)0.35
Embeded 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 Re-
engineering
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
