1. COCOMO and Function Point Analysis
Software Engineering
Lecture 07
COCOMO and Function Point Analysis
Prof. Dr. Ir. Riri Fitri Sari MM MSc
18 November 2011
Faculty of Engineering
University of Indonesia

2. Software Engineering Roadmap: Chapter 2 Focus
Management structure
- hierarchical, peer,...
Risk identification
& retirement
SPMP
Schedule
Development
process
- when to do what phase
- document: SPMP
Corporate
practices
Cost estimate
Plan
project
Development
phases
Analyze
requirements
Maintain
Integrate
& test system
Design
Implement
Test units
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

3. Software Engineering Roadmap: Chapter 2 Focus
Corporate
practices
Plan
project
Analyze
requirements
Maintain
Integrate
& test system
Design
Implement
Test units
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

4. 8. Estimating costs: early calculations

5. Range of Errors in Estimating Eventual Cost$4
Range of cost estimates after conceptualization phase, based on actual cost of $1
Conceptual-
ization
phase $1
Range of cost estimates after requirements analysis phase
25c
Requirements
analysis $1
Range of Errors in Estimating Eventual Cost
Design $1
Implementation $1
Integration/Test $1
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

6. Typical Cost Estimation Roadmap
1A. Use comparisons with past jobs to estimate cost & duration directly or to estimate lines of code.
and / or
1B. Use function point method to estimate lines of code
1B.1 Compute un-adjusted function points.
1B.2 Apply adjustment process.
2. Use lines of code estimates to compute labor and duration using COCOMO formulas.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

7. Function Point Computation for a Single Function (IFPUG)
External Inquiries (EIN)
Internal Logical Files (ILF)*
Function
Logical
group of
user data
Logical
group of
user data
Logical
group of
user data
External Outputs (EO)
External Inputs (EI)
External Logical Files (ELF)
file
file
* Internal logical grouping of user data into files
file

8. Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process)
PARAMETER simple complex
Ext. inputs EI … or… 4 or = ___
Ext. outputs EO … or … 5 or = ___
countTotal

9. Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process)
PARAMETER simple complex
Ext. inputs EI … or… 4 or = ___
Ext. outputs EO … or … 5 or = ___
Ext. inquiries EIN … or … 4 or = ___
Int. logical files ILF or …10 or = ___
Ext. logical files ELF or …7 or = ___
countTotal

10. Unadjusted Function Point Computation for First Encounter Functions:“Set up Player Character”
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

11. Unadjusted Function Point Computation for Second Encounter Functions: “Encounter Foreign Character”
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

12. General Characteristics for FP Adjustment 1-7
incidental average essential 1 2 3 4 5
Case
study
none moderate significant
1. Requires backup/recovery?
2. Data communications required? 0-1
3. Distributed processing functions? 0

13. General Characteristics for FP Adjustment 1-7
incidental average essential 1 2 3 4 5
Case
study
none moderate significant
1. Requires backup/recovery?
2. Data communications required? 0-1
3. Distributed processing functions? 0
4. Performance critical?
5. Run on existing heavily utilized environmt.? 0-1
6. Requires on-line data entry?
7. Multiple screens for input? continued 4-5

14. General Characteristics for FP Adjustment 8-14
incidental average essential 1 2 3 4 5
Case
study
none moderate significant
8. Master fields updated on-line? 3-4
9. Inputs, outputs, inquiries of files complex? 1-2
10. Internal processing complex?

15. General Characteristics for FP Adjustment 8-14
incidental average essential 1 2 3 4 5
Case
study
none moderate significant
8. Master fields updated on-line? 3-4
9. Inputs, outputs, inquiries of files complex? 1-2
10. Internal processing complex? 1-3
11. Code designed for re-use?
12. Conversion and installation included? 0-2
13. Multiple installation in different orgs.? 1-3
14. Must facilitate change & ease-of-use
by user?

16. Computation of Adjusted Function Points (IFPUG)
[ Unadjusted function points ] r
[ r ( total general characteristics ) ]

17. Unadjusted Function Point Scores for Video Store Example
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

18. FP Adjustment Factors for Video Example
none incidental moderate average significant essential 1 2 3 4 5
1. Requires backup/recovery?…………………………. 4
2. Data communications required ?………...…………. 0
3. Distributed processing functions ?…………………. 0
4. Performance critical ?………………….……………. 3
5. Run on existing heavily utilized environment ?……. 1
6. Requires on-line data entry ?………………………

19. FP Adjustment Factors for Video Example
none incidental moderate average significant essential 1 2 3 4 5
1. Requires backup/recovery?…………………………. 4
2. Data communications required ?………...…………. 0
3. Distributed processing functions ?…………………. 0
4. Performance critical ?………………….……………. 3
5. Run on existing heavily utilized environment ?……. 1
6. Requires on-line data entry ?……………………….. 5
7. Multiple screens for input ?…………………………. 3
8. Master fields updated on-line ?…………………….. 5
9. Inputs, outputs, inquiries of files complex ?……….. 2
10. Internal processing complex ?………………………. 1
11. Code designed for re-use ?…………………………... 3
12. Conversion and installation included ?…………….. 3
13. Multiple installation in different orgs. ?……………. 3
14. Must facilitate change & ease-of-use by user ?…….. 2
Total 35

20. 9. Estimating effort and duration from lines of code

21. Meaning of the COCOMO Formulas (Boehm)
(1) Effort* for
increasing LOC
( y b 3x 1.12 )
(2) Duration for
increasing Effort*
( y b 2.5x 0.35 )
< 1
exponent:
> 1
Applies to design through integration & test.
*“Effort” = total person-months required.

22. Basic COCOMO Formulae (Boehm)
Effort in Person-months
= aKLOC b
Duration = c Effort d
Software Project a b c d
Organic
Semidetached
Embedded
Due to Boehm [Bo]

23. Computing COCOMO Case Study Models
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

24. Computing COCOMO Case Study Models
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

25. Estimate Cost and Duration Very Early in Project
One way to ...
Estimate Cost and Duration Very Early in Project
1. Use the function point method to estimate lines of code
2. Use Boehm’s formulas to estimate labor required
3. Use the labor estimate and Boehm’s formula to estimate duration
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

26. 10. The Team Software Process

27. TSP Launch Issues to Settle (Humphrey)
Process to be used
Quality goals
Manner of tracking quality goals
How team will make decisions
What to do if quality goals not attained
fallback positions
What to do if plan not approved
Define team roles
Assign team roles
TSP Launch Issues to Settle (Humphrey)
Graphics reproduced with permission from Corel.

28. To Be Produced at Launches (Humphrey)
1. Written team goals
2. Defined team roles
3. Process development plan
4. Quality plan
5. Project’s support plan
computers, software, personnel etc.
6. Overall development plan and schedule
7. Detailed plans for each engineer
8. Project risk assessment
9. Project status report

29. TSPi Cycle Structure (Humphrey)1 1 1 1 1 1
Week 1 2 3 4 5 6 7 8 9 1 2 3 4 5
Cycle 1 launch
Delivery
Milestones
Cycle 2 launch
Cycle 3 launch
1. strategy
2. plan
3. requirements
4. design
5. implementation
6. test
7. postmortem
Iteration 1
Iteration 2
1. strat.
1. strategy….
Iteration 3
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

30. 11. The Software Project Management Plan

31. IEEE 1058.1-1987 SPMP Table of Contents
1. Introduction
1.1 Project overview
1.2 Project deliverables
1.3 Evolution of the SPMP
1.4 Reference materials
1.5 Definitions and acronyms 2. Project organization
2.1 Process model
2.2 Organizational structure
2.3 Organizational boundaries
and interfaces
2.4 Project responsibilities
3. Managerial process
3.1 Managerial objectives &
priorities
IEEE SPMP Table of Contents

32. IEEE 1058.1-1987 SPMP Table of Contents
3.2 Assumptions, dependencies
& constraints
3.3 Risk management
3.4 Monitoring & controlling
mechanisms
3.5 Staffing plan
4. Technical process
4.1 Methods, tools & techniques
4.2 Software documentation
4.3 Project support functions
5. Work packages, schedule &
budget
5.1 Work packages
5.2 Dependencies
5.3 Resource requirements
5.4 Budget & resource allocation
5.5 Schedule
1. Introduction
1.1 Project overview
1.2 Project deliverables
1.3 Evolution of the SPMP
1.4 Reference materials
1.5 Definitions and acronyms 2. Project organization
2.1 Process model
2.2 Organizational structure
2.3 Organizational boundaries
and interfaces
2.4 Project responsibilities
3. Managerial process
3.1 Managerial objectives &
priorities

33. 12. Quality in project management

34. Table 2.5 Defects by Phase
Defects detected per requirements, or ... design diagram, or ... KLOC
This project / norm
Phase in which defects detected
Detailed require-ments
Design
Implemen- tation
Phase containing defects
Detailed requirements
2 / 5
0.5 / 1.5
0.1 / 0.3
3 / 1
1 / 3
Implementa-tion
2 / 2
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

35. Five Process Metric Examples
Compare each of the following with company norms averaged over similar processes.
1. Number of defects per KLOC detected within x weeks of delivery
2. Variance in schedule on each phase
actual duration - projected duration projected duration
3. Variance in cost actual cost - projected cost
projected cost
4. Total design time / total programming time
should be at least 50% (Humphry)
5. Defect injection and detection rates per phase
e.g. “1 defect per class in detailed design phase”
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

36. IEEE 739-1989 Software Quality Assurance Plans Table of Contents Part 2 of 2
7. Test
-- can reference Software Test Documentation
8. Problem reporting & corrective action
9. Tools, techniques and methodologies
-- can reference SPMP
10. Code control
-- reference SCMP
11. Media control
12. Supplier control
13. Records collection, maintenance & retention
14. Training
15. Risk Management

37. Gather Process Metrics
One way to ...
Gather Process Metrics
1. Identify & define metrics team will use by phase; include ... time spent on 1. research, 2. execution, 3. review
… size (e.g. lines of code)
… # defects detected per unit (e.g., lines of code)
include source
… quality self-assessment of each on scale of 1-10
maintain bell-shaped distribution
2. Document these in the SQAP
3. Accumulate historical data by phase
4. Decide where the metric data will be placed
as the project progresses SQAP? SPMP? Appendix?
5. Designate engineers to manage collection by phase
QA leader or phase leaders (e.g., design leader)
6. Schedule reviews of data for lessons learned
Specify when and how to feed back improvement
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

38. Requirements Document: 200 detailed requirements
Meeting
Research
Execution
Personal Review
Inspection
Hours spent
0.5 x 4 4 5 3 6
% of total time
10%
20%
25%
15%
30%
% of total time: norm for the organization
Self-assessed quality 1-10 2 8
Defects per 100
N/A
Defects per 100: organization norm
Hours spent per detailed requirement
0.01
0.02
0.025
0.015
0.03
Hours spent per detailed requirement: organization norm
0.04
Process improvement
Improve strawman brought to meeting
Spend 10% more time executing
Summary
Productivity: 200/22 = 9.9 detailed requirements per hour
Probable remaining defect rate: 6/4´[organizational norm of 0.8 per hundred] = 1.2 per 100
Table 2.6 Project Metric Collection for phases
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

39. 13. Process improvement and the Capability Maturity Model

40. Table 2.7 Example of Process Comparison
Motor control applications
Process
Waterfall
Spiral, 2-4 iterations
Spiral, 5-10 iterations
Company average -- Defects per thousand source lines of code at delivery time injected at ...
... requirements time
4.2
3.2
2.4
... architecture time
3.1
2.5
3.7
... detailed design time
1.1
2.2
... implementation time
1.0
2.1
3.5
TOTAL
9.4
8.9
11.8
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

41. Feed Back Process/Project Improvement
One way to ...
1. Decompose the process or sub-process being measured into Preparation, Execution and Review
include Research if learning about the procedure
2. Note time taken, assess degree of quality for each part on a 1-10 scale, count defects
try to enforce a curve
3. Compute quality / (percent time taken)
4. Compare team’s performance against existing data, if available
5. Use data to improve next sub-process
note poorest values first e.g., low quality/(percent time)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

42. For each part ... Preparation Execution Review Typical? Action
For each part ...
Preparation
Execution
Review
% time 45 30 25
Quality (0 to 10)*
If low, investigate 6 2
investigate
Quality/(% time)
0.13
0.07
0.24
Typical? No
Joe lost specs
Yes
Action
Schedule 20% more time for execution, taken equally from other phases
Table 2.8 Measuring Team Phase Performance
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

43. 14. Miscellaneous tools and techniques for project management Model

44. Remote Team Options Same office area Same city, different offices
+ ideal for group communication
- labor rates sub-optimal
Same city, different offices
communication fair
Same country, different cities
- communication difficult
+ common culture
Multi-country
- communication most difficult
- culture issues problematical
+ labor rates optimal
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Graphics reproduced with permission from Corel.

45. Non-Extreme vs Extreme Programming
Limited customer contact
Central up-front design
Build for the future too
Complex implementation
Tasks assigned
Developers in isolation
Infrequent integration
Limited communication
Customer on team
Open evolving design
Evolve; just in time
Radical simplicity
Tasks self-chosen
Pair programming
Continuous integration
Continual communication
Adapted from Andserson, A., et al, "At Chrysler, Objects Pay", Distributed Computing, October 1998

46. Triage in Project Management
Among top items in importance?
if so, place it in do at once category
otherwise Could we ignore without substantially affecting project?
if so, place it in last to do category
otherwise ……
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

47. Triage in Project Management
Among top items in importance?
if so, place it in do at once category
otherwise Could we ignore without substantially affecting project?
if so, place it in last to do category
otherwise (do not spend decision time on this)
place in middle category
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

48. 16. Summary of the project management process

49. Summary Project management: “silver bullet”?
“People” aspects co-equal technical
Specify SPMP
Define and retire risks
Estimate costs with several methods
expect to revisit and refine
use ranges at this stage
Schedule project with appropriate detail
Maintain a balance among cost, schedule, quality and functionality
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Graphics reproduced with permission from Corel.

50. SPMP for the Encounter video game

51. Gaming Industries Consolidated
President
Gaming Industries Consolidated
IV&V
. . .
VP Marketing
VP Engineering
Software
Engineering
Labs
. . .
Game Lab
. . .
Game 123
Encounter
SQA
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

52. Table 2.9 Encounter Project Responsibilities
Member
Team leader
CM Leader QA
leader
Require-ments management leader
Design leader
Implementation Leader
Liaison
Respon-sibility
VP Engineering
Marketing
Software engineering lab
Document Responsi-bility
SPMP
SCMP
SQAP
STP
SRS
SDD
Code base
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

53. Program Monitoring & Control
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

54. Table 2.11 Encounter Staffing Plan
Name
Team Leader
CM Leader. QA
Leader
Requ. Mngmnt Leader
Design Leader
Implemen- tation Leader
Ed Braun X
Al Pruitt
Fern Tryfill
Hal Furnass
Karen Peters
Liaison with
VP Eng.
Marketing
Soft. Eng. Lab
Table 2.11 Encounter Staffing Plan
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

55. Work Breakdown Structure Excluding Secretarial
Month 1
Month 2
Month 3
Month 4
Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
SCMP
Complete testing
Milestones
SQAP
Freeze requirements
Delivery
SPMP rel. 1
Iteration 1
Tasks
Risk I&R
Iteration 2
E. Braude
J. Pruitt
F. Tryfill
H. Furnass
K. Peters
F. Smith (tech support)
TOTAL
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

56. Method*
Mini-mum
Maxi-mum
Comment
(1)
7.5**
170
(2)
4.2
300
(3)
11.4 46
for two identified functions ´ 6-20 times as many in complete application
Most conservative
Maximum of minimums and maximum of maximums.
Least conservative
Minimum of minimums and minimum of maximums.
Widest range
Minimum of minimums and maximum of maximums.
Narrowest range
Maximum of minimums and minimum of maximums.
Table 2.12 Very Rough Estimate of Application Size Prior to Requirements Analysis
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

57. High Level Task Chart with Fixed Delivery Date: Order of Completion
Month 1
Month 2
Month 3
Month 4
Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
SCMP complete
Begin system testing
(2)
SQAP complete
Milestones
(1*) Delivery
SPMP rel. 1 complete
(3) Freeze requirements
(4)
Iteration 1
(6)
Iteration 2
Risk identification & retirement
(5)
Prep. for maintenance
* Indicated the order in which the parts of this table were built
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

58. Software quality assurance plan Part 2 of 2

59. Problem Reporting Form
1. Defect Number: Proposer: Documents / sections affected:__________ Source code affected*: 4. package(s)_______ class(es) ____6. method(s) ______ Severity: ____8. Type: _____
9. Phase injected**: Req Arch  Dtld.Dsg  Code  Int 
10. Detailed description: ___________________ Resolution: ____ 12. Status closed / open:__ Sign-off: 13. Description and plan inspected: __ Resolution code and test plan inspected: ___ Change approved for incorporation: ______
Problem Reporting Form
* for source code defects **earliest phase with the defect
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.