2 PROJECT MANAGEMENT. Plan project Integrate & test system Analyze requirements Design Maintain Test...
Preview:
Citation preview
- Slide 1
- 2 PROJECT MANAGEMENT
- Slide 2
- Plan project Integrate & test system Analyze requirements
Design Maintain Test unitsImplement Software Engineering Roadmap:
Chapter 2 Focus Corporate practices Adapted from Software
Engineering: An Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
- Slide 3
- Development process - when to do what phase - document: SPMP
Management structure - hierarchical, peer,... Risk identification
& retirement Plan project Integrate & test system Analyze
requirements Design Maintain Test unitsImplement Software
Engineering Roadmap: Chapter 2 Focus Corporate practices
Development phases Schedule Cost estimate SPMP Adapted from
Software Engineering: An Object-Oriented Perspective by Eric J.
Braude (Wiley 2001), with permission.
- Slide 4
- 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.
- Slide 5
- 1. Introduction to project management
- Slide 6
- 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..... Adapted from Software Engineering: An
Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with
permission.
- Slide 7
- 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 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.
- Slide 8
- Bullseye Figure for Project Variables cost capabilityduration
defect density Target : $70K Target : 30 wks Target : 4
defects/Kloc Target: 100% Adapted from Software Engineering: An
Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with
permission.
- Slide 9
- Bullseye Figure for Project Variables cost capabilityduration
defect density Target : $70K Actual: 100% Target : 30 wks Target :
4 defects/Kloc this project Actual: 1 defect/Kloc Actual: 20 wks
Actual: $90K Target: 100% Adapted from Software Engineering: An
Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with
permission.
- Slide 10
- 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.
- Slide 11
- 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 6. Develop staffing plan -- see section
3.5 of case study 1 5. Develop schedule (times at which the work
portions are to be performed) -- see section 6 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.
- Slide 12
- 2. Managing people
- Slide 13
- 1.* Distribute start time, end time, and agenda with
approximate times (see figure tbd) list important items first 2.*
Ensure strawman items prepared 3. Start on time 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. Plan and Execute Meetings * 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.
- Slide 14
- 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 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.
- Slide 15
- 3. Options for organizing personnel
- Slide 16
- Optimal Size for Interaction (Approximate) Number of people
with whom developer must frequently interact Developer communicates
regularly with no one. No communication time lost, but developer is
too isolated and has no help. Key:= engineer 3 Effectiveness per
developer Adapted from Software Engineering: An Object-Oriented
Perspective by Eric J. Braude (Wiley 2001), with permission.
- Slide 17
- Optimal Size for Interaction (Approximate) Number of people
with whom developer must frequently interact Developer communicates
regularly with eleven people. Communication time outweighs benefits
of interaction Developer communicates regularly with no one. No
communication time lost, but developer is too isolated and has no
help. Key:= engineer Approximate optimal range 37 Effectiveness per
developer Adapted from Software Engineering: An Object-Oriented
Perspective by Eric J. Braude (Wiley 2001), with permission.
- Slide 18
- Hierarchical Project Management Organizations Larger
Projects:Smaller Projects: No separate Marketing? No separate QA
organization? 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.
- Slide 19
- Horizontal Project Management Organizations Gil Warner Team
leader Ian Corliss Team member Nel Tremont Team member Fran Smith
Team member Team facilitator? Adapted from Software Engineering: An
Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with
permission.
- Slide 20
- 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.
- Slide 21
- Peer Organizations for Larger Projects Team of leaders Adapted
from Software Engineering: An Object-Oriented Perspective by Eric
J. Braude (Wiley 2001), with permission.
- Slide 22
- Table 2.1 Matrixed organization Project Airline reserv. project
Bank accountg. project Molecular analysis project Fluid mechanics
project Func- tional Unit Project manage- ment dpt 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 Engineer- ing dpt Hal
Egberts...... Ben Ehrlich...... Mary Ericson..... Len Engels.....
Table 2.1 Matrixed organization
- Slide 23
- 4. Identifying and retiring risks
- Slide 24
- 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.
- Slide 25
- 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. .
- Slide 26
- Project finish The Risk Management Mindset Project start
IdentificationRetirement 2. Java skills not high enough. 1. May not
be possible to superimpose images adequately. 1. Retirement by
conquest: Demonstrate image super- imposition Risk 1 Risk 2 Risk 1
Project finish Risk 2 2. Retirement by avoidance: Use C++ Project
start Graphics reproduced with permission from Corel.Adapted from
Software Engineering: An Object-Oriented Perspective by Eric J.
Braude (Wiley 2001), with permission.
- Slide 27
- Likelihood 1-10 1 = least likely Impact 1-10 1 = least impact
Retire- ment cost 1-10 1 = lowest retirement cost Priority
computation Resulting priority Lowest number handled first 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
Adapted from Software Engineering: An Object-Oriented Perspective
by Eric J. Braude (Wiley 2001), with permission.
- Slide 28
- # Risk title (details given above) Like- lihood 1-10 1=least
likely Im- pact 1-10 1=least impact Retire- ment cost 1-10 1=lowest
retirement cost Pri- ority lowest number handled first Retirement /
mitigation plan Respon- sible engineer Target com- pletion date 1
Super- imposing images 31018 Experiment with Java images. P.
R.2/1/99 2 Deficient Java skills 96880 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 3 Alan Gray may be pulled off
this project 379288 Susan Ferris to inspect all of Alan's work S.F.
Contin- ual.... Table 2.3 Sample Risk Analysis for Encounter Case
Study Adapted from Software Engineering: An Object-Oriented
Perspective by Eric J. Braude (Wiley 2001), with permission.
- Slide 29
- *:in advance of first meeting M : at meeting **: between
meetings Identify and Retire Risks 1.* Each team member spends 10
mins. exploring his or her greatest fears for the projects 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
- Slide 30
- 5. Choosing development tools and support
- Slide 31
- 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.
- Slide 32
- Example of Build vs. Buy Decision-making: Game Graphics engine
Build costBuy cost Comments (in thousands) 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 Customize Ajax application
______ _________________ TOTALS$30$51 Build, do not buy Adapted
from Software Engineering: An Object-Oriented Perspective by Eric
J. Braude (Wiley 2001), with permission.
- Slide 33
- Factor Weight (1-10) Benefit of Language 1 1 to 10=best Benefit
of Language 2 1 to 10=best Internet-friendly 382 Familiarity to
development team 839 Compilation speed 528 Runtime speed on
processor p 173 Score 3*8 + 8*3 + 5*2 + 1*7 = 65 3*2 + 8*9 + 5*8 +
1*3 = 121 Table 2.4 Example of method for deciding language choice
Adapted from Software Engineering: An Object-Oriented Perspective
by Eric J. Braude (Wiley 2001), with permission.
- Slide 34
- 6. Creating schedules: high level planning
- Slide 35
- High Level Task Chart with Fixed Delivery Date: Order of
Completion Month 1 1234 Month 2 1234 Month 3 1234 Month 4 1234
Month 5 1234 Milestones(1 * ) Delivery Begin system testing
Iteration 1 Iteration 2 (6) (4) (3) Freeze requirements Risk
identification & retirement (5) * Indicated the order in which
the parts of this table were built SCMP complete SQAP complete SPMP
rel. 1 complete (2) Prep. for maintenance Adapted from Software
Engineering: An Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
- Slide 36
- 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.
- Slide 37
- Level Labor Allocation for Fixed Labor Total Month 1 1234 Month
2 1234 Month 3 1234 Month 4 1234 Month 5 1234 Milestones Release to
production Complete testing Iteration 1 Iteration 2 Freeze
requirements Risk ID & retire 2223223 222111 444334
444443344443344444 44444 44 4 Given team size: To be assigned 4 Hal
vacation Karen vacation Adapted from Software Engineering: An
Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with
permission.
- Slide 38
- 7. Integrating legacy applications
- Slide 39
- Resulting system Legacy System Integration Legacy system New
features New application Add new features (typically using same
language) or Change features (e.g., port to new environment) Build
new application that uses legacy system (possibly using different
language) Legacy system Repairs Adapted from Software Engineering:
An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with
permission.
- Slide 40
- 8. Estimating costs: early calculations
- Slide 41
- Range of cost estimates after conceptualization phase, based on
actual cost of $1 Integration/Test Design Implementation
Requirements analysis $1 25c $4 $1 Conceptual- ization phase Range
of cost estimates after requirements analysis phase Range of Errors
in Estimating Eventual Cost Adapted from Software Engineering: An
Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with
permission.
- Slide 42
- 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.
- Slide 43
- Function Point Computation for a Single Function (IFPUG)
Function External Inputs (EI) External Inquiries (EIN) External
Outputs (EO) file External Logical Files (ELF) file Internal
Logical Files (ILF)* * Internal logical grouping of user data into
files Logical group of user data Logical group of user data Logical
group of user data
- Slide 44
- Function Point Computations (IFPUG) (Unadjusted -- to be
followed by applying adjustment process) Ext. inputs EI 3 or 4
or... 6 = ___ Ext. outputs EO 4 or 5 or... 7 = ___ PARAMETER simple
complex countTotal
- Slide 45
- Function Point Computations (IFPUG) (Unadjusted -- to be
followed by applying adjustment process) Ext. inputs EI 3 or 4
or... 6 = ___ Ext. outputs EO 4 or 5 or... 7 = ___ Ext. inquiries
EIN 3 or 4 or... 6 = ___ Ext. logical files ELF ... 5 or 7 or... 10
= ___ Int. logical files ILF ... 7 or 10 or... 15 = ___ PARAMETER
simple complex countTotal
- Slide 46
- Unadjusted Function Point Computation for First Encounter
Functions:Set up Player Character Adapted from Software
Engineering: An Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
- Slide 47
- Unadjusted Function Point Computation for Second Encounter
Functions: Encounter Foreign Character Adapted from Software
Engineering: An Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
- Slide 48
- General Characteristics for FP Adjustment 1-7 1. Requires
backup/recovery?0-2 2. Data communications required?0-1 3.
Distributed processing functions? 0..... 0 incidental average
essential 12345 Case study none moderate significant
- Slide 49
- General Characteristics for FP Adjustment 1-7 1. Requires
backup/recovery?0-2 2. Data communications required?0-1 3.
Distributed processing functions? 0 4. Performance critical?3-4 5.
Run on existing heavily utilized environmt.?0-1 6. Requires on-line
data entry? 5 7. Multiple screens for input?.... continued4-5 0
incidental average essential 12345 Case study none moderate
significant
- Slide 50
- 8. Master fields updated on-line?3-4 9. Inputs, outputs,
inquiries of files complex? 1-2 10. Internal processing
complex?1-4.. 012345 General Characteristics for FP Adjustment 8-14
incidental average essential Case study none moderate
significant
- Slide 51
- 8. Master fields updated on-line?3-4 9. Inputs, outputs,
inquiries of files complex? 1-2 10. Internal processing complex?1-3
11. Code designed for re-use?2-4 12. Conversion and installation
included?0-2 13. Multiple installation in different orgs.?1-3 14.
Must facilitate change & ease-of-use by user?4-5 012345 General
Characteristics for FP Adjustment 8-14 incidental average essential
Case study none moderate significant
- Slide 52
- Computation of Adjusted Function Points (IFPUG) (Adjusted)
Function points = [ Unadjusted function points ] [ 0.65 + 0.01 (
total general characteristics ) ]
- Slide 53
- Unadjusted Function Point Scores for Video Store Example
Adapted from Software Engineering: An Object-Oriented Perspective
by Eric J. Braude (Wiley 2001), with permission.
- Slide 54
- 012345 FP Adjustment Factors for Video Example 1. Requires
backup/recovery?.4 2. Data communications required ?....0 3.
Distributed processing functions ?.0 4. Performance critical ?..3
5. Run on existing heavily utilized environment ?.1 6. Requires
on-line data entry ?..5.... none incidental moderate average
significant essential
- Slide 55
- 012345 FP Adjustment Factors for Video Example 1. Requires
backup/recovery?.4 2. Data communications required ?....0 3.
Distributed processing functions ?.0 4. Performance critical ?..3
5. Run on existing heavily utilized environment ?.1 6. Requires
on-line data entry ?..5 7. Multiple screens for input ?.3 8. Master
fields updated on-line ?..5 9. Inputs, outputs, inquiries of files
complex ?..2 10. Internal processing complex ?.1 11. Code designed
for re-use ?...3 12. Conversion and installation included ?..3 13.
Multiple installation in different orgs. ?.3 14. Must facilitate
change & ease-of-use by user ?..2 none incidental moderate
average significant essential Total 35
- Slide 56
- 9. Estimating effort and duration from lines of code
- Slide 57
- Meaning of the COCOMO Formulas (Boehm) Applies to design
through integration & test. *Effort = total person-months
required. (2) Duration for increasing Effort* ( y b 2.5x 0.35 ) (1)
Effort* for increasing LOC ( y b 3x 1.12 ) exponent: < 1 >
1
- Slide 58
- Basic COCOMO Formulae (Boehm) Effort in Person-months = a KLOC
b Duration = c Effort d Software Project a b c d Organic2.41.05 2.5
0.38 Semidetached3.01.12 2.5 0.35 Embedded3.61.20 2.5 0.32 Due to
Boehm [Bo]
- Slide 59
- Computing COCOMO Case Study Models Adapted from Software
Engineering: An Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
- Slide 60
- Computing COCOMO Case Study Models Adapted from Software
Engineering: An Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
- Slide 61
- Estimate Cost and Duration Very Early in Project 1. Use the
function point method to estimate lines of code 2. Use Boehms
formulas to estimate labor required 3. Use the labor estimate and
Boehms formula to estimate duration Adapted from Software
Engineering: An Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
- Slide 62
- 10. The Team Software Process
- Slide 63
- TSP Launch Issues to Settle (Humphrey) Graphics reproduced with
permission from Corel. 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
- Slide 64
- To Be Produced at Launches (Humphrey) 1. Written team goals 2.
Defined team roles 3. Process development plan 4. Quality plan 5.
Projects support plan computers, software, personnel etc. 6.
Overall development plan and schedule 7. Detailed plans for each
engineer 8. Project risk assessment 9. Project status report
- Slide 65
- TSPi Cycle Structure (Humphrey) 123456789012345 1. strategy 2.
plan 3. requirements 4. design 5. implementation 6. test 7.
postmortem Milestones Delivery 1. strat. Iteration 1 Iteration 2 1.
strategy. Cycle 1 launch Week 1 Cycle 2 launch Cycle 3 launch 11111
Iteration 3 Adapted from Software Engineering: An Object-Oriented
Perspective by Eric J. Braude (Wiley 2001), with permission.
- Slide 66
- 11. The Software Project Management Plan
- Slide 67
- IEEE 1058.1-1987 SPMP Table of Contents 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..
- Slide 68
- IEEE 1058.1-1987 SPMP Table of Contents 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 3.2 Assumptions, dependencies & constraints
3.3 Risk management 3.4 Monitoring & controlling mechanisms 3.5
Staffing plan 4. Technical process 4.1 Methods, tools &
techniques 4.2 Software documentation 4.3 Project support functions
5. Work packages, schedule & budget 5.1 Work packages 5.2
Dependencies 5.3 Resource requirements 5.4 Budget & resource
allocation 5.5 Schedule
- Slide 69
- 12. Quality in project management
- Slide 70
- Defects detected per...... 100 requirements, or... design
diagram, or... KLOC This project / norm Phase in which defects
detected Detailed require- ments DesignImplemen- tation Phase
containing defects Detailed requirements 2 / 50.5 / 1.50.1 / 0.3
Design 3 / 11 / 3 Implementa- tion 2 / 2 Table 2.5 Defects by Phase
Adapted from Software Engineering: An Object-Oriented Perspective
by Eric J. Braude (Wiley 2001), with permission.
- Slide 71
- Five Process Metric Examples 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 Compare each of the
following with company norms averaged over similar processes.
Adapted from Software Engineering: An Object-Oriented Perspective
by Eric J. Braude (Wiley 2001), with permission.
- Slide 72
- 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
- Slide 73
- 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.
- Slide 74
- Requirements Document: 200 detailed requirements
MeetingResearchExecution Personal Review Inspection Hours spent0.5
x 44536 % of total time10%20%25%15%30% % of total time: norm for
the organization 15% 30%15%25% Self-assessed quality 1-1028546
Defects per 100N/A 56 Defects per 100: organization norm N/A 34
Hours spent per detailed requirement 0.010.020.0250.0150.03 Hours
spent per detailed requirement: organization norm 0.02 0.040.010.03
Process improvement Improve strawman brought to meeting Spend 10%
more time executing Summary 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 Table 2.6
Project Metric Collection for phases Adapted from Software
Engineering: An Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
- Slide 75
- 13. Process improvement and the Capability Maturity Model
- Slide 76
- Motor control applications Process WaterfallSpiral, 2-4
iterations Spiral, 5-10 iterations Company average -- Defects per
thousand source lines of code at delivery time injected at......
requirements time4.23.22.4... architecture time3.12.53.7...
detailed design time1.1 2.2... implementation time1.02.13.5
TOTAL9.48.911.8 Table 2.7 Example of Process Comparison Adapted
from Software Engineering: An Object-Oriented Perspective by Eric
J. Braude (Wiley 2001), with permission.
- Slide 77
- 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 teams 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.
- Slide 78
- For each part... PreparationExecutionReview % time 453025
Quality (0 to 10)* If low, investigate 6 2 investigate 6 Quality/(%
time) If low, investigate 0.13 investigate 0.07 investigate 0.24
Typical? No Joe lost specs Yes Action Schedule 20% more time for
execution, taken equally from other phases Table 2.8 Measuring Team
Phase Performance Adapted from Software Engineering: An
Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with
permission.
- Slide 79
- 14. Miscellaneous tools and techniques for project management
Model
- Slide 80
- 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.
- Slide 81
- Non-Extreme vs Extreme Programming Limited customer contact
Central up-front design Build for the future too Complex
implementation Tasks assigned Developers in isolation Infrequent
integration Limited communication Customer on team Open evolving
design Evolve; just in time Radical simplicity Tasks self-chosen
Pair programming Continuous integration Continual communication
Adapted from Andserson, A., et al, "At Chrysler, Objects Pay",
Distributed Computing, October 1998
- Slide 82
- 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.
- Slide 83
- 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.
- Slide 84
- 16. Summary of the project management process
- Slide 85
- 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.
- Slide 86
- SPMP for the Encounter video game
- Slide 87
- Gaming Industries Consolidated President VP EngineeringVP
Marketing... IV&V EncounterGame 123... SQA Game Lab... Software
Engineering Labs Adapted from Software Engineering: An
Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with
permission.
- Slide 88
- Member Team leader CM Leader QA leader Require- ments manageme
nt leader Design leader Implementati on Leader Liaison Respon-
sibility VP Engineer ing Marketing Software engineeri ng lab Docume
nt Responsi -bility SPMPSCMP SQAP STP SRSSDDCode base Table 2.9
Encounter Project Responsibilties Adapted from Software
Engineering: An Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
- Slide 89
- Program Monitoring & Control Adapted from Software
Engineering: An Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
- Slide 90
- Name Team Leader CM Leader. QA Leader Requ. Mngmnt Leader
Design Leader Implemen- tation Leader Ed BraunX X Al Pruitt X Fern
Tryfill X Hal Furnass X Karen Peters X Liaison withVP Eng.
Marketing Soft. Eng. Lab Table 2.11 Encounter Staffing Plan Adapted
from Software Engineering: An Object-Oriented Perspective by Eric
J. Braude (Wiley 2001), with permission.
- Slide 91
- Month 1 1234 Month 2 1234 Month 3 1234 Month 4 1234 Month 5
1234 Milestones Delivery Complete testing Iteration 1 Iteration 2
Freeze requirements Risk I&R SCMP SQAP SPMP rel. 1 E. Braude 1
1 1 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 Tasks Work Breakdown Structure Excluding Secretarial TOTAL
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 F. Smith (tech
support).5.5.5.5.5.5.5.5.5.5.5.5.5.5.5.5.5.5.5.5 Adapted from
Software Engineering: An Object-Oriented Perspective by Eric J.
Braude (Wiley 2001), with permission.
- Slide 92
- Method* Mini- mum Maxi- mum Comment (1)7.5**170 (2)4.2300
(3)11.446 1.9-2.3 for two identified functions 6-20 times as many
in complete application Most conservative 11.4300 Maximum of
minimums and maximum of maximums. Least conservative 4.246 Minimum
of minimums and minimum of maximums. Widest range 4.2300 Minimum of
minimums and maximum of maximums. Narrowest range 11.446 Maximum of
minimums and minimum of maximums. 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.
- Slide 93
- High Level Task Chart with Fixed Delivery Date: Order of
Completion Month 1 1234 Month 2 1234 Month 3 1234 Month 4 1234
Month 5 1234 Milestones(1 * ) Delivery Begin system testing
Iteration 1 Iteration 2 (6) (4) (3) Freeze requirements Risk
identification & retirement (5) * Indicated the order in which
the parts of this table were built SCMP complete SQAP complete SPMP
rel. 1 complete (2) Prep. for maintenance Adapted from Software
Engineering: An Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
- Slide 94
- Software quality assurance plan Part 2 of 2
- Slide 95
- 1. Defect Number: 2. Proposer: 3. Documents / sections
affected:__________ Source code affected*: 4. package(s)_______ 5.
class(es) ____6. method(s) ______ 7.Severity: ____8. Type: _____ 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: ______ Problem Reporting Form * 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.