CSC309 Lecture 19

jgs
CSC 309
Software Engineering II
Lecture 19:
COCOMO
Dr. Javier Gonzalez-Sanchez
[email protected]
www.javiergs.com
Building 14 -227
Office Hours: By appointment

View Slide

jgs
Constructive Cost Model
Cocomo

View Slide

jgs
Javier Gonzalez-Sanchez | CSC 309 | Winter 2023 | 3
Regression-Based Model

View Slide

jgs
§ The constructive cost model was developed by Barry Boehm (the Spiral
model guy) in the late 1970 and published in Software Engineering
Economics.
§ It is a model for estimating effort, cost, and schedule for software projects.
§ It drew on a study of 63 projects at TRW Aerospace.
§ The study examined projects ranging in size from 2,000 to 100,000 lines of
code and diverse programming languages.
§ These projects were based on the waterfall model of software development
(prevalent in 1981).
COCOMO

View Slide

jgs
COCOMO II

View Slide

jgs
COCOMO II Web Tool by USC
http://softwarecost.org/tools/COCOMO/

View Slide

jgs
1. Software Size (Lines of Code)
2. Software Scale Drivers: sources of exponential effort variation
3. Software Cost Drivers: sources of linear effort variation. They group in 4
categories: product, platform, personnel and project
Factor are rated between very low and very high per rating guidelines
Factors of development cost

View Slide

jgs
COCOMO II - Inputs

View Slide

jgs
Scale Drivers Rating
Scale Factors (Wi) Very Low Low Nominal High Very High Extra High
Precedentedness
(PREC)
thoroughly
unprecedented
largely
unprecedented
somewhat
unprecedented
generally
familiar
largely
familiar
throughly
familiar
Development
Flexibility (FLEX)
rigorous occasional
relaxation
some
relaxation
general
conformity
some
conformity
general
goals
Architecture/Risk
Resolution (RESL)*
little (20%) some (40%) often (60%) generally
(75%)
mostly
(90%)
full (100%)
Team Cohesion
(TEAM)
very difficult
interactions
some difficult
interactions
basically
cooperative
interactions
largely
cooperative
highly
cooperative
seamless
interactions
Process Maturity
(PMAT)
Weighted average of “Yes” answers to CMM Maturity Questionnaire
* % significant module interfaces specified, % significant risks eliminated

View Slide

jgs
COCOMO II - Inputs

View Slide

jgs
1.1. Required Reliability (RELY)
1. 2. Data Base Size (DATA)
1. 3. Complexity (CPLX)
1. 4. Developed for Reusability (RUSE)
1. 5. Documentation (DOCU)
Cost Drivers | Product Factors

View Slide

jgs
2.1 Analyst capability (ACAP)
2.2 Programmer (Software Engineer) capability (PCAP)
2.3. Applications experience (APEX)
2.4. Platform (or VM) experience (PLEX)
2.5. Language and tool experience (LTEX)
2.6. Personnel continuity (PCON)
Cost Drivers | Personnel factors

View Slide

jgs
3.1. Time constraint (TIME)
3.2. Storage constraint (STOR)
3.3. Platform volatility (PVOL)
Cost Drivers | Platform Factors

View Slide

jgs
Project Factors
4.1. Use of Software tools (TOOL)
4.2. Multisite development (SITE)
4.3. Required schedule - stretch-out or acceleration (SCED)
Cost Drivers | Project Factors
Multisite development

View Slide

jgs
Questions

View Slide

jgs
§ Somerville, Chapter 23
Reference

View Slide

jgs
Office Hours
Tuesday and Thursday 3 - 5 pm
But an appointment required
Sent me an email – [email protected]

View Slide

jgs
Appendix A: Product Factors

View Slide

jgs
§ Measures the extent to which the software must perform its intended function over
a period of time.
§ Ask: what is the effect of a software failure?
1.1. Required Reliability (RELY)
Very Low Low Nominal High Very High Extra High
RELY slight
inconvenience
low, easily
recoverable losses
moderate, easily
recoverable losses
high financial loss risk to human life

View Slide

jgs
§ Captures the effect large data requirements have
on development to generate test data that will be used to exercise
the program
§ Calculate the data/program size ratio (D/P):
DatabaseSize(bytes) / ProgramSize (LOC)
1.2. Data Base Size (DATA)
DATA DB bytes/ Pgm SLOC < 10 10 £ D/P < 100 100 £ D/P < 1000 D/P > 1000

View Slide

jgs
It is divided into five areas:
1. control operations,
2. computational operations,
3. device-dependent operations,
4. data management operations, and
5. user interface management operations.
Select the area or combination of areas that characterize the product or a
sub-system of the product.
Use a subjective weighted average of the attributes, weighted
by their relative product importance.
1.3. Product Complexity (CPLX)

View Slide

jgs
1.3. Product Complexity (CPLX)
Control
Operations
Straightline code
with a few non-
nested structured
programming
operators: DOs,
CASEs,
IFTHENELSEs.
Simple module
composition via
procedure calls or
simple scripts.
Straightforward
nesting of
structured
programming
operators.
Mostly simple
predicates.
Mostly simple
nesting. Some
intermodule
control. Decision
tables. Simple
callbacks or
message
passing,
including
middleware-
supported
distributed
processing.
Highly nested
structured
programming
operators with many
compound
predicates. Queue
and stack control.
Homogeneous, dist.
processing. Single
processor soft real-
time ctl.
Reentrant and
recursive coding.
Fixed-priority
interrupt handling.
Task synchronization,
complex callbacks,
heterogeneous dist.
processing. Single-
processor hard real-
time ctl.
Multiple resource
scheduling with
dynamically changing
priorities. Microcode-
level control.
Distributed hard real-
time control.
Computational
Operations
Evaluation of
simple
expressions: e.g.,
A=B+C*(D-E)
Evaluation of
moderate-level
expressions:
e.g.,
D=SQRT(B**2-
4.*A*C)
Use of standard
math and
statistical
routines. Basic
matrix/vector
operations.
Basic numerical
analysis: multivariate
interpolation, ordinary
differential eqns.
Basic truncation,
roundoff concerns.
Difficult but structured
numerical analysis:
near-singular matrix
equations, partial
differential eqns.
Simple
parallelization.
Difficult and
unstructured
numerical analysis:
highly accurate
analysis of noisy,
stochastic data.
Complex
parallelization.
Device-
dependent
Operations
Simple read,
write
statements
with simple
formats.
No cognizance
needed of particular
processor or I/O
device
characteristics. I/O
done at GET/PUT
level.
I/O processing
includes device
selection, status
checking and error
processing.
Operations at physical
I/O level (physical
storage address
translations; seeks,
reads, etc.).
Optimized I/O overlap.
Routines for interrupt
diagnosis, servicing,
masking.
Communication line
handling.
Performance-intensive
embedded systems.
Device timing-
dependent coding,
micro-programmed
operations.
Performance-
critical embedded
systems.
Data
Management
Operations
Simple arrays
in main
memory.
Simple COTS-
DB queries,
updates.
Single file subsetting
with no data structure
changes, no edits, no
intermediate files.
Moderately complex
COTS-DB queries,
updates.
Multi-file input and
single file output.
Simple structural
changes, simple
edits. Complex
COTS-DB queries,
updates.
Simple triggers
activated by data
stream contents.
Complex data
restructuring.
Distributed database
coordination. Complex
triggers. Search
optimization.
Highly coupled,
dynamic relational
and object
structures. Natural
language data
management.
User
Interface
Management
Simple input
forms, report
generators.
Use of simple graphic
user interface (GUI)
builders.
Simple use of
widget set.
Widget set
development and
extension. Simple
voice I/O, multimedia.
Moderately complex
2D/3D, dynamic
graphics, multimedia.
Complex
multimedia, virtual
reality.

View Slide

jgs
Accounts for the additional effort needed to construct components intended
for reuse.
1.4 Required Reusability (RUSE)
RUSE none across project across program across product line across multiple product lines

View Slide

jgs
Level of required documentation.
1.5. Documentation (DOCU)
DOCU Many life-cycle
needs uncovered
Some life-cycle
needs uncovered
Right-sized to life-
cycle needs
Excessive for life-
cycle needs
Very excessive for
life-cycle needs

View Slide

jgs
Appendix B: Personal Factors

View Slide

jgs
Analysts work on requirements, high level design and detailed design.
Consider analysis and design ability, efficiency and thoroughness, and the
ability to communicate and cooperate.
2.1. Analyst Capability (ACAP)
ACAP 15th percentile 35th percentile 55th percentile 75th percentile 90th percentile

View Slide

jgs
Evaluate the capability of the programmers as a team rather than as
individuals. Consider ability, efficiency and thoroughness, and the ability to
communicate and cooperate.
2.2. Programmer Capability (PCAP)
PCAP 15th percentile 35th percentile 55th percentile 75th percentile 90th percentile

View Slide

jgs
Assess the project team's equivalent level of experience with this type
of application.
2.3. Applications Experience (AEXP)
AEXP £ 2 months 6 months 1 year 3 years 6 years

View Slide

jgs
Assess the project team's equivalent level of experience with this platform
including the OS, graphical user interface, database, networking, and
distributed middleware.
2.4. Platform Experience (PEXP)
PEXP £ 2 months 6 months 1 year 3 years 6 year

View Slide

jgs
Measures the level of programming language and software tool experience of
the project team.
o
2.5. Language and Tool Experience (LTEX)
LTEX £ 2 months 6 months 1 year 3 years 6 years

View Slide

jgs
The scale for PCON is in terms of the project's annual personnel turnover.
2.6. Personnel Continuity (PCON)
PCON 48% / year 24% / year 12% / year 6% / year 3% / year

View Slide

jgs
Appendix C: Platform Factors

View Slide

jgs
Measures the constraint imposed upon a system in terms of the percentage
of available execution time expected to be used by the system.
3.1. Time Constraint (TIME)
TIME £ 50% use of available execution time 70% 85% 95%

View Slide

jgs
§ Measures the degree of main storage constraint imposed on a software
system or subsystem.
§ Given the remarkable increase in available processor execution time and
main storage, one can question whether these constraint variables are still
relevant. However, many applications continue to expand to consume
whatever resources are available, making these cost drivers still relevant.
3.2. Storage Constraint (STOR)
STOR £ 50% use of available storage 70% 85% 95%

View Slide

jgs
Assesses the volatility of the platform, i.e., the complex of hardware and
software the software product calls on to perform its tasks
3.3. Platform Volatility (PVOL)
PVOL major change every 12 mo.;
minor change every 1 mo.
major: 6 mo.;
minor: 2 wk.
major: 2 mo.;
minor: 1 wk.
major: 2 wk.;
minor: 2 days

View Slide

jgs
Appendix D: Project Factors

View Slide

jgs
Assess the usage of software tools used to develop the product in terms of
their capabilities and maturity. Software tools have improved significantly
since the 1970's projects used to calibrate COCOMO. The tool rating ranges
from simple edit and code, very low, to integrated lifecycle management
tools, very high.
4.1. Use of Software Tools (TOOL)
edit, code,
debug
simple,
frontend,
backend CASE,
little integration
basic lifecycle
tools, moderately
integrated
strong, mature
lifecycle tools,
moderately
integrated
strong, mature,
proactive lifecycle
tools, well integrated
with processes,
methods, reuse

View Slide

jgs
Assess and average two factors: site collocation and communication
support.
4.2. Multisite Development (SITE)
SITE:
Collocation
International Multi-city and
Multi-company
Multi-city or
Multi-company
Same city or
metro. area
Same building or
complex
Fully collocated
SITE:
Communications
Some phone,
mail
Individual phone,
FAX
Narrowband
email
Wideband
electronic
communication
Wideband elect.
comm, occasional
video conf.
Interactive
multimedia

View Slide

jgs
Measure the imposed schedule constraint in terms of the percentage of
schedule stretch-out or acceleration with respect to a nominal schedule
for the project.
4.3. Required Schedule (SCED)
SCED 75% of nominal 85% 100% 130% 160%

View Slide

jgs

View Slide

jgs
CSC 309
Software Engineering II
Lab 19:
COCOMO
Dr. Javier Gonzalez-Sanchez
[email protected]
www.javiergs.com
Building 14 -227
Office Hours: By appointment

View Slide

jgs
§ It has 1200 LOC
§ Nothing to be reuse
§ What could be its cost in the best-case scenario?
§ What could be its cost in the worse-case scenario?
§ What is the best-case scenario? (value for the factors)
§ What is the worse-case scenario? (value for the factors)
Pacman

View Slide

jgs
§ It has ~2000 LOC
§ Are you reusing?
§ What are the values for the factors that apply to your team?
Your Final Project

View Slide

jgs
Let’s Work

View Slide

jgs
CSC 309 Software Engineering II
Javier Gonzalez-Sanchez, Ph.D.
[email protected]
Winter 2023
Copyright. These slides can only be used as study material for the class CSC308 at Cal Poly.
They cannot be distributed or used for another purpose.

View Slide

CSC309 Lecture 19

CSC309 Lecture 19

Javier Gonzalez-Sanchez
PRO

More Decks by Javier Gonzalez-Sanchez

Other Decks in Programming

Featured

Transcript

CSC309 Lecture 19

CSC309 Lecture 19

Javier Gonzalez-Sanchez PRO

More Decks by Javier Gonzalez-Sanchez

Other Decks in Programming

Featured

Transcript

Javier Gonzalez-Sanchez
PRO