Project Planning - PowerPoint PPT Presentation

Loading...

PPT – Project Planning PowerPoint presentation | free to download - id: 207d9c-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Project Planning

Description:

Use one or more empirical models for software cost and effort ... The degree to which the planner has properly estimated the size of the product to be built. ... – PowerPoint PPT presentation

Number of Views:47
Avg rating:3.0/5.0
Slides: 23
Provided by: Jerr2
Learn more at: http://www.engr.sjsu.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Project Planning


1
Project Planning
Instructor Dr. Jerry Gao
2
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
3
Project Planning
Project planning is one of the first activity in
a software process. The quality and accuracy of a
software project ---gt 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.
4
Software Scope
The first activity in software project planning
--gt 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. delive
ry 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
5
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 --gt
- 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?
6
Obtaining Information
Questions focus on solutions (from the customers
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 QA session should be used for the
first encounter only.
7
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. ---gt small
changes and low risk. - Partial-experience
components existing specification, design, code,
or test data from past projects. ---gt needs a
lot of changes, a fair degree of risk. - New
components new software components must be built
by the software team .

8
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. ---gt small
changes and low risk. - Partial-experience
components existing specification, design, code,
or test data from past projects. ---gt needs a
lot of changes, a fair degree of risk. - New
components new software components must be built
by the software team .

9
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.

10
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. --gt not practical. - Base estimation
on similar completed projects --gt 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 --gt a viable approach
to software project estimation. - Use one or
more empirical models for software cost and
effort estimation. --gt can be used to complement
decomposition techniques and offer a
potentially valuable estimation approach. --gt
based on the past experience in a specific
environment for application projects.

11
Decomposition Techniques
--gt 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
12
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. --gt Focus on each of the
information domain characteristics, such
as inputs, outputs, data files, inquires, and
external interfaces, and so on.
13
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, historica
l LOC or FP productivity data are applied. Are
the estimates correct? The only answer to this
question is We cant be sure.
14
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
15
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 Facto
r 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
16
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. ---gt 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).
17
The COCOMO Model
Barry Boehm BOE81s 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 drivers impact on each step of the
software process.
18
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 ab bb cb db organic 2.4 1.05 2.5 0.38 s
emi-detached 3.0 1.12 2.5 0.35 embedded 3.6 1.2
0 2.5 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,
NE/D95/12.3 8 people.
19
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 ai bi organic 3.2 1.05
semi-detached 3.0 1.12 embedded 2.8 1.20
20
The Software Equation
The software equation PUT92 - a multivariable
model. --gt 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
21
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.
22
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?
380,000
simple (0.30)
450,000
275,000
difficult (0.70)
minor changes (0.40)
build
310,000
reuse
simple (0.20)
complex (0.80)
490,000
System X
Major changes (0.60)
buy
210,000
minor changes (0.70)
major changes (0.30)
contract
400,000
Without changes (0.60)
500,000
With changes (0.40)
About PowerShow.com