Transcript Document 7128222

2
PROJECT
MANAGEMENT
Software Engineering Roadmap:
Chapter 2 Focus
Corporate
practices
Plan
project
Analyze
requirements
Maintain
Integrate
& test system
Design
Implement
Test units
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Software
Management
Engineering
structure
Roadmap:
- hierarchical, peer,...
Chapter 2 Focus
Development
process
Corporate
practices
Risk identification
& retirement
SPMP
- when to do what phase
- document: SPMP
Schedule
Cost estimate
Plan
project
Analyze
requirements
Development
phases
Maintain
Integrate
& test system
Design
Implement
Test units
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Learning Goals of This Chapter
• Understand the term “project management”
• Organize teams
• Specify project management plans
• Define and retire risks
• Estimate costs very early in the life cycle
• Create high level projects schedules
• Write a Software Project Management Plan
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Introduction to project management
Can somewhat vary the following factors.
1. The total cost of the project,
 e.g., increase expenditures
2. The capabilities of the product,
 e.g., subtract from a list of features
.....
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
The Variables
of Project
Management
Can somewhat vary the following factors.
1. The total cost of the project,
 e.g., increase expenditures
2. The capabilities of the product,
 e.g., subtract from a list of features
The Variables
of Project
Management
3. The quality of the product,
 e.g., increase the mean time between failure
4. The date on which the job is completed.
 e.g., reduce the schedule by 20%
 e.g., postpone project's completion date one month
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Bullseye Figure for Project Variables
Target:
100%
cost
capability
Target :
4 defects/Kloc
Target :
$70K
duration
defect
density
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Target :
30 wks
Bullseye Figure for Project Variables
Target:
100%
Actual:
100%
capability
cost
this
project
Actual:
$90K
duration
Target :
30 wks
Target :
4 defects/Kloc
Actual:
1 defect/Kloc
Target :
$70K
defect
density
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Actual:
20 wks
RoadMap for Project Management
1. Understand project content, scope, & time frame
2. Identify development process
(methods, tools, languages, documentation and support) -- section 4 of chapter 1
3. Determine organizational structure
(organizational elements involved) -- see section 3
4. Identify managerial process
(responsibilities of the participants) -- see section 3 of case study 1 at end of chapter
.....
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
RoadMap for Project Management
1. Understand project content, scope, & time frame
2. Identify development process
(methods, tools, languages, documentation and support) -- section 4 of chapter 1
3. Determine organizational structure
(organizational elements involved) -- see section 3
4. Identify managerial process
(responsibilities of the participants) -- see section 3 of case study 1 at end of chapter
5. Develop schedule
(times at which the work portions are to be performed) -- see section 6
6. Develop staffing plan -- see section 3.5 of case study 1
7. Begin risk management -- see section 4
8. Identify documents to be produced -- see SQAP 4.2
9. Begin process itself -- described in chapters 3-10
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
2. Managing people
1.* Distribute start time, end time, and agenda
with approximate times (see figure tbd)
– list important items first
2.* Ensure “strawman” items prepared Plan and
Execute
3. Start on time
Meetings
‡
4. Have someone record action items
5. Have someone track time & prompt members
6. Get agreement on the agenda and timing
7. Watch timing throughout, and end on time
– allow exceptions for important discussion
– stop excessive discussion; take off line
8. Keep discussion on the subject
9.** E-mail action items & decision summary.
* in advance of meeting
‡ actions members must perform ** after meeting
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Specify Agendas
1. Get agreement on agenda & time allocation
2. Get volunteers to … :
… record decisions taken and action items
… watch time and prompt members (see figure tbd)
3. Report progress on project schedule -- 10 mins
4. Discuss strawman artifact(s) -- x mins
5. Discuss risk retirement -- 10 mins
<MORE ITEMS>
metrics and process improvement?
n. Review action items -- 5
mins
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
3. Options for organizing personnel
Optimal Size for Interaction (Approximate)
Effectiveness
per developer
Developer communicates
regularly with no one.
No communication time
lost, but developer is too
isolated and has no help.
3
Number of people with whom
developer must frequently interact
Key:
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
= engineer
Optimal Size for Interaction (Approximate)
Effectiveness
per developer
Approximate
optimal range
Developer communicates
regularly with no one.
No communication time
lost, but developer is too
isolated and has no help.
3
7
Number of people with whom
developer must frequently interact
Developer
communicates
regularly with eleven
people.
Communication time
outweighs benefits of
interaction
Key:
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
= engineer
Hierarchical Project Management Organizations
Smaller Projects:
No separate Marketing?
No separate QA organization?
Larger Projects:
Subdivide QA into testing, …?
Subdivide Engineering into
system engineering, …?
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Horizontal Project Management Organizations
Ian Corliss
Team member
Gil Warner
Team leader
Nel Tremont
Team member
Team facilitator?
Fran Smith
Team member
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Organize a Team
1. Select team leader: responsibilities:
– ensure all project aspects active
– fill all gaps
3. Designate leader roles & document responsibilities
team leader: proposes and maintains… SPMP
configuration management leader: ... SCMP
quality assurance leader:
... SQAP, STP
requirements management leader: ... SRS
design leader:
... SDD
implementation leader:
... code base
2. Leaders’ responsibilities:
–
–
–
–
propose a strawman artifact (e.g. SRS, design)
seek team enhancement & acceptance
ensure designated artifact maintained & observed
maintain corresponding metrics if applicable
4. Designate a backup for each leader as per
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Peer Organizations for Larger Projects
Team of leaders
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Table 2.1
Matrixed
organization
Airline
reserv.
project
Bank
accountg.
project
Molecular
analysis
project
Fluid
mechanics
project
Al Pruitt
Full time
Quinn
Parker
Half time
Ruth Pella
Full time
Fred
Parsons
Full time
Marketing
dpt
Oscar Mart
Full time
Pete
Merrill
Full time
Sue More
Half time
Elton
Marston
Full time
Engineering dpt
Hal
Egberts
......
Ben
Ehrlich
......
Mary
Ericson
.....
Len Engels
.....
Project
management dpt
Functional
Unit
Project
4. Identifying and retiring risks
The Four Risk Activities
(1) Identification
Mindset: try to continually identify risks
(2) Retirement planning
(3) Prioritization
(4) Retirement or mitigation
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Risk Sources Ordered by Importance (Keil, Cule, Lyytinen, Schmidt)
1. Lack of top management commitment
2. Failure to gain user commitment
3. Misunderstanding of requirements
4. Inadequate user involvement
5. Failure to manage end-user expectations
6. Changing scope and/or objectives
7. ….
The Risk Management Mindset
Identification
Retirement
2. “Java
skills not
high
enough.”
Project
finish
Project
finish
Risk 2
Risk 2
Risk 1
1. “May not be
possible to
superimpose
images
adequately.”
2. Retirement
by avoidance:
Use C++
Project
start
Risk 1
1. Retirement
by conquest:
Demonstrate
image superimposition
Project
start
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Graphics reproduced with permission from Corel.
Likelihood
1-10
Impact
1-10
Retirement cost
1-10
1 = least
likely
1 = least
impact
1 = lowest
retirement
cost
The
highest
priority
risk
10
(most
likely)
10
(most
impact)
1
(lowest
retiremen
t cost)
(11-10)
*(11-10)
*1
1
The
lowest
priority
risk
1
(least
likely)
1
(least
impact)
10
(highest
retiremen
t cost)
(11-1)
*(11-1)
*10
1000
Table 2.2
A way to
compute
risk
priorities
Priority
computation
Resulting
priority
Lowest
number
handled
first
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Table 2.3 Sample Risk Analysis for Encounter Case Study
#
1
Risk title
(details given
above)
Superimposing
images
Likelihood
1-10
Impact
1-10
Retirement
cost
1-10
1=least likely
1=least
impact
1=lowest
retirement
cost
3
10
1
Priority
3
9
6
8
Responsible
engineer
Target
completion
date
lowest
number
handled
first
8
Experiment with
Java images.
P. R.
2/1/99
80
H.T., K.M., V.I. and
L.D. to attend
training course
beginning 1/5/99 at
Ultra Training Corp,
obtain Java level 2
certification by
3/1/99 and level 3
certification by
4/15/99
H. L.
4/15/99
S.F.
Continual
...
...
2
Deficient
Java skills
Retirement / mitigation
plan
Alan Gray
may be
pulled off
this project
3
7
9
288
Susan Ferris to
inspect all of Alan's
work
...
...
...
...
...
...
.
.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Identify and Retire Risks
1.* Each team member spends 10 mins. exploring his or
her greatest fears for the project’s success
2.* Each member specifies these risks in concrete
language, weights them, writes retirement plans, (see
format above) & e-mails to the team leader
3.* Team leader integrates and prioritizes results
4.M Group spends 10 mins. seeking additional risks
5.M Team spends 10 mins. finalizing the risk table
– Designates responsible risk retirement engineers
6.** Responsible engineers do risk retirement work
7.M Team reviews risks for 10 mins. at weekly meetings
– responsible engineers report progress
– team discusses newly perceived risks and adds them
*:in advance of first meeting
M:
at meeting
**: between meetings
5. Choosing development tools
and support
Potential CASE Tool Components
• To support
project
management
– schedule
– work
breakdown
• To support
configuration
management
• For managing
requirements
• For drawing designs
– functional
– object-oriented
– use-case-based
• Tracing tools
– requirements to
designs
– designs to code
• To support testing
• To support
maintenance
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Graphics reproduced with permission from Corel.
Example of Build vs. Buy Decision-making: Game
Graphics engine
Build cost
Buy cost
(in thousands)
Comments
multi-year costs not accounted for
Supplies
$ 0
$40
Purchase Ajax engine
First-person perspective
$ 5
$ 0
Ajax has this feature
3-D
$10
$ 1
Customize Ajax application
Light reflection
$15
$10
___
$51
Customize Ajax application
___
TOTALS
$30
_________________
Build, do not buy
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Table 2.4 Example of method for deciding language choice
Weight
(1-10)
Benefit of
Language 1
1 to 10=best
Benefit of
Language 2
1 to 10=best
Internet-friendly
3
8
2
Familiarity to
development team
8
3
9
Compilation speed
5
2
8
Runtime speed on
processor p
1
7
3
3*8 + 8*3 +
5*2 + 1*7
= 65
3*2 + 8*9 +
5*8 + 1*3
= 121
Factor
Score
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
6. Creating schedules: high level planning
High Level Task Chart with Fixed Delivery Date:
Order of Completion
Month 1 Month 2 Month 3 Month 4 Month 5
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
SCMP complete
Milestones
Begin system testing (2)
SQAP complete
(1*) Delivery
SPMP rel. 1 complete
(3) Freeze requirements
Iteration 1
(4)
(6)
Iteration 2
Risk
identification &
retirement
(5)
Prep. for maintenance
* Indicated the order in which the parts of this table were built
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Create an Initial Schedule
1. Indicate the milestones your must observe
– usually includes delivery date
2. Back these up to introduce the milestones you need
– e.g., begin system testing well before delivery
3. Designate a time at which all requirements frozen
The remaining steps depend on the process used. We
will assume an iterative process.
4. Show first iteration: establishes minimal capability
– usually: keep it very modest, even trivial, in capability
– benefit: exercises the development process itself
5. Show task of identifying & retiring risks
– starting from project inception
6. Show unassigned time (e.g., week) near middle?
7. Complete the schedule
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Level Labor Allocation for Fixed Labor Total
Month 1 Month 2 Month 3 Month 4 Month 5
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Milestones
Freeze requirements
Karen
vacation
Iteration 1
Complete testing
Release to production
2 2 2 3 2 2 3
Hal
vacation
4 4 4 3 3 4 4 4 4 4 4 4
Iteration 2
Risk ID & retire 2 2 2 1 1 1
Given team size:
4
To be assigned
4 4 4 4 4 3 3 4 4 4 4 3 3 4 4 4 4 4 4 4
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
7. Integrating legacy applications
Add new features
(typically using
same language)
or Change features
(e.g., port to new
environment)
Resulting system
Repairs
Legacy
system
Legacy System Integration
Build new application
that uses legacy system
(possibly using
different language)
Legacy
system
New
features
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
New
application
8. Estimating costs: early calculations
$4
Range of cost estimates after
conceptualization phase,
based on actual cost of $1
Conceptualization
phase
$1
25c
Requirements
analysis
Range of
Errors in
Estimating
Eventual Cost
Range of cost estimates after
requirements analysis phase
$1
Design
$1
Implementation
$1
Integration/Test
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
$1
Typical Cost Estimation Roadmap
1A. Use comparisons with past jobs to estimate cost &
duration directly or to estimate lines of code.
and / or
1B. Use function point method to estimate lines of code
1B.1 Compute un-adjusted function points.
1B.2 Apply adjustment process.
2. Use lines of code estimates to compute labor and
duration using COCOMO formulas.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Function Point Computation for a Single Function (IFPUG)
External
Inquiries
(EIN)
External
Inputs
(EI)
Function
Logical
Logical
group
ofof
Logical
group
user
data
group
of
user
data
user data
External
Logical
Files (ELF)
file
file
file
Internal
Logical Files
(ILF)*
External
Outputs
(EO)
* Internal
logical
grouping of
user data
into files
Function Point Computations (IFPUG)
(Unadjusted -- to be followed by applying adjustment process)
PARAMETER
simple
complex
Ext. inputs EI
…3
or… 4 or ... 6 = ___
Ext. outputs EO
…4
or … 5 or ... 7 = ___
countTotal
Function Point Computations (IFPUG)
(Unadjusted -- to be followed by applying adjustment process)
PARAMETER
simple
complex
Ext. inputs EI
…3
or… 4 or ... 6 = ___
Ext. outputs EO
…4
or … 5 or ... 7 = ___
Ext. inquiries EIN
…3
or … 4 or ... 6 = ___
Int. logical files ILF ... 7
or …10 or ... 15 = ___
Ext. logical files ELF ... 5
or …7 or ... 10 = ___
countTotal
Unadjusted Function Point Computation for First
Encounter Functions:“Set up Player Character”
Simple
Medium
Complex Subcount factor count factor count factor totals
Ext. inputs
1
3
1
4
1
6
comments:
Name
Ready/move Qualities
Ext. outputs
0
4
0
5
0
7
Ext. inquiries
0
3
0
4
0
6
Int. logical files
1
7
0
10
0
15
comments:
Data about the user's character
Ext. interface files
1
5
0
7
0
10
comments:
Data about the user's character
2. Encounter foreign character
Simple
Medium
13
0
0
7
25
5
Complex Sub-
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Total
Total
Unadjusted Function Point Computation for Second
Encounter Functions: “Encounter Foreign Character”
Simple
Medium
Complex Subcount factor count factor count factor totals
Ext. inputs
0
3
0
4
Ext. outputs
1
4
0
5
comments:
Report on results
Ext. inquiries
0
3
0
4
Int. logical files
1
7
0
10
comments:
Data about the user's character
Ext. interface files
1
5
0
7
-- comments on above
Data about the user's character
0
0
6
7
0
4
0
0
6
15
0
7
0
10
5
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Total
16
General Characteristics for FP Adjustment 1-7
incidental
0
none
1
average
2
moderate
essential
3
4
significant
1. Requires backup/recovery?
2. Data communications required?
3. Distributed processing functions?
.....
5
Case
study
0-2
0-1
0
General Characteristics for FP Adjustment 1-7
incidental
0
1
none
1.
2.
3.
4.
5.
6.
7.
average
2
moderate
3
essential
4
5
significant
Requires backup/recovery?
Data communications required?
Distributed processing functions?
Performance critical?
Run on existing heavily utilized environmt.?
Requires on-line data entry?
5
Multiple screens for input? .... continued
Case
study
0-2
0-1
0
3-4
0-1
4-5
General Characteristics for FP Adjustment 8-14
incidental
0
none
1
average
2
moderate
3
essential
4
significant
8. Master fields updated on-line?
9. Inputs, outputs, inquiries of files complex?
10. Internal processing complex?
....
5 Case
study
3-4
1-2
1-4
General Characteristics for FP Adjustment 8-14
incidental
0
none
1
average
2
moderate
3
essential
4
significant
8. Master fields updated on-line?
9. Inputs, outputs, inquiries of files complex?
10. Internal processing complex?
11. Code designed for re-use?
12. Conversion and installation included?
13. Multiple installation in different orgs.?
14. Must facilitate change & ease-of-use
by user?
5 Case
study
3-4
1-2
1-3
2-4
0-2
1-3
4-5
Computation of Adjusted Function Points (IFPUG)
(Adjusted) Function points =
[ Unadjusted function points ] 
[ 0.65 + 0.01  ( total general characteristics ) ]
Unadjusted Function Point Scores for Video Store
Example
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
FP Adjustment Factors for Video Example
none
incidental
moderate
average
significant
essential
0
1
2
3
4
5
1.
2.
3.
4.
5.
6.
Requires backup/recovery?………………………….
Data communications required ?………...………….
Distributed processing functions ?………………….
Performance critical ?………………….…………….
Run on existing heavily utilized environment ?…….
Requires on-line data entry ?………………………..
....
4
0
0
3
1
5
FP Adjustment Factors for Video Example
none
incidental
moderate
average
significant
essential
0
1
2
3
4
5
1. Requires backup/recovery?………………………….
2. Data communications required ?………...………….
3. Distributed processing functions ?………………….
4. Performance critical ?………………….…………….
5. Run on existing heavily utilized environment ?…….
6. Requires on-line data entry ?………………………..
7. Multiple screens for input ?………………………….
8. Master fields updated on-line ?……………………..
9. Inputs, outputs, inquiries of files complex ?………..
10. Internal processing complex ?……………………….
11. Code designed for re-use ?…………………………...
12. Conversion and installation included ?……………..
13. Multiple installation in different orgs. ?…………….
14. Must facilitate change & ease-of-use by user ?……..
4
0
0
3
1
5
3
5
2
1
3
3
3
2
Total
35
9. Estimating effort and duration from lines of
code
Meaning of the COCOMO Formulas (Boehm)
(2) Duration for
increasing Effort*
( y b 2.5x 0.35 )
(1) Effort* for
increasing LOC
( y b 3x 1.12 )
exponent: < 1
>1
Applies to design through integration & test.
*“Effort” = total person-months required.
Basic COCOMO Formulae (Boehm)
Effort in Person-months
b
= a  KLOC
Duration = c  Effort d
Software Project
a
b
c
d
Organic
2.4 1.05 2.5 0.38
Semidetached
3.0 1.12 2.5 0.35
Embedded
3.6 1.20 2.5 0.32
Due to Boehm [Bo]
Computing COCOMO Case Study Models
a
K
b
2.4
2.4
4.2 1.05
300 1.05
c
P
Effort
LO
HI
d
Duration
LO
2.5
10 0.38
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
approx.
aK^b
10
1000
approx.
cP^d
6
Computing COCOMO Case Study Models
a
K
b
2.4
2.4
4.2 1.05
300 1.05
c
P
Effort
LO
HI
d
Duration
LO
HI
2.5
10 0.38
2.5 1000 0.38
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
approx.
aK^b
10
1000
approx.
cP^d
6
35
Estimate Cost and Duration Very Early in Project
1. Use the function point method to estimate
lines of code
2. Use Boehm’s formulas to estimate labor
required
3. Use the labor estimate and Boehm’s formula
to estimate duration
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
10. The Team Software Process
•
•
•
•
•
TSP Launch
Issues to Settle
(Humphrey)
Process to be used
Quality goals
Manner of tracking quality goals
How team will make decisions
What to do if quality goals not attained
– fallback positions
• What to do if plan not approved
– fallback positions
• Define team roles
• Assign team roles
Graphics reproduced with permission from Corel.
To Be Produced at Launches (Humphrey)
1.
2.
3.
4.
5.
Written team goals
Defined team roles
Process development plan
Quality plan
Project’s support plan
computers, software, personnel etc.
6.
7.
8.
9.
Overall development plan and schedule
Detailed plans for each engineer
Project risk assessment
Project status report
TSPi Cycle Structure (Humphrey)
Week
Milestones
Iteration 1
Iteration 2
1 1 1 1 1 1
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
Cycle 1 launch
Delivery
Cycle 2 launch
Cycle 3 launch
1. strategy
2. plan
3. requirements
4. design
5. implementation
6. test
7. postmortem
1. strat.
Iteration 3
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. strategy….
11. The Software Project Management Plan
1. Introduction
1.1 Project overview
1.2 Project deliverables
1.3 Evolution of the SPMP
1.4 Reference materials
1.5 Definitions and acronyms
2. Project organization
2.1 Process model
2.2 Organizational structure
2.3 Organizational boundaries
and interfaces
2.4 Project responsibilities
3. Managerial process
3.1 Managerial objectives &
priorities
....
IEEE 1058.1-1987 SPMP
Table of Contents
IEEE 1058.1-1987 SPMP Table of
Contents
3.2 Assumptions, dependencies
& constraints
3.3 Risk management
1. Introduction
3.4 Monitoring & controlling
1.1 Project overview
mechanisms
1.2 Project deliverables
3.5 Staffing plan
1.3 Evolution of the SPMP
4. Technical process
1.4 Reference materials
4.1 Methods, tools & techniques
1.5 Definitions and acronyms
4.2 Software documentation
2. Project organization
4.3 Project support functions
2.1 Process model
5. Work packages, schedule &
2.2 Organizational structure
budget
2.3 Organizational boundaries
5.1 Work packages
and interfaces
5.2 Dependencies
2.4 Project responsibilities
5.3 Resource requirements
3. Managerial process
5.4 Budget & resource allocation
3.1 Managerial objectives &
5.5 Schedule
priorities
12. Quality in project management
Table 2.5 Defects by Phase
Defects detected per ... ... 100
requirements, or ... design
diagram, or ... KLOC
This project / norm
Detailed
requirements
Phase
containing
defects
Design
Phase in which defects detected
Detailed
requirements
Design
Implementation
2/5
0.5 / 1.5
0.1 / 0.3
3/1
1/3
Implementation
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
2/2
Five Process Metric Examples
Compare each of the following with company
norms averaged over similar processes.
1.Number of defects per KLOC detected within x
weeks of delivery
2.Variance in schedule on each phase
actual duration - projected duration
projected duration
3.Variance in cost actual cost - projected cost
projected cost
4.Total design time / total programming time
should be at least 50% (Humphry)
5.Defect injection and detection rates per phase
e.g. “1 defect per class in detailed design phase”
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
IEEE 739-1989 Software Quality Assurance Plans Table of Contents Part 2 of 2
7. Test
-- can reference Software Test Documentation
8. Problem reporting & corrective
action
9. Tools, techniques and methodologies
-- can reference SPMP
10. Code control
-- reference SCMP
11. Media control
12. Supplier control
13. Records collection, maintenance &
retention
14. Training
15. Risk Management
-- can reference SPMP
Gather Process Metrics
1. Identify & define metrics team will use by phase;
include ... time spent on 1. research, 2. execution, 3. review
… size (e.g. lines of code)
… # defects detected per unit (e.g., lines of code)
include source
… quality self-assessment of each on scale of 1-10
maintain bell-shaped distribution
2. Document these in the SQAP
3. Accumulate historical data by phase
4. Decide where the metric data will be placed
– as the project progresses SQAP? SPMP? Appendix?
5. Designate engineers to manage collection by phase
– QA leader or phase leaders (e.g., design leader)
6. Schedule reviews of data for lessons learned
– Specify when and how to feed back improvement
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Requirements Document:
200 detailed requirements
Hours spent
Meeting
Research
Execution
Personal
Review
Inspection
0.5 x 4
4
5
3
6
% of total time
10%
20%
25%
15%
30%
% of total time: norm for
the organization
15%
15%
30%
15%
25%
Self-assessed quality 1-10
2
8
5
4
6
Defects per 100
N/A
N/A
N/A
5
6
Defects per 100:
organization norm
N/A
N/A
N/A
3
4
Hours spent per detailed
requirement
0.01
0.02
0.025
0.015
0.03
Hours spent per detailed
requirement: organization
norm
0.02
0.02
0.04
0.01
0.03
Process improvement
Summary
Improve
strawman
brought to
meeting
Spend 10%
more time
executing
Table 2.6 Project Metric
Collection for phases
Productivity: 200/22 = 9.9 detailed requirements per hour
Probable remaining defect rate: 6/4´[organizational norm of 0.8 per hundred] = 1.2 per 100
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
13. Process improvement and the Capability
Maturity Model
Table 2.7 Example of Process Comparison
Process
Motor control applications
Waterfall
Spiral, 2-4
iterations
Spiral, 5-10
iterations
... requirements time
4.2
3.2
2.4
... architecture time
3.1
2.5
3.7
... detailed design time
1.1
1.1
2.2
... implementation time
1.0
2.1
3.5
TOTAL
9.4
8.9
11.8
Company average -- Defects per
thousand source lines of code at
delivery time injected at ...
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Feed Back Process/Project Improvement
1. Decompose the process or sub-process being
measured into Preparation, Execution and Review
– include Research if learning about the procedure
2. Note time taken, assess degree of quality for each
part on a 1-10 scale, count defects
– try to enforce a curve
3. Compute quality / (percent time taken)
4. Compare team’s performance against existing
data, if available
5. Use data to improve next sub-process
– note poorest values first e.g., low quality/(percent time)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Table 2.8
Measuring Team
Phase
Performance
% time
Quality (0 to
10)*
If low,
investigate
Quality/(%
time)
If low,
investigate
Typical?
Action
For each part ...
Preparation
Execution
Review
45
30
25
6
2
investigate
6
0.13
investigate
0.07
investigate
0.24
No
Joe lost specs
Yes
Yes
Schedule 20% more
time for execution,
taken equally from
other phases
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
14. Miscellaneous tools and techniques for project
management Model
Remote Team Options
• Same office area
+ ideal for group communication
- labor rates sub-optimal
• Same city, different offices
communication fair
• Same country, different cities
- communication difficult
+ common culture
• Multi-country
- communication most difficult
- culture issues problematical
+ labor rates optimal
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Graphics reproduced with permission from Corel.
Non-Extreme
vs
Extreme Programming
• Limited customer contact
• Customer on team
• Central up-front design
• Open evolving design
• Build for the future too
• Evolve; just in time
• Complex implementation
• Radical simplicity
• Tasks assigned
• Tasks self-chosen
• Developers in isolation
• Pair programming
• Infrequent integration
• Continuous integration
• Limited communication
• Continual
communication
Adapted from Andserson, A., et al, "At Chrysler, Objects Pay", Distributed Computing, October 1998
Triage in Project Management
• Among top items in importance?
– if so, place it in do at once category
• otherwise Could we ignore without
substantially affecting project?
– if so, place it in last to do category
• otherwise ……
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Triage in Project Management
• Among top items in importance?
– if so, place it in do at once category
• otherwise Could we ignore without
substantially affecting project?
– if so, place it in last to do category
• otherwise (do not spend decision time
on this)
– place in middle category
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
16. Summary of the project management process
Summary
• Project management: “silver bullet”?
• “People” aspects co-equal technical
• Specify SPMP
• Define and retire risks
• Estimate costs with several methods
– expect to revisit and refine
– use ranges at this stage
• Schedule project with appropriate detail
• Maintain a balance among cost, schedule, quality
and functionality
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Graphics reproduced with permission from Corel.
SPMP for the Encounter video game
Gaming Industries
Consolidated
President
IV&V
...
VP Marketing
...
...
VP Engineering
Software
Engineering
Labs
Game Lab
Game 123
Encounter
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
SQA
Table 2.9 Encounter Project Responsibilties
Member
Team
leader
Liaison
Responsibility
VP
Engineer
ing
Docume
nt
Responsi
-bility
SPMP
CM
Leader
SCMP
QA
leader
SQAP
STP
Requirements
manageme
nt leader
Design
leader
Marketing
Software
engineeri
ng lab
SRS
SDD
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Implementati
on Leader
Code base
Program Monitoring & Control
Leader
Responsibilty
Report at weekly meeting
Circulate weekly report
Circulate biweekly report
Circulate monthly report
*Report formats
1
2
3
4
X
Facilitator
Marketing
QA Game lab
Risk
liaison
liaison liaison retirement
X
X
3*
X
4*
1*
see
see
see
see
CI
CI
CI
CI
2*
34: "monthly project status form"
87: "monthly marketing status form"
344: "weekly QA status form"
48: "biweekly game lab result form"
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Table 2.11
Encounter
Staffing
Plan
Team
Leader
CM
Leader.
QA
Leader
Requ.
Mngmnt
Leader
Design
Leader
Implementation
Leader
Name
Ed Braun
X
Al Pruitt
X
X
Fern Tryfill
X
Hal Furnass
X
Karen Peters
Liaison with
X
VP Eng.
Marketing
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Soft. Eng.
Lab
Work Breakdown
Structure
Excluding Secretarial
Month 1
Month 2
Month 3
Month 4
Month 5
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
SCMP
SQAP
Milestones
Complete testing
Freeze requirements
SPMP rel. 1
Delivery
Iteration 1
Tasks
Iteration 2
Risk I&R
E. Braude
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
J. Pruitt
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1 1
F. Tryfill
1
1
1
1
1
1
1
1
1
1
1
1
1
H. Furnass
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1 1
1
1 1
K. Peters
1
1
1
1
1
1
1
1
1
1
1 1
1
1 1
F. Smith (tech support)
TOTAL
.5 .5 .5 .5
1
1 1
.5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5
5.5 5.5 5.5 5.5 5.5 5.5 5.5 5.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 3.5 3.5
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Method*
Minimum
Maximum
(1)
7.5**
170
(2)
4.2
300
(3)
11.4
46
1.9-2.3 for two identified functions ´ 6-20
times as many in complete application
Most
conservative
11.4
300
Maximum of minimums and maximum of
maximums.
Least
conservative
4.2
46
Minimum of minimums and minimum of
maximums.
Widest range
4.2
300
Minimum of minimums and maximum of
maximums.
Narrowest
range
11.4
46
Maximum of minimums and minimum of
maximums.
Comment
Table 2.12 Very Rough Estimate
of Application Size Prior to
Requirements Analysis
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
High Level Task Chart with Fixed Delivery Date:
Order of Completion
Month 1 Month 2 Month 3 Month 4 Month 5
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
SCMP complete
Milestones
Begin system testing (2)
SQAP complete
(1*) Delivery
SPMP rel. 1 complete
(3) Freeze requirements
Iteration 1
(4)
(6)
Iteration 2
Risk
identification &
retirement
(5)
Prep. for maintenance
* Indicated the order in which the parts of this table were built
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Software quality assurance plan
Part 2 of 2
1. Defect Number:
2. Proposer:
3. Documents / sections affected:__________
Source code affected*: 4. package(s)_______
Problem
5. class(es) ____6. method(s) ______
Reporting
7.Severity: ____8. Type: _____
Form
9. Phase injected**:
Req• Arch• Dtld.Dsg• Code• Int•
10. Detailed description: ___________________
11. Resolution: ____ 12. Status closed / open:__
Sign-off: 13. Description and plan inspected: __
14. Resolution code and test plan inspected: ___
15. Change approved for incorporation: ______
* for source code defects **earliest phase with the defect
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.