Transcript Software Development Plan - University of Central Florida

Software
Size and Cost Estimation
CEN 5016
© Dr. David A. Workman
School of Computer Science
Feburary 24, 2005
Revised:
February 27, 2007
Software Project Estimation
•
•
METHODS of ATTACK
– Base estimates on similar projects that have already been completed.
– Use decomposition techniques.
– Use statistically derived empirical models.
DECOMPOSITION TECHNIQUES
Accuracy depends on the following factors:
•
•
•
•
–
–
–
–
degree of accuracy with which the planner has estimated size of the system to be
constructed;
ability of planner to translate size estimates into human effort;
degree to which the project plan reflects the abilities of the software team;
stability of product requirements and the development environment.
Fuzzy-logic Sizing
Function Point Sizing (#EIF, #ILF, #EI, #EO, #EQ)
Standard Component Sizing (subsystems, modules, screens, reports, files, menus )
Change Sizing (modifications to an existing system)
Ref: Putnam and Meyers, Measures for Excellence, Yourdon Press, 1992.
Feb. 27, 2007
(c) Dr. David A. Workman
2
Size-Related Attributes
•
Source Lines of Code (SLOC or LOC)
– Logical vs. Physical
Logical = a single source statement in a given programming language
Physical = physical lines in a source file (number of EOLs)
– Developed vs. Non-developed
• Developed = source statements added or modified specifically for the
software product under development.
• Non-developed = reused source statements (without change) and deleted
source statements ( removed or modified from a previous version or similar
product).
– New SS = #added + #modified
– Deleted SS = #modified + #removed
– Reused SS = #original - #modified - #removed
Feb. 27, 2007
(c) Dr. David A. Workman
3
Function Points: Introduction
•
•
Reference
Function Point Analysis, by D. Garmus and D. Herron, Addison-Wesley,
2001, ISBN = 0-201-69944-3
Definitions
– Number of Internal Logical Files (ILF)
– Number of External Interface Files (EIF)
– Number of External Inputs (EI)
– Number of External Outputs (EO)
– Number of External Queries (EQ)
– (Raw) Function Point Count = a weighted sum of counts of the five
system features enumerated above. Weights are a function of feature
complexity ( low, medium , high ) and empirical data.
– Adjusted Function Point Count = Raw FP * A( F1, F2, …, F14), where
F1, F2, …, F14 are project adjustment factors that must be estimated as
to their “degree of influence” ( 0..5 ).
Feb. 27, 2007
(c) Dr. David A. Workman
4
Data Functions: Internal Logical Files
Definition (Internal Logical Files)(ILF)
A user-identifiable group of logically related data or control information maintained
within the boundary of the system. The primary purpose is to hold data that must
be maintained by one or more elementary operations and must persist beyond a
single operation.
Clarification:
– ILFs are internal entity objects/classes used to encapsulate and maintain
“problem” data within the system.
– ILFs are standalone classes or base classes of an inheritance hierarchy.
– Elementary Operation are methods defined for ILFs.
Examples:
OSSIM: Computer System, Device, User, CPU, OS, Memory, Address Unit,
Process, Program, Segment, Instruction
ROBOT: Waiter, Assistant, Treats, Tray, Guest, Kitchen, Reception Room
Twine: Instruction, Basic Block, Code Segment
Satellite: Command, Recorded Data, Position, Velocity, Attitude
Rover: Command, Target Vehicle, Position, Velocity, Attitude, Obstacles, Path
PACS: Program, Package, File, Class, Interface, Frame, Method, Feature,
Symbol
FAMS: NFA, STD, TT, Alphabet, States
Feb. 27, 2007
(c) Dr. David A. Workman
5
Data Functions: External Interface Files
Definition (External Interface Files)(EIF)
A user-identifiable group of logically related data or control information
maintained by an application outside the boundary of the system. The
primary purpose is to hold data that must be referenced by one or more
elementary operations within the system.
Clarification:
– An EIF is an ILF for an autonomous system modeled as an actor (online independent systems).
– An EIF is a persistent database table.
– An EIF is any class designed to hold data for import or export to an
actor other than interactive users.
Feb. 27, 2007
(c) Dr. David A. Workman
6
Data Functions: Complexity Level
Principle: Each ILF and EIF must be assigned a complexity level based on the
number of Data Element Types (DETs) and Record Element Types (RETs)
associated with it.
RET: A subclass of an ILF or EIF.
- Count “1” for standalone ILF or EIF classes.
- Count “1” for the base class of each ILF or EIF inheritance hierarchy.
- Add “1” for each derived subclass of an ILF or EIF inheritance tree.
DET: A unique user-identifiable, non-repeated field or attribute of an ILF,
EIF or RET.
- Count “1” for each group of data members that has a unique purpose.
- Count “1” for each pointer or handle that maintains an association or
composition relationship with some other object.
- Count “1” for array objects and data members used to index that object.
- For subclasses (RETs), consider only those data members explicitly
defined by the subclass; inherited data members are already counted.
Feb. 27, 2007
(c) Dr. David A. Workman
7
ILFs, EIFs, RETs, DETs
Class A
X
Y
alpha
beta
Class A1
Class Z
Class B
A
B
C
D
E
Class A2
U
V
Class B1
X1
Y1
delta
Class A12
Class A11
U2
V2
T
R
Class A211
R7
Feb. 27, 2007
Class A21
ILF = 3
Class A ( RET = 8)(DET = 12)
Class B ( RET = 2)(DET = 3)
Class Z (RET = 1) (DET = 5)
Class A211
T7
(c) Dr. David A. Workman
8
Data Functions: Complexity Weights
Table 2. Complexity Weight
Complexity Weight
Record Element
Types
Table 1. Complexity Level
ILF
&
EIF
Data Element Types
1-19
20-50
>= 51
1
Low
Low
Medium
2-5
Low
Medium
High
>5
Medium
High
High
FP
Category
Low
Medium
High
ILF
x7
x10
x15
EIF
x5
x7
x10
EI
x3
x4
x6
EO
x4
x5
x7
EQ
x3
x4
x6
Rule1: For each ILF or EIF, use the RET count as a row index into Table 1. Use the DET count
to define the column index into Table 1. The entry at the intersection of the row and column
gives the complexity measure for the ILF or EIF. Note: the DET count for an ILF or EIF is
summed over all RETs associated with that ILF or EIF.
Rule 2: For a given ILF or EIF use the complexity level from Table 1 as a column index in Table 2.
Use the appropriate (ILF | EIF) row to index the weighting factor.
Sum the weights for all ILFs (and EIFs). The result is the unadjusted (raw) Function Point
count.
Feb. 27, 2007
(c) Dr. David A. Workman
9
Function Points: External Inputs
System Boundary
Transactional Functions
– External Inputs (EI)
– External Outputs (EO)
– External Queries (EQ)
Definition: (EI) External Inputs
EO
EI
EQ
ILF
An EI is an elementary process of the system that processes data or control
information that enters from outside the system boundary. The primary purpose
of an EI is to maintain one or more ILFs and/or to alter the behavior of the
system via its processing logic.
Clarification:
– An IE is an input operation (use case) that defines or updates some subset of the
data members of one or more ILFs; EIs are control class or boundary class
methods that manage a complete use case – these methods control use case
INPUT operations for capturing problem data within the system.
– An IE must bring data across the system boundary to populate one or more ILFs.
– The IE must have meaning to a system actor; that is, it is a use case involving
one or more actors.
– Two IE’s are unique, if they differ in the ILFs they maintain or in the set of data
members they define or update; two constructors for different subclasses (RETs)
of the same ILF would be treated as distinct IEs.
Feb. 27, 2007
(c) Dr. David A. Workman
10
Complexity: External Inputs
Principle: The physical count of EI’s, together with the relative functional complexity for
each determines the contribution of the external inputs to the unadjusted Function Point
count (UFP). Each identified EI must be assigned a functional complexity based on the
number of DETs and File Types referenced (FTRs).
– Complexity = low, medium, high
– DETs
= those that receive problem data that crosses the system boundary
– File Types Referenced = total number of distinct ILFs or RETs read or updated
by the EI together with the total number of EIFs (DB tables) read by the EI.
Counting Rules:
1.
2.
3.
4.
5.
6.
Do NOT count DETs not associated with problem data crossing the system boundary.
Add “1” DET for multiple fields serving a single purpose (e.g lines of an “street address”)
Add “1” DET for all prompts sent across the system boundary as part of an EI process; not
“1” for each prompt or message – “1” for all such outputs.
Add “1” DET for all error messages sent across the system boundary as part of an EI
process.
Add “1” DET for all mechanisms that can trigger the action of the given EI; e.g., if a mouse
click and function key are two distinct interaction mechanisms for triggering the same EI,
then count only “1” (for the EI), not “2” for the different invocation methods.
Count only “1” FTR for each ILF, RET, or EIF that is both read and maintained (updated)
by the same EI.
Feb. 27, 2007
(c) Dr. David A. Workman
11
Transaction Function: External Output
Definition: (EO) External Output
An EO is an elementary process of the System that generates data and control
information that exits the System boundary. The primary intent of an EO is to
present information to a System actor through processing logic other than, or in
addition to, the retrieval of data or control information. The processing logic
must contain at least one mathematical formula or calculation, create derived
data, maintain one or more ILFs and/or alter the behavior of the System.
Clarification
– An EO is an output use case (“ the smallest unit of activity that is meaningful to
the user).
– An EO must leave the System in a consistent state.
– Control information is data used or generated by the System for the purpose of
influencing an elementary process (use case); e.g., control signal in real-time
systems, output messages instructing the user to take some action.
– Processing logic on its own should not be used to determine unique EI, EO or
EQs; re-arranging, re-formatting, and re-sorting a set of data in various ways do
not by themselves constitute unique EO’s.
– unique calculations must be involved producing new information having
meaning to the user.
Feb. 27, 2007
(c) Dr. David A. Workman
12
Transaction Function: External Output
Examples
–
–
–
–
–
–
–
–
Mathematical calculations or unique algorithms
Conversion of units associated with values
Selecting a data subset based on some specified criteria
Updating ILFs, RETs or EIFs (but not using data crossing the system boundary)
Retrieval of data or control information
Computing or creating derived data
Altering the behavior of the System in some way
Preparation and presentation of information outside the System boundary
Counting Rules:
1.
2.
3.
4.
The data or control information must exit the System boundary (eventually)
The processing logic (algorithm) of the EO must perform one of the following:
(a) a mathematical calculation
(b) compute derived data
(c) update at least one ILF, RET or EIF
(d) alter the behavior of the System
The EO must be the smallest unit of activity meaningful to the user.
The EO must be self-contained and must leave the System in a consistent state.
Feb. 27, 2007
(c) Dr. David A. Workman
13
Transaction Function: External InQuiries
Definition: (EQ) External Inquiries
An EQ is an elementary process (use case) of the System that results in the retrieval
of data or control information sent outside the System boundary. The primary
intent is to present information to an actor maintained in an ILF or EIF. The
processing logic contains no mathematical formulas or calculations and creates
no derived data (it is output or presentation only). No ILF is updated during
processing, and the behavior of the application is not altered.
Clarification
– An EQ involves a request for information (calls on inspector methods), generally
from an ILF or an EIF, extracting the relevant DETs, and presenting them across
the System boundary to the user (or actor); e.g., file output operation, GUI
display operation, or database write operation.
– The data or control information must cross the System boundary.
– The data must be retrieved from one or more ILFs, RETs and/or EIFs.
– The EQ cannot derive data, cannot perform mathematical computations, nor
influence the behavior of the System (this characterizes an EO).
– An EQ cannot update (write to) an ILF, must be self-contained, and must leave
the System in a consistent state.
Feb. 27, 2007
(c) Dr. David A. Workman
14
Counting Rules: EO and EQ
Counting Rules (DETs)
1.
2.
3.
4.
Control fields that determine what, when, and/or how data is to be retrieved or generated.
Unique, user-recognizable, non-repeated fields that exit the System boundary.
If a DET both enters and leaves the System boundary, count it only once for the EO or EQ.
Count one DET for the capability to send a System response message outside the System
boundary to indicate an error, confirm that processing is complete, or verify that processing
should continue.
5. Count only one DET for the capability to specify an action to be taken by an EO or EQ even
if there are multiple invocation mechanisms for the action (count one for all call instances
of a given EO or EQ method).
6. Do NOT count System generated report fields such as “page no.”, “run date”, “positioning
info.”
7. Do NOT count literals, report titles, screen Ids, column headings and field titles.
8. Do NOT count temporary ILF fields computed during an EO or EQ if they do not cross the
System boundary.
9. Count one DET for a logical field that is stored physically as multiple fields but is viewed by
the user as a single piece of information.
10. Count one DET for each type of label and each type of numerical equivalent appearing on a
graphical display.
11. Count one DET for text information that may consist of a single word, sentence, paragraph,
or many paragraphs, but has a single meaning or purpose to the user.
Feb. 27, 2007
(c) Dr. David A. Workman
15
Transaction Function: External Output
Counting Rules (FTRs)
1.
2.
3.
Add “1” to the FTR count for each ILF, RET or EIF read during the EO or EQ.
Add “1” to the FTR count for each ILF, RET or EIF updated by an EO.
Add only “1” to the FTR count for an ILF, RET or EIF that is both read and updated by an
EO.
NOTE: FTRs count the number of distinct classes, subclasses, or tables accessed
by EI, EO and EQ operations. DETs are counts of the data members
actually accessed by these operations.
Feb. 27, 2007
(c) Dr. David A. Workman
16
Example: EI, EO, EQ
Server Node
Client Node(s)
EI
Browser
IIS
EI
ILF
ILF
ASP#
Page
ASP#
Page
*
1
TCP/IP
EO
EI
EI
EO
EO
EQ
EIFs
Feb. 27, 2007
(c) Dr. David A. Workman
WRMS
DB
17
Complexity Level: EI, EO, EQ
Data Element Types
Use the FTR count to index the row and
the DET count to index the column of the
table corresponding to a given EI, EO or
EQ to determine its complexity level.
File Types
Referenced
EQ
1-5
6-19
>= 20
1
Low
Low
Medium
2-3
Low
Medium
High
>3
Medium
High
High
Data Element Types
Data Element Types
EO
1-4
5-15
>= 16
<2
Low
Low
Medium
2
Low
Medium
High
>2
Medium
High
High
Feb. 27, 2007
File Types
Referenced
File Types
Referenced
EI
(c) Dr. David A. Workman
1-5
6-19
>= 20
<2
Low
Low
Medium
2-3
Low
Medium
High
>3
Medium
High
High
18
Adjustment Factors: Overview
• Complexity Adjustment Factors (Fi : 1 <= i <= 14)
F1: Data Communication: the degree to which on-line communication
with other systems or interactive users is required or central to the
application.
F2: Distributed Data Processing: the degree to which the application itself
is composed of autonomous and distributed components or subsystems;
distributed data is included in this factor.
F3: Performance: the degree to which response time and throughput
performance impact development.
F4: Heavily Used Configuration: the degree to which resource restrictions
influence the system design and development; includes situations where
the system must share or compete for resources with other independent
applications.
F5: Transaction Rate: applies primarily to transaction processing systems
where transaction rate is a critical design constraint.
Feb. 27, 2007
(c) Dr. David A. Workman
19
Adjustment Factors: Overview
• Complexity Adjustment Factors (Fi : 1 <= i <= 14)
F6: On-line Data Entry: the degree to which data is entered interactively;
includes on-line data entry and control.
F7: End User Efficiency: the degree to which consideration for human
factors and ease of use for end-users impacts system design.
F8: Online Update: the degree to which on-line (interactive) update to
internal logical files (ILFs) impacts system design.
F9: Complex Processing: the degree to which complexity of processing or
algorithmic logic impact system design; this includes the amount of data
validation and exception handling is required.
F10: Reusability: the degree to which the application and the design are
required to be reusable.
F11: Installation Ease: the degree to which conversion from previous and
possibly future environments influence the development of this system.
Feb. 27, 2007
(c) Dr. David A. Workman
20
Adjustment Factors: Overview
• Complexity Adjustment Factors (Fi : 1 <= i <= 14)
F12: Operational Ease: the degree to which operational aspects of the
system influence its design; e.g. start-up, recovery, backup processing,
and minimizing the need for manual intervention in these processes.
F13: Multiple Sites: the degree to which the system is to be developed for
multiple locations and user organizations. Installation on multiple sites
is required.
F14: Facilitate Change: the degree to which the system has been designed
for easy maintenance, enhancement and flexibility.
Weight for design impact: 0..5
0 = no influence (not present)
1 = incidental influence
2 = moderate influence
3 = nominal influence
4 = significant influence
5 = very large influence
Feb. 27, 2007
(c) Dr. David A. Workman
21
SLOC to Function Points
Feb. 27, 2007
Language
LOC per FP
Assembly Language
320
C
128
COBOL
105
Fortran
105
Pascal
90
Ada95
53
Visual Basic
32
Prolog, Lisp, Forth
65?
OOPL
30?
(Java)
45-55?
(C++)
64
(SmallTalk)
22
4GL
20?
Lex, Yacc
15?
PowerBuilder
16
Spreadsheets
6?
GUI
4?
Estimating Software Costs
by Capers Jones, McGraw-Hill, 1998.
? Numbers have not been validated
(c) Dr. David A. Workman
22
SLOC to Function Points
Cocomo II Model Definition Manual
By Barry Boehm et a., 1999.
Feb. 27, 2007
(c) Dr. David A. Workman
23
Function Points: Example
FP
Category
EI
Low
Medium
High
3 x3
6 x4
0 x6
Row
UFP
33
EO
0 x4
0 x5
1 x7
7
EQ
0 x3
3 x4
0 x6
12
ILF
3 x7
0 x10
0 x15
21
EIF
1 x5
0 x7
0 x10
5
Total Unadjustd FP = 78
Factor
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
F13
F14
Value
4
0
3
2
3
5
4
3
1
0
0
3
1
2
FP = UFP 0.65+ 0.01  Fi  = 78 (0.65+ 0.31)
FP = 74
LOC = 74  30 = 2, 220.
NOTES:
Data and Transaction counts are in red, weights in blue.
Complexity weights = see slide 8
Value adjustment factors (Fi) = (see slide 17 - 19)
LOC to FP conversion = (see slide 20)
Feb. 27, 2007
(c) Dr. David A. Workman
24
Extensions to Function Point Methods
•
•
Feature Points (Jones 1991)
"Feature Points" are a super set of Function Points. Special
"Algorithms" are added to the list of features counted.
BOEING (3D Function Points)(Whitmire 1995)
– Data Dimension
– Function Dimension
– Control Dimension
Feb. 27, 2007
(c) Dr. David A. Workman
25
COCOMO
•
Basic Formulas (LM = labor months; DT = development time in months)
Organic: Small number of experienced developers who are familiar with both the
application area and the development environment. Product size varies from
small to medium.
LM  2.4(KSLOC)1.05
DT  2.5(LM)0.38
Semi-detached: Lies between Organic and Embedded in its demand on resources
and development process. Assumes the development team is a mix of experienced
and inexperienced personnel with little experience working together. Product
size varies from medium to very large.
LM  3.0(KSLOC)1.12
DT  2.5(LM)0.35
Embedded: Requires the most resources. Has stringent requirements on reliability,
performance, schedule, external interfaces, and timing. Employs a development
process with frequent reviews and rigid test requirements. Product size varies
from medium to large.
LM  3.6(KSLOC)1.2
Feb. 27, 2007
DT  2.5(LM)0.32
(c) Dr. David A. Workman
26
COCOMO
•
Each cost driver defines a
multiplicative coefficient to the
value of LM defined by the
basic models. Call LM' the
resulting adjusted labor months.
Cost Drivers
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
RELY: effect of software reliability
DATA: effect of database size
CPLX: effect of software complexity
TIME: effect of execution time constraints
STOR: effect of constraints on main storage
VIRT: effect of virtual machine volatility (environment stability)
TURN: obsolete (choose 1.0)
ACAP: effect of analyst's capabilities
AEXP: effect of team's experience
PCAP: effect of programmer's capabilities
VEXP: effect of team experience with development/target environment
LEXP: effect of programmer's experience with programming language
MODP: effect of using modern development methods on team
TOOL: effect of using advanced development tools on team
SCED: effect of schedule constraints


LM'   CDi   LM, whereCDi  i th Cost Driverfactor See table on next slide
 i

Feb. 27, 2007
(c) Dr. David A. Workman
27
COCOMO
Attribute
Weighting Factor
Very
Low
Low
Nominal
High
Very High
0.75
0.88
1.0
1.15
1.4
0.94
1.0
1.08
1.16
0.85
1.0
1.15
1.3
1.65
Computer
Related
4: TIME
1.0
1.11
1.3
1.66
5: STOR
1.0
1.06
1.21
1.56
0.87
1.0
1.15
1.3
1.46
1.19
1.0
0.86
0.71
8: AEXP
9: PCAP
10: VEXP
11: LEXP
Project
Related
12: MODP
13: TOOL
1.29
1.42
1.21
1.14
1.13
1.17
1.10
1.07
1.0
1.0
1.0
1.0
0.91
0.86
0.90
0.95
0.82
0.70
1.24
1.24
1.10
1.10
1.0
1.0
0.91
0.91
0.82
0.83
14: SCED
1.23
1.08
1.0
1.04
1.10
Product
Related
1: RELY
2: DATA
3: CPLX
6: VIRT
Personnel
Related
7: ACAP
Feb. 27, 2007
0.7
(c) Dr. David A. Workman
Extra
High
28
COCOMO II Formulas
 n

PM estimated    EM i   A  ( Size) B  Reeng
 i

A  2.94 (Lat estcalibrat edvalue)
B  0.91 0.01  Wk , where Wk  {P REC, FLEX,RESL, T EAM,P MAT}
k
SLOC
ESLOC
(Reeng  0) or
(Reeng  0)
1000
1000
n  7 for Early Model
EMi  {RCP X,RUSE, P DIF,P ERS, P REX,FCIL,SCED}
Size 
 17 for P ost - Archit ect ure Model
EMi  {RELY,DAT A,CP LX,DOCU, RUSE, T IME,ST OR, P VOL,

ACAP ,P CAP ,P CON,AEXP ,P EXP ,LT EX,T OOL,SIT E,SCED}
TDev  3.67  P M
Feb. 27, 2007
0.28  0.2( B 1.01)

  SCED
 , where P M is P M
100 
wit hout SCED.
estimated
(c) Dr. David A. Workman
29
COCOMO II Formulas
With REUSE
ASLOCAA  AAF1.0  0.02 SU  UNFM 
, AAF  0.5
100
ASLOCAA  AAF  SU  UNFM 
, AAF  0.5
ESLOC 
100
AAF  0.4  DM  0.3  CM  0.3  IM
ESLOC 
ASLOC = Adjusted SLOC ( SLOC modified legacy)
AA
= Assessment Assimilation Increment (degree of effort needed to determine whether
a full-reused module is appropriate and to integrate its description into the overall product.
DM
= Percentage of the original design that must be modified to accommodate the new requirements.
CM
= Percentage of the original code that must be modified to accommodate the new software and
its environment.
IM
= Percentage of Integration required for modified software in comparison to normal amount
required for integration and test of software of comparable size.
SU
= Software Understanding Increment (penalty)
UNFM = Programmer Unfamiliarity Increment.
Feb. 27, 2007
(c) Dr. David A. Workman
30
COCOMO II Formulas
With REUSE (continued)
Feb. 27, 2007
(c) Dr. David A. Workman
31
COCOMO II Formulas
With REUSE (continued)
Feb. 27, 2007
(c) Dr. David A. Workman
32
COCOMO II Formulas
With REUSE (continued)
Reeng =
Feb. 27, 2007
(c) Dr. David A. Workman
33
Sizing Procedure A
1: As a team, apply the Brooks rule using current time expended on the project
assuming we are half-way through the "design" phase.
“My rule of thumb is 1/3 of the schedule for design, 1/6 for coding, 1/4 for component
testing, and 1/4 for system testing.”
2. Apply Schach Pi-Chart
3. Compute Function Point estimations of SLOC and Effort using COCOMO-II

(a) Individually compute SLOC and Effort

(b) As a team arrive at SLOC and Effort

(c) Use a weighted average of Low, High, Average of (a) & (b)
4. Compute SLOC by sizing components individually and Effort using
COCOMO-II or some other productivity factor.

(a) Individually compute SLOC and Effort

(b) As a team arrive at SLOC and Effort

(c) Use a weighted average of Low, High, Average of (a) & (b)
5. Compute a weighted average of 1 - 4
Feb. 27, 2007
(c) Dr. David A. Workman
34
Sizing Procedure B
See Notes
For more
details
1. Apply Schach Pi-Chart to estimate:
• (a) Effort to complete
• (b) Calendar time to complete (using your averages team hrs/week)
2. Compute SLOC by Module breakdown analysis.

(a) Count Classes to Develop/Modify – Boundary, Entity, Control

(b) Size each Class in (a) by counting methods to develop/modify

(c) Size each method (using high, medium, low) and assign SLOC count to
each size category.

(d) Convert SLOC to hours, and hours to work weeks using your
performance data.
3. Apply the OO Function Point Analysis to Completed Code!
Use the FP methodology on your delivered implementation to arrive at
actual FP and then compute the SLOC/FP ratio for the
implementation language you used.
Feb. 27, 2007
(c) Dr. David A. Workman
35
Sizing Data for Java Classes
Size Categories
<= 10
11 <= 30
> 30
Totals
139
37
22
198
5
18.78
66.82
70.20
18.69
11.11
#Bndry
78
27
11
Ave Size Bndry
5
18.33
55.91
%Bndry
67.24
23.28
9.48
#Entity
56
10
11
Ave Size Entity
5
20.00
77.73
72.73
12.99
14.29
#All
Ave Size ALL
%All
%Entity
Feb. 27, 2007
(c) Dr. David A. Workman
116
77
36