PSP Principles - 1
‹The
quality of a software system is governed
by the quality of its worst components.
PSP och lite annat
Erik Lindström
elindstrom@noblestar.com
http://www.cs.umu.se/kurser/TDBB12/
‹The
quality of a software component is
governed by the individual who developed it.
‹This
is governed by your
†knowledge
†discipline
†commitment
Copyright © 2001, Erik Lindström
PSP Principles - 2
With a Stable PSP
‹As
‹You
software professionals you should
know your own performance.
‹You
should measure, track, and
analyze your work.
‹You
should learn from your
performance variations.
can
†estimate and
plan your work
your commitments
†resist unreasonable commitment pressures
†meet
‹You
will also
†understand
†be
your ability
better able to improve
‹You
should Incorporate these lessons
in your personal practices.
Copyright © 2001, Erik Lindström
Copyright © 2001, Erik Lindström
1
A PSP Also Provides
What is a PSP?
‹A
‹A
proven basis for developing and
practicing
industrial-strength
personal disciplines
discipline that shows you how to
improve your personal process
steps
†forms
†standards
‹A
‹A
‹The
‹A
data to continually improve the
productivity, quality, and predictability
of your work
personal process for developing software
†defined
measurement and analyses framework to
help you characterize your process
defined procedure to help you to improve
your performance
Copyright © 2001, Erik Lindström
The Benefits of the PSP - 1
PSP
‹
A process for individual developers
†
Well-defined process steps (scripts)
† Forms
† Instruction for filling in the forms
† Standards
‹
‹
Copyright © 2001, Erik Lindström
Framework for analysis
Tool for individual process improvements
‹Insight
†you
will better understand your strengths and
weaknesses
†you will be better able to maximize your assets
†the PSP will help you to objectively deal with your
weaknesses
Ó Developers find more errors
Ó Developers improve their estimations
Ó Developers improve productivity
Î
Improvements at “no” costs
Copyright © 2001, Erik Lindström
Copyright © 2001, Erik Lindström
2
The Benefits of the PSP - 2
The Benefits of the PSP - 3
‹Ideas
‹Improvement
†by defining
your process, you assert control over it
†you can then act like a process owner
†your critical facilities will be in gear
†you will unconsciously observe your working self
†you will see many ways to improve your process
and your performance
framework
†a
defined process provides a language for thinking
about your work
†you can better see how the process parts relate
†you can better focus on priority areas for
improvement
Copyright © 2001, Erik Lindström
Copyright © 2001, Erik Lindström
The Benefits of the PSP - 4
The Benefits of the PSP - 5
‹Personal
‹Accomplishments
control
†you
will have a planning framework
†you will have the data on which to base your plans
†your plans will be more reliable
†you will be better able to track your status
†you will be better able to manage your work
Copyright © 2001, Erik Lindström
and personal bests
†you
will recognize your personal bests
†you will better understand how to repeat and to
surpass them
†you will see where and how you have improved
†you will have your own personal improvement
goals
†you will have the satisfaction that comes with
knowing you are doing superior work
Copyright © 2001, Erik Lindström
3
PSP Overview
‹When
your team’s processes are
defined
Requirements
Planning
†you
Design
Scripts
Compile
perform better when they can
concentrate on the job and not worry
about being defensive.
Syfte
Handledning för PSP0 planering
Inträdeskrav
Problembeskrivning
Result
Plan
&
Summary
Post Mortem
Project and Process Data
Summary Report
Product
Copyright © 2001, Erik Lindström
Fas
Logs
Logs
Testing
‹Teams
Exempel på ett script
Plan
Coding
guide
can better back them up and support them
†they can better back you up and support you
†you will more precisely relate to each other
†you will no longer need to protect yourself from
your peers’ failures
†they won’t need to protect against your failures
logging (time / defects
The Benefits of the PSP - 6
Copyright © 2001, Erik Lindström
Tidslog
Namn:
Datum:
Program:
jubo
990428
Test_1
Projektplan sammanfattningsformuläret
Tidsloggning
1
Definiera
programkrav
Framställa eller skaffa ett kravdokument för
programmet
Datum
990428
Tid
Start
Stop
13:15
14:15
14:15
15:15
Minuter
Avbrott Delta
15
45
60
Fas
Kommentar
Planering Kort fikarast
Design
Säkerställa att kravdokumentet är klar och
motsägelsefri
Lösa alla frågor angående kravdokumentet
2
Uppskatta resurser
Göra den bästa möjliga uppskattningen av
tiden som krävs för att utveckla programmet
Utträdeskrav
Dokumenterade krav
Fullständig projektplan sammanfattning med
tidsuppskattning för utvecklingstid
Fullständiga tidsloggar
Copyright © 2001, Erik Lindström
Copyright © 2001, Erik Lindström
4
PSP0 Time Recording Log 1
PSP0 Time Recording Log 2
‹Reference
‹Stop
‹Header
‹Date
- Table C16
- name, date, and program
- Enter the current date.
‹Start
- Enter the time in minutes
when you start a project phase.
- Enter the time in minutes
when you stop work on a project phase,
even if you are not done with that
phase.
‹Interruption
time - Enter any time
you lost due to interruptions in the
start to stop period.
‹Delta
time - Enter the elapsed start
to stop time less the interruption time.
Copyright © 2001, Erik Lindström
PSP0 Time Recording Log 3
Fellog
Namn:
Datum:
Program:
‹Phase
†note
†use
Copyright © 2001, Erik Lindström
the phase on which you were working
the phase name
‹Comments
- describe
Datum
990428
jubo
990428
Test_1
Nummer
25
Feltyp
20
Införd
kodning
Borttagit
kompilering
Fix-tid (min)
1
Fixat fel
Införd
kompilering
Borttagit
kompilering
Fix-tid (min)
1
Fixat fel
25
Beskrivning: Glömd krulleparantes.
Datum
990428
Nummer
26
Feltyp
20
Beskrivning: Knappade in två krulleparantes vid felrättning.
†the
interruption
task you were doing
†anything else that significantly affects your work
†the
Copyright © 2001, Erik Lindström
Copyright © 2001, Erik Lindström
5
Defect Recording Log - 1
Defect Recording Log - 2
‹Reference
‹Type
‹Header
program
- Table C18
- enter the name, date, and
‹Date
- Enter the date when you
found and fixed the defect.
‹Number
- Enter a unique number for
this defect. Start each project with 1.
- Enter the defect type from
the defect type standard.
‹Inject
- Enter the phase during
which you judge the defect was
injected.
‹Remove
- Enter the phase in which
you found and fixed the defect.
Copyright © 2001, Erik Lindström
Copyright © 2001, Erik Lindström
Defect Recording Log - 3
Defect Type Standard - 1
‹Fix
‹The
‹Fix
‹While
time - Enter the time you took to fix
the defect. You may time it exactly or use
your best judgment.
defect - If this defect was injected
while fixing another defect, enter the
number of that defect or an X if you do not
know.
defect type standard provides a
general set of defect categories
you may replace this standard
with your own, it is generally wise to
stick with simple type definitions until
you have data to guide your changes
‹Note
- A defect is anything in the program
that must be changed for it to be properly
developed, enhanced, or used.
Copyright © 2001, Erik Lindström
Copyright © 2001, Erik Lindström
6
Defect Type Standard - 2
The PSP defect types are:
‹ 10 - Documentation
‹ 20 - Syntax
‹ 30 - Build, package
‹ 40 - Assignment
‹ 50 - Interface
‹ 60 - Checking
‹ 70 - Data
‹ 80 - Function
‹ 90 - System
‹100 - Environment
Copyright © 2001, Erik Lindström
PSP Results
‹
Projektplan och
sammanfattning
‹ Jämför
planen med uppnådda resultat
† Tid
per fas
† Kodstorlek
† Kvalitet
 Produkt
 Process
† Produktivitet
† Effektivitet
‹ Statistik
Copyright © 2001, Erik Lindström
Defect Detection in Compile
Many published case studies
†
†
†
†
†
†
SEI
DoD m m
Embry-Riddle Aeronautical University
Hawaii University
Lund universitet (Claes Wohlin)
OOPS! Often very few students (not Hawaii/Lund)
‹ Industry relevant (mainly USA and Japan)
‹ Results are generally positive
† Improved predictions



†
†
Development time
Program size
Quality of results
Improved quality
Improves development processes
See SEI´s web pages at http://www.sei.cmu.edu/psp/Results.htm
Copyright © 2001, Erik Lindström
Copyright © 2001, Erik Lindström
7
Defect Detection in Test
Improvements in Defect
Detection
See SEI´s web pages at http://www.sei.cmu.edu/psp/Results.htm
See SEI´s web pages at http://www.sei.cmu.edu/psp/Results.htm
Copyright © 2001, Erik Lindström
Problem med PSP
‹ Stel
Copyright © 2001, Erik Lindström
PSP Levels
process
PSP3
† Måste allt
vara klart innan första compile?
† Måsta alla fel loggas?
† Hur hanteras iterativ utveckling/prototyping?
‹ Utvecklare
Cyclic development
slutar använda PSP
PSP2
Code reviews
Design reviews
† Uppföljning?
† Koppling
till CMM?
‹ Datainsamling
† Manuell
problematisk
PSP1
Size estimating
Test report
datainsamling är opålitlig
datainsamling innebär etiska risker
† Automatisk
‹ Inga
verktyg som stödjer PSP fullt ut
Copyright © 2001, Erik Lindström
PSP0
Current process
Time recording
Defect recording
Defect type standard
PSP2.1
Design templates
PSP1.1
Task planning
Schedule planning
PSP0.1
Coding standard
Size measurement
Process improvement
proposal (PIP)
Copyright © 2001, Erik Lindström
8
Text Pages Versus Time
6000
120
5000
100
Time (hours)
Time (min)
C++ LOC Versus Development Time
4000
3000
2000
80
60
40
20
1000
0
0
0
200
400
600
0
800
Copyright © 2001, Erik Lindström
20
30
40
50
Copyright © 2001, Erik Lindström
Report LOC Versus Time
Relationship to Development
‹LOC
is a reasonably good measure for
development of source programs like
Java, C and C++.
‹Pages are an acceptable measure for
document development.
‹LOC is not an adequate measure for
reports or scripts.
70
60
Time (hours)
10
Pages
C++ LOC
50
40
30
20
10
0
0
2000
4000
Report LOC
Copyright © 2001, Erik Lindström
6000
8000
‹Some
other possible measures are function
points, screens, and modules.
Copyright © 2001, Erik Lindström
9
Machine Countable
The PSP Counting Standard
‹Size
‹Count
measurement is time consuming
and inaccurate.
counters can only work on
definable program characteristics.
end, if, then, else, etc.
†{, }, ;, ., etc.
†count declarations, directives, headers, etc.
‹Automated
‹Counters
can be complex:
†size
definition selected
†counting method
‹Do
not count blanks, comment lines,
automatically generated code, or reused code
‹Count
new and changed code for measuring
and estimating development productivity
Copyright © 2001, Erik Lindström
PSP0 Documents
‹ PSP0
Process Script
‹ PSP0 Planning Script
‹ PSP0 Development Script
‹ PSP0 Post-mortem Script
‹ PSP0 Project Plan Summary and
Instructions
‹ Time Recording Log and Instructions
‹ Defect Recording Log and
Instructions
‹ Defect Type Standard
Copyright © 2001, Erik Lindström
PSP3 Documents
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
Copyright © 2001, Erik Lindström
all statements:
†begin,
PSP3 Process Script
‹
PSP3 Planning Script
‹
‹
PSP3 High-level Design
Script
‹
‹
PSP3 High-level Design
Review Script
‹
‹
PSP3 Development Script
‹
PSP3 Post-mortem Script
PSP3 Project Plan Summary ‹
‹
and Instructions
Operational Scenario T&I1 ‹
Functional Specification T&I
State Specification T&I
Logic Specification T&I
PSP3 Design Review Checklist
Code Review Checklist
Task Planning T&I
Schedule Planning T&I
PROBE2 Estimating Script
Test Report T&I
Size Estimating T&I
PIP3 and Instructions
Coding Standard
Time Recording Log & I
Defect Recording Log & I
Defect Type Standard
1
2
3
T&I: Template and Instructions
PROBE: Proxy-based Estimation
PIP: Process Improvement Proposal
Copyright © 2001, Erik Lindström
10
CMM and PSP
5:
4:
3:
2:
1:
Optimized:
Process change management
Technology innovation
Defect prevention
Managed:
Quality management
Process measurement and analysis
Defined:
Peer reviews
Intergroup coordination
Software product engineering
Integrated software management
Training program
Organization process definition
Organization process focus
Repeatable:
Software configuration management
Software quality assurance
Software subcontract management
Software project tracking and oversight
Software project planning
Requirements management
PSP key process areas
Initial
Copyright © 2001, Erik Lindström
11