Transcript San Diego International Airport – Access Control System: System transactions—over 250000 per.

San Diego International Airport – Access Control System:
System transactions—over 250000 per. day.
Average processing time—less than 15. seconds.
Reliability—99.99%.
System capability—upgradeable and. expandable ...
[www.biometric.org]
Process, Product and Project Metrics
Product Metrics for Software
Estimation for Software Projects
based on
Chapter 15
Chapter 22
Chapter 23
Software Engineering: A Practitioner’s Approach, 6/e
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
For University Use Only
May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
1
McCall’s Triangle of Quality
M a in ta in a b ility
F le xib ility
T e sta bility
P R O D U C T R E V IS IO N
proposed in the early 1970s.
P o rta b ility
R e u sa bility
In te ro p e ra b ility
P R O D U C T T R A N S IT IO N
P R O D U C T O P E R A T IO N
C o rre ctn e ss
U sa b ility
E fficie n cy
R e lia b ility
In te g rity
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
2
A Good Manager Measures
process
process metrics
project metrics
measurement
product metrics
product
What’s the diff. between
Process and Product metrics?
What do we
use as a
basis?
• size?
• function?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
3
Measures, Metrics

A measure provides a quantitative indication of the extent, amount,
dimension, capacity, or size of some attribute of a product or process

The IEEE glossary defines a metric as “a quantitative measure of the
degree to which a system, component, or process possesses a given
attribute.”
Can you quantify user-friendliness, security, evolvability, …?
Software measurement
(Sommerville; http://www.utdallas.edu/~chung/SE3354Honors/IEEInaugural.pdf)
• Measurement of products or systems is absolutely fundamental to
the engineering process.
• I am convinced that measurement as practised in other engineering
disciplines is IMPOSSIBLE for software engineering
Not
thatare
can
counted
counts,
and Engineering:
not everything
thatApproach,
counts
beprovided
counted.
Theseeverything
courseware materials
to bebe
used
in conjunction
with Software
A Practitioner’s
6/ecan
and are
with permission
by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
[Albert
Einstein]
4
Project Estimation
Establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical
project.
So the end result gets done on time, with quality!


Project scope must be understood (is your ADS to cover HR)?
Elaboration (decomposition) is necessary



Historical metrics are very helpful (if not, the first time will be hard)




task breakdown and effort estimates (how many do you have for your ADS?)
size (e.g., FP) estimates
Empirical models (hopefully, statistical)
Past (similar) project experience
At least two different techniques should be used (WHY?)
Uncertainty is inherent in the process (and just about everywhere in real SE
projects)
Conventional Methods:
 compute LOC/FP using estimates of information domain values
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with
 permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
use historical data to build estimates for the project
5
Typical Size-Oriented Metrics








errors per KLOC (thousand lines of code)
defects per KLOC
$ per LOC
pages of documentation per KLOC
errors per person-month
Errors per review hour
LOC per person-month
$ per page of documentation
Typical Function-Oriented Metrics
 errors per FP (thousand lines of code)
 defects per FP
 $ per FP
 pages of documentation per FP
 FP per person-month
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
6
Function-Based Metrics



The function point metric (FP), first proposed by Albrecht [ALB79], can be used
effectively(?) as a means for measuring the functionality
delivered by a system.
FPs are derived using an empirical relationship based on
countable (direct) measures of software's information domain
and assessments of software complexity
Information domain values are defined in the following
manner:
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
7
Function-Based Metrics

Information domain values are defined in the following manner:
number of external

inputs (EIs)
number of external outputs (EOs)
number of external inquiries (EQs)
number of internal logical files (ILFs)

Number of



{password, panic button, activate/deactivate}
{messages, sensor status}
{zone inquery, sensor inquery}
{system configuration file}
external interface files (EIFs)
{test sensor, zone setting, activate/deactivate, alarm alert}
Sensors
Test sensor
Password
Zone setting
Zone inquery
User
Sensor inquery
Panic button
SafeHome
User interaction
function
messages
User
Sensor status
Activate/deactivate
Activate/deactivate
Password,
Sensors,
…
Alarm alert
Monitoring
& response
system
System configuration data
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
What kind of diagram is this?
8
Computing Function
Points
Inform ation
Dom ain Value
External Inputs ( EIs)
External Outputs ( EOs)
External Inquiries ( EQs)
Internal Logical Files ( ILFs)
External Interf ace Files ( EIFs)
We ighting factor
s im ple ave r age com ple x
Count
x3
x3
x3
3
x
3
x
=
3
4
6
4
5
7
3
4
6
=
7
10
15
=
5
7
10
=
=
Count total
assume simple
What would be the total function points for the safehome system?
What do we do next with the total function points for the safehome system?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
9
LOC Approach
Function
Estimated LOC
2-d geometric analysis
2300
3-d geometric analysis
5300
DBM
3350
Graphics display facilities
4950
Peripheral control function
2100
UI
2300
Design analysis modules
8400
Estimated LOC
33200
A CAD application
Historical data:
• Average productivity for systems of this type = 620 LOC/pm.
(per-month)
• Labor rate = $8000/pm, Cost/LOC =8000/620?
Based on the LOC estimate and the historical productivity data,
• estimated effort = 33200/620=54 person-months.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
• total estimated project cost = 33200/620 * 8000 = $431,000
10
Example: FP Approach
Inform ation
Dom ain Value
External Inputs ( EIs)
External Outputs ( EOs)
External Inquiries ( EQs)
Internal Logical Files ( ILFs)
External Interf ace Files ( EIFs)
Count total
We ighting factor
s im ple ave r age com ple x
Count
x3
x3
x
3
x3
x
3
=
3
4
6
4
5
7
3
4
6
=
7
10
15
=
5
7
10
=
=
A CAD application
320
FPestimated = count-total * [0.65 + 0.01 * Sum (Fi)] --- p442 adjustment factors
(e.g., factor in reliability, performance, reusability, complexity, …)
= 320 * [0.65 + 0.01 * 52] = 374
Historical data:
• organizational average productivity = 6.5 FP/pm.
• labor rate = $8000 pm, cost per FP = ?.
Based on the FP estimate and the historical productivity data,
•These
total
estimated
project
374/6.5 * 8000 = $461,000
courseware
materials
are to be cost
used in =
conjunction
with Software Engineering: A Practitioner’sSee
Approach,
6/e and are provided
safehome
example
11
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
• estimated effort = 374/6.5 = 58 person-months.
Comparing LOC and FP
Programming
Language
Ada
Assemb ler
C
C++
COBOL
Java
JavaSc ript
Perl
PL/1
Powerbuilder
SAS
Smalltalk
SQL
Visual Basic
LOC per Function point
avg.
median
low
high
154
337
162
66
315
109
53
104
91
33
29
205
694
704
178
77
63
58
60
78
32
40
26
40
47
77
53
63
67
31
41
19
37
42
14
77
42
22
11
33
10
7
16
400
75
263
105
49
55
110
158
Representative values developed by QSM
So, which would you prefer – LOC or FP?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
12
Estimation with Use-Cases
use cases scenarios pages
e subsystem
6
10
6
User interf ace
subsystem
Engineeringsubsystem
subsystem
group
group
10
20
8
Inf rastructure
subsystem
group
e subsystem
group
5
6
5
Total LOC estimate
stimate
Êscenarios pages
Ê
12
5
Ê
16
8
Ê
10
6
Ê
Ê
Ê
Ê
Ê
Ê
LOC LOC estimate
560
3,366
3100
31,233
1650
7,970
Ê
Ê
42,568
Historical data:
• average productivity for systems of this type = 620 LOC/pm
• labor rate = $8000 pm,
=> cost/LOC = ?.
Based on the use-case estimate and the historical productivity data,
- total estimated project cost =
= $552,000
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
- estimated effort = = 68 pm.
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
42568/620 * 8000
42568/620
13
The Make-Buy Decision
expected cost build = 0.30 ($380K) + 0.70
($450K)
= $429 K
expected cost reuse
= ??? = $382K
expected cost =
expected
costApproach,
buy 6/e and
= ???
= $267K
These courseware materials are to be used in conjunction with Software Engineering:
A Practitioner’s
are provided
(path
probability)
x
(estimated
path
cost)
with permission by R.S. Pressman
i & Associates, Inc., copyright © 1996, 2001,
i 2005
14
Class-Oriented Metrics
Proposed by Chidamber and Kemerer:




methods per class
depth of the inheritance tree
number of children
coupling between object classes
Can you depict these in UML?
Proposed by Lorenz and Kidd [LOR94]:




class size
number of operations overridden by a subclass
number of operations added by a subclass
average number of parameters per operation
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
15
Measurement Principles

The objectives of measurement should be established before data collection begins;

Each technical metric should be defined in an unambiguous manner;

Metrics should be derived based on a theory that is valid for the domain of application

Metrics should be tailored to best accommodate specific products and processes
[BAS84]
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
How do you define technical metric unambiguously?
16
The Mythical Man-Month


What is so mythical?
Review The Mythical Man-Month
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
17
Omitted Slides
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
18
Defect Removal Efficiency
DRE = E /(E + D)
E is the number of errors found before delivery of
the software to the end-user
D is the number of defects found after delivery.
What would be the relationship betw. DRE and reliability prediction?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
19
Why Do We Measure?





assess the status of an ongoing project
track potential risks
uncover problem areas before they go “critical,”
adjust work flow or tasks,
evaluate the project team’s ability to control quality of
software work products.
Process model
Process improvement
recommendations
Improvement goals
Process metrics
SPI
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
20
Process Measurement

We measure the efficacy of a software process indirectly.


That is, we derive a set of metrics based on the outcomes that can be derived
from the process.
Outcomes include

measures of errors uncovered before release of the software

defects delivered to and reported by end-users

work products delivered (productivity)

human effort expended

calendar time expended
schedule conformance
other measures.


These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
21
Project Metrics



used to minimize the development schedule by making the adjustments necessary
to avoid delays and mitigate potential problems and risks
used to assess product quality on an ongoing basis and, when necessary, modify
the technical approach to improve quality.
every project should measure:
inputs—measures of the resources (e.g., people, tools) required to do the work.
outputs—measures of the deliverables or work products created during the software
engineering process.
results—measures that indicate the effectiveness of the deliverables.



Typical Project Metrics





Effort/time per software engineering task
Errors uncovered per review hour
Scheduled vs. actual milestone dates
Changes (number) and their characteristics
Distribution of effort on software engineering tasks
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
22
Object-Oriented Metrics

Number of scenario scripts (use-cases)

Number of support classes (required to implement the system
but are not immediately related to the problem domain)

Number of subsystems (an aggregation of classes that support
a function that is visible to the end-user of a system)
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
23
WebE Project Metrics








Number of static Web pages (the end-user has no control over the content
displayed on the page)
Number of dynamic Web pages (end-user actions result in customized
content displayed on the page)
Number of internal page links (internal page links are pointers that provide a
hyperlink to some other Web page within the WebApp)
Number of persistent data objects
Number of external systems interfaced
Number of static content objects
Number of dynamic content objects
Number of executable functions
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
24
Goal-Oriented Software Measurement

The Goal/Question/Metric Paradigm




(1) establish an explicit measurement goal that is specific to the process
activity or product characteristic that is to be assessed
(2) define a set of questions that must be answered in order to achieve the
goal, and
(3) identify well-formulated metrics that help to answer these questions.
Goal definition template





Analyze {the name of activity or attribute to be measured}
for the purpose of {the overall objective of the analysis}
with respect to {the aspect of the activity or attribute that is considered}
from the viewpoint of {the people who have an interest in the measurement}
in the context of {the environment in which the measurement takes place}.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
25
Measurement Process





Formulation. The derivation of software measures and metrics appropriate for the
representation of the software that is being considered.
Collection. The mechanism used to accumulate data required to derive the
formulated metrics.
Analysis. The computation of metrics and the application of mathematical tools.
Interpretation. The evaluation of metrics results in an effort to gain insight into the
quality of the representation.
Feedback. Recommendations derived from the interpretation of product metrics
transmitted to the software team.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
26
Establishing a Metrics Program










Identify your business goals.
Identify what you want to know or learn.
Identify your subgoals.
Identify the entities and attributes related to your subgoals.
Formalize your measurement goals.
Identify quantifiable questions and the related indicators that you will use to
help you achieve your measurement goals.
Identify the data elements that you will collect to construct the indicators that
help answer your questions.
Define the measures to be used, and make these definitions operational.
Identify the actions that you will take to implement the measures.
Prepare a plan for implementing the measures.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
27
Why Opt for FP?




Programming language independent
Used readily countable characteristics that are
determined early in the software process
Does not “penalize” inventive (short) implementations
that use fewer LOC that other more clumsy versions
Makes it easier to measure the impact of reusable
components
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
28
Omitted Slides from
Estimation for Software Projects
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
29
Project Planning Task Set




Establish project scope
Determine feasibility
Analyze risks
Define required resources


Estimate cost and effort




human resources, reusable software resources
Decompose the problem
Develop two or more estimates using size, FPs, process tasks or use-cases
Reconcile the estimates
Develop a project schedule
Establish a meaningful task set
 Define a task network
 Use scheduling tools to develop a timeline chart
 Define
schedule
tracking
mechanisms
These courseware
materials are
to be used in conjunction
with Software
Engineering: A Practitioner’s Approach, 6/e and are provided

with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
30
Resources
number
sof tware
tools
skills
hardware
people
environment
locat ion
net work
resources
pr oje ct
OTS
components
reusable
softw are
f ull-experience
components
new
components
part. -experience
components
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
31
Write it Down!
Project Scope
Estimates
Risks
Schedule
Control strategy
Software
Project
Plan
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
32
Estimation

Estimation of resources, cost, and schedule for a
software engineering effort requires




experience
access to good historical information (metrics
the courage to commit to quantitative predictions when
qualitative information is all that exists
Estimation carries inherent risk and this risk leads to
uncertainty
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
33
To Understand Scope ...






Understand the customers needs
understand the business context
understand the project boundaries
understand the customer’s motivation
understand the likely paths for change
understand that ...
Even when you understand,
nothing is guaranteed!
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
34
What is Scope?

Software scope describes





the functions and features that are to be delivered to end-users
the data that are input and output
the “content” that is presented to users as a consequence of
using the software
the performance, constraints, interfaces, and reliability that
bound the system.
Scope is defined using one of two techniques:


A narrative description of software scope is developed after
communication with all stakeholders.
A set of use-cases is developed by end-users.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
35
Process-Based Estimation
Obtained from “process framework”
framework activities
application
functions
Effort required to
accomplish
each framework
activity for each
application function
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
36
Functional Decomposition
Statement
of
Scope
functional
decomposition
Perform a
Grammatical “parse”
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
37
Process-Based Estimation Example
Activity
CC
Planning
Risk
Analysis
Task
Engineering
Construction
Release
analysis
design
code
test
0.50
0.75
0.50
0.50
0.50
0.25
0.50
2.50
4.00
4.00
3.00
3.00
2.00
2.00
0.40
0.60
1.00
1.00
0.75
0.50
0.50
5.00
2.00
3.00
1.50
1.50
1.50
2.00
4.50
CE
Totals
n/a
n/a
n/a
n/a
n/a
n/a
n/a
8.40
7.35
8.50
6.00
5.75
4.25
5.00
Function
UICF
2DGA
3DGA
CGDF
DSM
PCF
DAM
Totals
0.25
0.25
0.25
3.50
20.50
% effort
1%
1%
1%
8%
45%
10%
16.50
46.00
36%
CC = customer communication CE = customer evaluation
Based on an average burdened labor rate of $8,000 per month, the
total estimated project cost is $368,000 and the estimated effort is 46
person-months.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
38
Tool-Based Estimation
project characteristics
calibration factors
LOC/FP data
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
39
COCOMO-II

COCOMO II is actually a hierarchy of estimation models
that address the following areas:



Application composition model. Used during the early stages of
software engineering, when prototyping of user interfaces,
consideration of software and system interaction, assessment of
performance, and evaluation of technology maturity are paramount.
Early design stage model. Used once requirements have been
stabilized and basic software architecture has been established.
Post-architecture-stage model. Used during the construction of the
software.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
40
Estimation for OO Projects-I




Develop estimates using effort decomposition, FP analysis, and any other
method that is applicable for conventional applications.
Using object-oriented analysis modeling (Chapter 8), develop use-cases
and determine a count.
From the analysis model, determine the number of key classes (called
analysis classes in Chapter 8).
Categorize the type of interface for the application and develop a multiplier
for support classes:





Interface type
No GUI
Text-based user interface
GUI
Complex GUI
Multiplier
2.0
2.25
2.5
3.0
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
41
Estimation for OO Projects-II



Multiply the number of key classes (step 3) by the multiplier to obtain
an estimate for the number of support classes.
Multiply the total number of classes (key + support) by the average
number of work-units per class. Lorenz and Kidd suggest 15 to 20
person-days per class.
Cross check the class-based estimate by multiplying the average
number of work-units per use-case
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
42
Metrics for OO Design

Whitmire [WHI97] describes nine distinct and measurable characteristics of an OO design:

Size


Complexity





“the degree to which an abstraction possesses the features required of it, or the degree to which a design
component possesses features in its abstraction, from the point of view of the current application.”
Completeness


The physical connections between elements of the OO design
Sufficiency


How classes of an OO design are interrelated to one another
Coupling


Size is defined in terms of four views: population, volume, length, and functionality
An indirect implication about the degree to which the abstraction or design component can be reused
Cohesion
 The degree to which all operations working together to achieve a single, well-defined purpose
Primitiveness
 Applied to both operations and classes, the degree to which an operation is atomic
Similarity
 The degree to which two or more classes are similar in terms of their structure, function, behavior,
or purpose
Volatility
 Measures the likelihood that a change will occur
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
43
Estimation for Agile Projects



Each user scenario (a mini-use-case) is considered separately for
estimation purposes.
The scenario is decomposed into the set of software engineering tasks that
will be required to develop it.
Each task is estimated separately. Note: estimation can be based on
historical data, an empirical model, or “experience.”


Estimates for each task are summed to create an estimate for the scenario.


Alternatively, the ‘volume’ of the scenario can be estimated in LOC, FP or some
other volume-oriented measure (e.g., use-case count).
Alternatively, the volume estimate for the scenario is translated into effort using
historical data.
The effort estimates for all scenarios that are to be implemented for a given
software increment are summed to develop the effort estimate for the
increment.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
44
Empirical Estimation Models
General form:
effort = tuning coefficient * size
exponent
usually derived
as person-months
of effort required
either a constant or
a number derived based
on complexity of project
empirically
derived
usually LOC but
may also be
function point
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
45
The Software Equation
“derived from productivity data collected for over 4000
contemporary software projects”
A dynamic multivariable model
E = [LOC x B0.333/P]3 x (1/t4)
where
E = effort in person-months or person-years
t = project duration in months or years
B = “special skills factor”
P = “productivity parameter” (typical value for developing real-time embedded sw = 2000;
telecom = 10000; business application = 28000)
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
46