COCOMO and CMM

1. Case Study
Presented by:
Prakash Poudel
Poudelprakash25@gmail.com

2. COCOMO Cost Estimation
Model
 It stand for Constructive Cost Model.
 COCOMO (Constructive Cost Model) is a cost estimation
model.
 COCOMO was developed by Barry Boehm.
 It applies on three classes of Software Project:
-Organic Projects
-Semi-Detach
-Embedded project

3.  Organic
- 2-50KLOC
- Small team
- Good Experience Developers
- Less rigid requirement
- Not tight Deadline
- Example: Payroll, Inventory System
 Semi-detached
- 50-300KLOC
- Medium team with mixed experience Developers
- Mixed rigidness
- Medium Deadline
- Example : Database System
 Embedded
- over 300KLOC
- Large Project
- Real time System
- Combination of organic and semi detached models
- Example : ATM, Air traffic control

5. Stages of COCOMO

6. BASIC COCOMO
 Approximate estimate of project parameters
 Software development effort is estimated
using Line of Code(LOC)
 Rough calculation of software cost

7. Formula of Basic COCOMO
 Effort applied(E) = ab(KLOC)bb
 Development Time(D) = cb(E)db
 People required(P) = E/D
Here a, b, c, d are the constraint.

8. Basic COCOMO Co-efficient

9. Intermediate
COCOMO
 Extension of Basic Cocomo
 Refines estimate obtained by Basic
Cocomo
 Improves the basic cocomo

10. Classification of Cost Drivers and their
attributes:
(i) Product attributes
 Size of the application database
 Required software reliability extent
 The complexity of the product
(ii) Hardware attributes
 Run-time performance constraints
 Memory constraints
 The volatility of the virtual machine
environment
 Required turnabout time

11. (iii) Personnel attributes
 Analyst capability
 Software engineering capability
 Applications experience
 Virtual machine experience
 Programming language experience
(iv) Project attributes
 Application of software engineering methods
 Use of software tools
 Required development schedule

12. Formula of Intermediate COCOMO
 Effort applied(E) = ai(KLOC)bi * (EAF)
 Development Time(D) = Ci(E)dd
 People required(P) = E/D
Here a, b, c, d are the constraint.
EAF stands for Effort Adjustment Factors
Typical values for EAF range from 0.9 to 1.4
There are 15 EAF in Intermediate Cocomo.

13. DETAILED COCOMO
 It is used for large sized projects.
 The cost drivers depend upon
requirements, analysis, design, testing
and maintenance.
 Team size is large.
 It refines Intermediate Cocomo.

14. The Six phases of detailed COCOMO
Are:
 Planning and requirements
 System design
 Detailed design
 Module code and test
 Integration and test
 Cost Constructive model

15. Each cost driver is broken down by phases
as in the example shown in table.
 Estimates for each module are combined into
subsystems and eventually an overall project estimate.
 Using the detailed cost drivers, an estimate is
determined for each phase of the lifecycle

16.  The Detailed COCOMO equations take
the form
E = ai (KLOC)bi * EAF
D = ci (E)di
Ep = µp*E
Dp = p*D
SS = E/D persons
P = KLOC/E

17. Example case
Consider a project to develop a full screen
editor. The major components identified are (1)
Screen edit, (2) Command Language
Interpreter, (3) File input and output, (4) Cursor
movement and (5) Screen movement. The
sizes for these are estimated to be 4K, 2K, 1K,
2K and 3K delivered source code lines. Use
COCOMO model to determine:
 Overall cost and schedule estimates
(assume values for different cost drivers,
with at least three of them being different
from 1.0).

18. Solution Size of 5 modules are
Screen edit = 4KLOC
Command Language Interpreter = 2KLOC File input
and output = 1KLOC
Cursor movement and = 2KLOC
Screen movement = 3KLOC
Total = 12KLOC
Let us assume that significant cost drivers are :
 Required software reliability is high i.e. 1.15
 Product complexity is high i.e. 1.15
 Analyst capability is high i.e. 0.86
 All other drivers are nominal i.e. 1.00
Hence
EAF = 1.15 * 1.15 * 0.86 = 1.1373

19. The initial effort estimate for the project
E = ai (KLOC)bi * EAF
=3.2(12)1.05 * 1.1373
= 49.449 PM (person-month)
D = ci (E)di
= 2.5(49.44)0.38
= 11.007 M(month)
Total person = E/D
= 44.449/11.007
= 4.038
That is total person = 4

20. CCPDS-R Case Study…..
Command center processing and display
system-replacement [CCPSS-R] project
was performed for the U.S. Air force by
technical review workgroup (TRW) space
and defense in Redondo Beach,
California. The entire project included
system engineering, hardware
procurement, and software development,
with each of these three major activities
consuming about one-third of the total
cost.

21. Key Points of CCPDS-R
 An objective case study is a true
indicator of a mature organization and a
mature project process. The software
industry needs more case studies like
CCPDS-R
 CCPDS-R was one of the pioneering
projects that practiced many modern
management approaches.

22. Usage areas of interest where
CCPDS-R mostly used:
Army
Defense
Intelligence
Ministry of defense
Force
Space
Discovery
Study

23. Software acquisitions
process:-
 Competitive Design phase [CD] Phase
 Full-scale Development phase[FSD]
Phase

24. Competitive Design phase [CD]
Phase
This Concept Definition Phase included following
activities:
• Analyze and specify the project requirements
• Define and develop the top-level architecture
• Plan FSD phase software development activities
• Configure the process and development
environment
• Establish trust and win-win relationships among
the stakeholder

25. Full-scale Development phase[FSD]
Phase
i. Software requirements review (SRR)
-Initial feasibility of the foundation components
-Basic use cases of Initialization
ii. Interim preliminary design review (IPDR)
-Feasibility of the architectural infrastructure under
riskiest use cases
iii. Preliminary design review (PDR)
-Adequate achievement of the peak load scenarios
iv. Critical design review (CDR)
-Update of the architectural baseline for test capability
of whole system

26. Project Organization &
Responsibilities
 Analyze and specify the project requirement
 Define and develop the top-level architecture
 Plan the FSD phase software development
activities
 Configure the process and development
environment
 Establish trust and win –win relationships
among the stakeholders.

27. CCPDS-R Life cycle
Overview

28. THE INCREMENTAL DESIGN
PROCESS
Well Defined sequence of walkthroughs took place:
i. Preliminary design walkthrough(PDW)
-Initial Prototyping and Design Work
ii. Critical design walkthrough(CDW)
- Build’s Design Work
iii. Code walkthrough(CW)
-Detailed Code Walkthrough
iv. Turnover review(TR)
-A one month activity including SAT, BIT ,
EST

29. The Incremental Test Process
i. Stand-alone test
-Corresponds to completeness and boundary condition
tests to the possible extent
ii. Build integration test
-To ensure previously demonstrated capabilities still
operated as expected
iii. Reliability test
-Help uncover potentially insipid, transient errors of major design
consequence
iv. Engineering string test
-Verifying specific subsets of requirements through demonstration
v. Final qualification test
-Represented a set of requirements which could not be verifying until whole system was present
Ex: a 50% reserve capacity requirement could not be verified until FQT, when whole system
was operational

30. Metrics
• Development Progress (% coded) vs time
• Requirements verified vs time
• Average hours per software change order (SCO)
• Cost/Effort Expenditure By Activity
• Mean time between failure (MTBF) vs total test
hours
• Cumulative SLOC vs budget

31. People Factors
• Core team concept
• Leverage skills of a few experts across the entire
team
• Avoid attrition
• Profit sharing of award fees

32. Introduction
 CMM was developed by the Software Engineering Institute
(SEI) at Carnegie Mellon University in 1987.
 It is a framework which is used to analyze the approach and
techniques followed by any organization to develop software
product.
 It also provides guidelines to further enhance the maturity of
those software products.
 5 different levels.
Capability Maturity Model

33. Five Levels
1. Level 1 – Initial
2. Level 2 – Repeatable
3. Level 3 – Defined
4. Level 4 – Managed
5. Level 5 - Optimized

35. Level-1: Initial
 Processes followed are immature and
are not well defined.
 No basis for predicting product quality,
time for completion, etc.
 No KPA’s defined.

36. Level-2: Repeatable
 Least documented and repeating same steps again and again.
 Experience with earlier projects is used for managing new similar natured projects.
KPA’s:
 Project Planning- It includes defining resources required, goals, constraints, etc. for the
project. It presents a detailed plan to be followed systematically for successful completion
of a good quality software.
 Configuration Management- The focus is on maintaining the performance of the software
product, including all its components, for the entire lifecycle.
 Requirements Management- It includes the management of customer reviews and
feedback which result in some changes in the requirement set.
 Subcontract Management- It focuses on the effective management of qualified software
contractors i.e. it manages the parts of the software which are developed by third parties.
 Software Quality Assurance- It guarantees a good quality software product by following
certain rules and quality standard guidelines while development.

37. Level-3: Defined
 At this level, documentation of the standard guidelines and
procedures takes place.
 Process are well defined and confirmed.
KPA’s:
 Peer Reviews- In this method, defects are removed by using a
number of review methods like demonstration, survey, etc.
 Intergroup Coordination- It consists of planned interactions
between different development teams to ensure efficient and
proper fulfillment of customer needs.
 Organization Process Definition- It’s key focus is on the
development and maintenance of the standard development
processes.
 Organization Process Focus- It includes activities and practices
that should be followed to improve the process capabilities of an
organization.
 Training Programs- It focuses on the enhancement of knowledge
and skills of the team members including the developers and
ensuring an increase in work efficiency.

38. Level-4: Managed
 At this stage, quantitative quality goals are set for
the organization for software products as well as
software processes.
KPA’s:
 Software Quality Management- It includes the
establishment of plans and strategies to develop a
quantitative analysis and understanding of the
product’s quality.
 Quantitative Management- It focuses on controlling
the project performance in a quantitative manner.

39. Level-5: Optimizing
 This is the highest level of process maturity in CMM and focuses on
continuous process improvement in the organization using quantitative
feedback.
 Use of new tools, techniques and evaluation of software processes is done to
prevent recurrence of known defects.
KPA’s:
 Process Change Management- Its focus is on the continuous improvement
of organization’s software processes to improve productivity, quality and
cycle time for the software product.
 Technology Change Management- It consists of identification and use of new
technologies to improve product quality and decrease the product
development time.
 Defect Prevention- It focuses on identification of causes of defects and to
prevent them from recurring in future projects by improving project defined
process.

41. Thank You!!