Project Planning
Instructor: Dr. Jerry Gao
Project Planning
- Software Scope
- Obtaining Information Necessary for Scope
- A Scoping Example
- Resources
- Software Project Estimation
- Decomposition Techniques
- Software Sizing
- Problem-based Estimation
- Process-Based Estimation
- Empirical Estimation Models
- The Structure of Estimation Models
- The COCOMO Model
- The Software Equation
- The Make-Buy Decision
Jerry Gao, Ph.D. Jan. 1999
Project Planning
Project planning is one of the first activity in a software process.
The quality and accuracy of a software project
---> affect the process, product quality, and schedule.
Objectives: reasonable estimation on resources, cost, and schedule
Major problem in project planning is the uncertainty of a project plan.
The risks caused by:
- Project complexity
- Project size
- The degree of structural uncertainty
- Understanding of the project and system
- Changes of requirements
Note: a project manager should not become obsessive about estimation.
Modern software engineering approaches take an iterative view of
development.
Revisit the estimation and revise it when the customer makes changes to
requirements.
Software Scope
The first activity in software project planning
--> determination of software scope.
Goal:
To define a unambiguous and understandable project scope
at management and technical levels.
Software scope:
function, performance, constraints, interfaces, and reliability.
delivery deadlines, budgetary restrictions, personnel availability
technical interfaces, and so on.
Without these information, it is impossible
- To define reasonable estimates of the cost
- To conduct an effective assessment of risk
- To do realistic breakdown of project tasks
- To come out a manageable project schedule
Obtaining Information
To define a project scope, we need a lot of information through a
communication process.
A preliminary meeting or interview is a common technique to bridge the
communication gap between engineers and the customer.
Analysts must ask context free questions to lead a basic understanding of
the problem and the desired solutions.
Communication with the customer -->
- definition of the data, functions, and behavior,
- the performance and constraints.
Questions focus on the customer, goals, and the benefits:
- Who is behind the request for this work?
- Who will use the solution?
- What will be the economic benefit of a successful solution?
- Is there another source for the solution?
Obtaining Information
Questions focus on solutions (from the customer’s perceptions):
- How would you characterize “good” output that would be
generated by a successful solution?
- What problem(s) will this solution address?
- Can you show me (or describe) the environment where the
solution will be used?
- Are there special performance issues (or constraints)?
The final set of questions: (meta-questions)
- Are you the right person to answer these questions? Are your
answers “official”?
- Are my questions relevant to the problem that you have?
- Am I asking too many questions?
- Is there anyone else who can provide additional information?
- Is there anything else that I should be asking you?
The Q&A session should be used for the first encounter only.
Resources
People
Reusable Software
Components
Hardware/Software Tools
Reusable Software Resources:
Bennatan [Ben92] suggests four software resource categories:
- Off-the-shelf components: third-party software, ready for use and validated.
- Full-experience components: existing specification, design, code or test data from past projects.
---> small changes and low risk.
- Partial-experience components: existing specification, design, code, or test data from past projects.
---> needs a lot of changes, a fair degree of risk.
- New components: new software components must be built by the software team .
Resources
People
Reusable Software
Components
Hardware/Software Tools
Reusable Software Resources:
Bennatan [Ben92] suggests four software resource categories:
- Off-the-shelf components: third-party software, ready for use and validated.
- Full-experience components: existing specification, design, code or test data from past projects.
---> small changes and low risk.
- Partial-experience components: existing specification, design, code, or test data from past projects.
---> needs a lot of changes, a fair degree of risk.
- New components: new software components must be built by the software team .
Resources
Guidelines used by software planner when reusable components are specified as a resource:
- If off-the-shelf components meet project requirements, acquire them.
Because: cost is low, risk is small.
- If full-experience components are available, the risks associated with modification and
integration are generally acceptable. The project plan should reflect this.
- If partial-experience components are available, their use for the current project should be
analyzed in detail.
Software Project Estimation
Software cost and effort estimation will never be an exact science. Too many variables can affect
the ultimate cost of software and effort.
For example, human, technical, environmental, political,….
To achieve reliable cost and effort estimation, a number of options arise:
- Delay estimation until late in the project.
--> not practical.
- Base estimation on similar completed projects
--> work reasonability well if the current project is quit similar to the past projects.
However, past experience has not always been a good indicator.
- Use relatively simple “decomposition techniques” to generate project cost and effort estimation
--> a viable approach to software project estimation.
- Use one or more empirical models for software cost and effort estimation.
--> can be used to complement decomposition techniques and offer a potentially
valuable estimation approach.
--> based on the past experience in a specific environment for application projects.
Decomposition Techniques
-->
Problem decomposition and process decomposition
Before an estimate can be made, the project planner must understand the scope
of the software to be built and generate an estimate of its “size”.
Software Sizing:
The accuracy of a software project estimate is predicated on a number things:
- The degree to which the planner has properly estimated the size of the product
to be built.
- The ability to translate the size estimate into human effort in time and cost.
- The degree to which the project plan reflects the abilities of the software team
- The stability of product requirements and the environment that supports the
software engineering effort.
Putnam and Myers [PUT92] suggest four different approaches to the sizing
problem:
a) Fuzzy-logic sizing
b) Function point sizing
c) Standard component sizing
d) Change sizing
Problem-Based Estimation
Line of code (LOC) and function points (FP) are basic metrics to measure
productivity.
LOC and FP data are used in two ways during software project estimation.
- As an estimation variable that is used to “size” each element of the software.
- As baseline metrics collected from past projects and used in conjunction with
estimation variables to predict project cost and effort.
As a project planner, he/she first decompose software into problem functions
until each of them can be estimated individually.
Next, Baseline productivity metrics (LOC/pm or FP/pm) are then applied to
the appropriate estimation variable and cost (or effort) for each function.
Alternatively, the planner may choose another component for sizing such as
classes (or objects), changes, or business processes.
For FP estimation, decomposition works differently.
--> Focus on each of the information domain characteristics, such as
inputs, outputs, data files, inquires, and external interfaces, and so on.
Problem-Based Estimation
A three-point or expected value:
EV = (Sopt + 4Sm + Spess)/6
(one typical example)
- EV - Expected value for the estimation variable (size).
- the optimistic (Sopt) estimate.
- the most likely (Sm).
- the pessimistic (Spess) estimate.
This assumes that there is a very small probability that the actual size result will
fall outside the optimistic or pessimistic values.
Once the expected value for the estimation variable has been determined,
historical LOC or FP productivity data are applied. Are the estimates correct?
The only answer to this question is: “We can’t be sure.”
An Example of LOC-based Estimation
A preliminary statement of software scope can be developed:
The CAD software will accept two- and three- dimensional geometric data from an engineer.
The engineer will interact and control the CAD system through a user interface that will exhibit
characteristics of good human-machine interface design. All geometric data and other
supporting information will be maintained in a CAD database. Design and analysis modules
will be developed to produce required output which will be displayed on a variety of graphics
devices. The software will be designed to control and interact with peripheral devices that
include a mouse, digitizer, and laser printer.
User interface and control facilities (UICF)
2,300
Two-dimensional geometric analysis (2DGA)
5,300
Three-dimensional geometric analysis (3DGA)
6,800
Database management (DBM)
3,350
Computer graphics display facilities (CGDF)
4,950
Peripheral control (PC)
2,100
Design analysis modules (DAM)
8,400
--------------------------------------------------------------------------estimated lines of code
33,200
The range of LOC estimates for the 3D geometric analysis function is:
Sopt = 4600,
Sm = 6900
Spess = 8600
An Example of FP-based Estimation
Information Domain Value opt. Likely pess. Est. count weight FP-count
--------------------------------------------------------------------------------------------------no. of inputs
20 24
30
24
4
96
no. of outputs
12 16
22
16
5
80
no. of inquires
16 22
28
22
4
88
no. of files
4
4
5
4
10
40
no. of external interfaces
2 2
3
2
7
14
--------------------------------------------------------------------------------------------------count-total
318
--------------------------------------------------------------------------------------------------Factor
Value
Factor
Value
Backup and recover
4
Data communications
2
Distributed processing
0
Performance critical
4
Existing op env.
3
On-line data entry
4
Input transaction
5
Master files updated
3
over multiple screens
Information domain value complex.5
Internal processing complex
5
Code designed for reuse
4
Conversion/installation in design 3
Multiple installations
5
Application designed for change 5
Complexity adj. Factor
1.17
Empirical Estimation Models
An estimation model for computer software uses empirically derived formulas to
predict effort as a function of LOC or FP.
The empirical data that support most estimation models is derived from a limited
sample of projects.
---> The results from such models must be used judiciously.
The Structure of Estimation Models:
A typical estimation model is derived using regression analysis on data collected
from past software projects. The overall structure of such models takes the
form:
C
E = A + B X (ev)
where A, B, and C are empirically derived constants, E is effort in person
months, and ev is the estimation variable (either LOC or FP).
The COCOMO Model
Barry Boehm [BOE81]’s COCOMO stands for COnstructuve COst Model.
COCOMO model is a comprehensive empirical model for software estimation.
Three forms:
Model 1: The Basic COCOMO model
- computes the cost as a function of program size expressed in
estimated lines of code.
Model 2: The Intermediate COCOMO model
- computes the cost as function of program size and a set of
“cost drivers”, such as hardware, personnel, project attributes,
.. product attribute.
Model 3: The Advanced COCOMO model
- incorporates all characteristics of the intermediate version with
an assessment of the cost driver’s impact on each step of the software
process.
The COCOMO Model
Basic COCOMO model:
bb
E = ab KLOC
db
D = cb E
E- the effort applied in person-months.
D - the development time in chronological months.
Software project
organic
semi-detached
embedded
ab
bb
cb
db
2.4
3.0
3.6
1.05
1.12
1.20
2.5
2.5
2.5
0.38
0.35
0.32
1.05
1.05
Example: E = 2.4 (KLOC) = 2.4(33.3) = 95 person-months
0.35
0.35
D = 2.5 E = 2.5 (95) = 12.3 months, N=E/D=95/12.3= ~8 people.
The COCOMO Model
Intermidiate COCOMO model:
bi
E = ai KLOC
X
EAF
E- the effort applied in person-months.
EAF - An effort adjustment factor (EAF)
typical values range from 0.9 to 1.4.
Software project
organic
semi-detached
embedded
ai
bi
3.2
3.0
2.8
1.05
1.12
1.20
The Software Equation
The software equation [PUT92] - a multivariable model.
--> assume a specific distribution of effort over the life of a software
development project. (based on data from 4000 projects)
0.333
3
4
E = [LOC X B
/ P ] X (1 / t )
E - effort in person-months or person-years.
t - project duration in months or years
B - special skill factor.
For small programs (KLOC = 5 - 15), B = 0.16.
For programs greater than 70 KLOC, B = 0.39.
P - “productivity parameter” that reflects:
- overall process maturity and management practices
- the extent to which good software engineering practices are used
- the level of programming languages used
- the state of the software environment
- the skill and experience of the software team
- the complexity if the application
P = 2000 for real-time embedded software
P = 10,000 for telecommunication systems,
P = 28,000 for business application systems
The Make-Buy Decision
In many cases, it is often more cost effective to acquire, rather than develop,
computer software.
Mangers are faced with a make-buy decision based on three acquisition options:
- software may be purchased (or licensed) off-the-shelf
- “full-experience” or “partial-experience” software components
- customer-built software
For more expensive software products, the following guidelines can be applied:
- 1) Develop a specification for the desirable function and performance.
- 2) Estimate the internal cost to develop and delivery date.
- 3a) Select 3 or 4 candidate applications that best meet your specification.
- 3b) Select reusable software components for applications.
- 4) Develop a comparison matrix for key functions.
- 5) Evaluate each software package or component.
- 6) Contact other users for opinions.
The Make-Buy Decision
- Creating a Decision Tree
In the final analysis, checking the following questions:
- Will the delivery date of the software product be sooner than for internally
developed software?
- Will the cost of acquisition plus the cost of customization be less than the cost
of developing the software internally?
- Will the cost of outside support be less than the cost of internal support?
simple (0.30)
$380,000
$450,000
difficult (0.70)
build
$275,000
minor changes (0.40)
$310,000
reuse
simple (0.20)
complex (0.80)
System X
buy
contract
Major changes
(0.60)
minor changes (0.70)
major changes (0.30)
Without changes (0.60)
$490,000
$210,000
$400,000
$500,000
With changes (0.40)