Personal Software Process

1
Personal Software Process

• CS4320
• Fall 2005

2
Agenda

• Watts Movie
• Intro to PSP

3
Rationale

• Understanding thru measurement and tracking (In
  G-d we trust, all others send data)
• Defined process based on experience
• Select appropriate methods using data
• Structure enhances teamwork, improves efficiency
• Act like engineers and not Soho artists

4
Important

• Keep in mind real PSP training involves a 40
  hour course that introduces each concept and then
  has you do a program implementing that concept.
• We are compressing that dramatically, so when you
  evaluate PSP, keep in mind the training aspect.

5
(No Transcript)
6
PSP Structure 2

• PSP0 establish a measured performance baseline
• PSP1 make size, resource, and schedule plans
• PSP2 learn defect and yield management
• PSP3 scale up PSP methods to larger projects
• The PSP can be extended to team development of
  large-scale software systems. It is a
  pre-requisite for the TSP.

7
PSP Structure 1
PSP3 Cyclic development
Team Software Process Requirements
Configuration management
Project Process Project management Quality
assurance
PSP2.1 Design templates
PSP2 Code reviews Design reviews
PSP1.1 Task planning Schedule planning
PSP1 Size estimating Test report
PSP components - forms, logs and templates -
process scripts - standards - benchmarks
PSP0.1 Coding standard Process improvement proposa
l Size measurement
PSP0 Current process Basic measures
8
Baseline Process

• Uses scripts 0 and 0.1
• Tracks Time by phase and interruption (B8)
• Tracks Defects by category, type, time to fix
  (B10)
• Time in minutes (rounded to whole, neverlt1)
• Phases of project
• Design, Code, Compile, Test
• Simple project plan, estimate development time,
  actuals on everything else
• 0.1 adds code size estimates, Base, Deleted,
  Modified, Added, Reused

9
Effort Measurement (B8)

• The PSP measures effort as time in minutes.
• appropriate for small programs
• easy to measure precisely
• Students keeps accurate records of time spent on
  each programming task.
• Interruption time is recorded and subtracted from
  time spent on development tasks.

10
Defect Measurement (B10)

• A PSP defect is
• something that must be changed to correct an
  error made in a software artifact (design, code,
  etc.)
• classified according to a defect type standard
• For each defect, students record the defect type,
  a description of the defect, and the fix time.
• All changes related to a single error are counted
  as one defect.
• Fix time is recorded in the phase in which the
  defect is removed (e.g., compile or test).

11
Size Measurement (B31)

• Size data is used in estimating development time
  and the expected number of defects.
• There are a number of criteria for good size
  measures.
• has good correlation with effort
• has a precise definition
• can be counted automatically
• is suitable for planning
• is sensitive to language, design, and development
  method
• A lines of code (LOC) measure satisfies most of
  the criteria for good size measures.
• The PSP uses LOC for measuring size.

12
Correlation Between Size and Effort
CMU 1994 Data
13
Code Metrics

• (B)Basethe LOC of the code (prev version)
  before project starts
• (D)Deletedthe LOC of the prev version that were
  deleted as not applicable to new project
• (M)Modifiedthe LOC of the prev version that were
  modified for the new project
• (A)Addedthe LOC that you created new for this
  project
• (R)Reusedthe LOC that were reused from other
  projects
• (N)Total NewChangedAddedModified
• (T)Total LOCThe LOC of the final project code
• Checks
• NAM
• A(T-(B-D)-R)

14
LOC Accounting 2

• 300

51 LOC

• 250

79 LOC

• 200

170 LOC
42 LOC
New and changed
Total

• 150

17 LOC

• 100

• 50

• 0

• Base

• Deleted

• Modified

• Added

• Reused

15
What gets counted?

• Code Counting Standard
• Varies by language
• Blank lines?
• Comments?
• Compound Statements?
• BE CONSISTENT!!!
• Normally Logical Lines of Code, javadoc
  comments, if, while, for, count 2
• i.e. if (c5) x7

16
Process Improvement Proposal (B19)

• The process improvement proposal (PIP) is used to
  record process problems and proposed improvements
  for future reference.
• The PIP holds process improvement information.
• PIP number
• problem description
• proposed solution
• notes and comments

17
PSP0.1 Project Plan Summary

• Adds estimated and actual LOC in summary form
• The types of LOC include
• base B
• deleted base D
• modified base M
• addednew and base A
• reused R
• total new and changed N
• total new reuse

18
PSP1 Objectives

• To introduce a structured method for making
  software size estimates and for estimating the
  time to develop a program
• To show how using personal historical data can
  produce more accurate estimates about their work
• To introduce a process for making task and
  schedule plans

19
The PSP1 Process

• The objective of PSP1 is to establish an orderly
  and repeatable procedure for developing software
  size and effort estimates.
• There are three new process elements for PSP1.
• PROBE size estimating method (B28)
• size estimating template (B31)
• test report template (B29)

20
Personal Planning Summary

• The PSP shows students how to estimate and plan
  their work.
• As students gain experience, they learn to make
  better estimates and plans.
• The keys to making better estimates and plans are
  to use
• relevant historical data
• statistically sound methods
• a defined estimating and planning process

21
PSP 1 Code Size Estimation

• Wideband-Delphi
• Group of Experts estimate tasks, assign times
• Facilitator tries to get convergence
• Divergence generates discussion of issues
• More accurate results achieved
• Fuzzy-Logic
• Compare to historical projects
• Requires large database

22
PSP Probe Method

• Proxy
• A person authorized to act for another an agent
  or substitute.
• The authority to act for another.
• The written authorization to act in place of
  another.
• PROxy-Based Estimating
• For example Homebuilding sq ft estimates

23
Size Estimating Proxies

• A good size estimating proxy is easy to visualize
  early in development
• correlates closely with program size and
  development time
• should also be a physical entity that can
  be measured
• For example, in the home construction business,
  the number and size for rooms is often used as a
  proxy to estimate construction costs.
• Standard project elements often make good
  software proxies.
• product components
• software objects, functions, or procedures
• user screens, reports, scripts, or files
• document pages or chapters

24
Objects as Proxies

• PROBE uses program objects/methods as proxies.
• Objects can be visualized early in development.
• Methods (functions and procedures) can often be
  estimated in the same way.
• Objects, functions, procedures, and their LOC
  can be automatically counted.
• Object category-size tables, constructed from
  historical data, can be used for estimating
  object size.

25
The PROBE Estimating Method
26
Sample Factor Table for PSP
27
Our Project Java Table
28
Statistically Based Estimates

• PROBE uses historical data and linear regression
  to relate estimates of object size to actual
  program size and actual development time.
• Linear regression provides the best fit, or
  minimum variance, of a line to these data.
• To use the regression method, you need
• a reasonable amount of historical data
• data that correlate

29
Linear Regression

• For PROBE size estimation, regression analysis is
  based on historical estimated object LOC (the x
  data) and actual new and changed LOC (the y
  data).
• The planned new and changed LOC (yk ) is
  computed from estimated object LOC (xk) using
  the formula
• where

yk????o??xk??1
30
Correlation

• In order for linear regression to give us
  meaningful results, the x and y data sets must
  correlate to each other (i.e., have a good
  straight-line fit).
• The degree to which two sets of data (x and y)
  correlate is given by the correlation
  coefficient (r).

31
Confidence

• r near 1 high positive correlation
• r near -1 high negative correlation
• r near 0 little correlation
• Correlation
• gt.9 high confidence
• 0.7lt gt0.9 adequate for planning, strong corr
• 0.5 lt gt0.7 use with caution, adequate corr
• 0.5 lt not reliable for planning

32
Size Estimating Accuracy
PROBE size
estimation begins
Assignment Average
Size Estimation Accuracy
PSP Level Average
1997 SEI Study
Assignment Number
33
Effort Estimating Accuracy

Effort Estimation Accuracy
Assignment Average
PSP Level Average
1997 SEI Study
Assignment Number
34
Identify and Size Software Objects

• Students first identify the objects/methods in
  their conceptual design.
• Students then judge the type and size of those
  objects.

Object/Method Type No. Meth. Rel. Size Obj
LOC Input_Data I/O 1 Large
22 List Data 3 Medium
27 Calc_Mean Cal. 1 Medium
11 Calc_SD Cal. 1 Medium
11 Print_Result I/O 1 Large 22
93
35
Estimating Size
Object/Method Type Obj LOC Input_Data I/O
22 List Data 27 Calc_Mean Calc
11 Calc_SD Calc 11 Print_Result I/O 22
93
Regression Parameters ??? 38 ??? 0.8 r2 0
.8 Est NC LOC ??? ??? Est obj LOC Est NC
LOC ???? 0??? 93 Est NC LOC ????LOC
Note The est obj LOC would typically include
estimated modifications (M) and additions (BA)
to the base code. For this example, there is no
base program.
36
Size EstimatingTemplate

• The size estimating
• Template
• guides the estimating process
• holds the estimate data

37
The PSP1.1 Process

• The objectives of PSP1.1 are to introduce and
  practice methods for
• making resource and schedule plans
• tracking performance against these plans
• judging likely project completion dates
• There are two new process elements.
• task planning template (B39)
• schedule planning template (B41)
• These elements of PSP are embodied in the TSPi
  task and schedule planning activities.

38
PSP 1.1

• Adds time estimation to size estimation, adds EV
• Compute available hours per week, Total
  utilization factor
• Determine tasks and record on Table B41 Schedule
  Planning Template
• Break out available project time by week
• Plan the task sequence
• Set task schedule
• Establish milestones

39
Time Estimation

• Correlate Actual Time to Estimated Size
• Assume Linear Relation

We use this to correct our estimate for
historical fluctuation. Again need at least
three old points. Otherwise, use personal
productivity (LOC/Hr). Time ß0 ß1 Size
40
Estimating Effort
Object/Method Type Obj LOC Input_Data I/O
22 List Data 27 Calc_Mean Calc
11 Calc_SD Calc 11 Print_Result I/O
22 93
Regression Parameters ??? 110 ??? 1.5 r2
0.7 Est Time ??? ??? Est obj LOC Est Time
110 1.5 93 Est Time 250 minutes
41
Project Planning

• What tasks do I need to do?
• WBS
• Process Descriptions
• What sequence can I do them?
• Parallel
• Dependencies
• How long does each task take?
• What is total project time required and critical
  path?
• How do I track and report on accomplishment?

42
Earned Value

• Assign a value to each task
• Credit that value when the task is done
• Each task is estimated by time
• EV is equal to tasks percent of total effort
• A 1000 hour project with a 15 hour task, that
  task has an EV 1.5
• Partially completed tasks get 0
• A solution to status tracking and 90 done problem

43
Task Planning Template (B39)

• Assign each task a number and enter on form.
• Estimate hours required for this task (Plan)
• Sum total hours for project and calculate
  cumulative hours (Plan)
• Compute planned value task hours/total hours
• Calculate Cumulative Planned Value
• How many 1/week too few, 1/day too many,
  2-4/week OK

44
Tracking Progress

• When task is completed (100 done!)
• Enter date completed
• The EV is entered by taking the plan value.
• The cumulative EV is computed

45
Example Task Template
46
Schedule Planning Template (B41)

• Compute number of hours available per week using
  utilization factor.
• Enter amount of work planned in hours for each
  week.
• Compute CPV by using task template to determine
  those things that should be 100 done by hours
  worked.
• Remember to adjust weeks by special events

47
Example
Hours Avail 40 .25 10
48
Am I behind schedule?
49
The PSP2 Process

• The objectives of PSP2 are to introduce
• design and code reviews
• methods for evaluating and improving the quality
  of your reviews
• There are three new process elements.
• PSP2 project plan summary
• PSP2 design review checklist
• PSP2 code review checklist

50
PSP 2

• Adds Design and Code Reviews
• Follow checklist for reviews
• Informal
• Individual
• PSP says review BEFORE compile
• Yield defects before compile/ defect after
  compile
• This may be hard to do on modern IDEs like
  Eclipse

51
Introduction to Software Quality

• High quality products must meet all user
  requirements.
• Quality software must be free of defects.
• In the PSP, the chief measure of product quality
  is the total defect density.
• The total defect density is measured as
  defects/KLOC (the number of defects removed in
  development per 1000 lines of code).

52
PSP Reviews

• The goal of PSP reviews is to get consistently
  high yield.
• review yield the percentage of defects in the
  product at review time that were found by the
  review
• process yield the percentage of defects found
  before the first compile.
• With practice, students can achieve consistently
  high process and review yields of around 70 to
  80.

53
Defect Removal Techniques

• Review a program.
• inspection
• walkthrough
• personal review
• Compile a program.
• Test a program.
• Where and how do you remove defects?

54
The PSP Review Process 1

• To have effective PSP personal reviews students
  must
• follow the processalways!
• use a personal checklist that is designed to find
  the defects they make
• devise a review strategy and use it
• review one product component at a time
• check for one topic at a time
• treat each check as a personal certification that
  the product is free of this defect
• measure their review (time and defects)

55
The PSP Review Process 2

• Table B52 is an example code review process.
• Phases include
• review
• correct
• check
• Each student should design their own checklist so
  that it supports their review process.

56
Design Review Checklist

• Table B60 is an example design review checklist.
• Items include
• completeness
• logic
• special cases
• functional use
• names
• standards

57
Code Review Checklist

• Table B52 is an example code review checklist for
  C.
• Items include
• completeness
• includes
• initialization
• calls
• names
• strings
• pointers
• output format
• pairs
• logic operators
• line-by-line check
• standards
• file open and close

58
PSP Quality Measures
59
AF/R
Appraisal COQ / Failure COQ Or Code review
time / Compile test time Relative time
spent finding defects before first compile lt1
finding most defects in testing. High
defects gt2 low defects
CMU 94 data
60
Test Defects/KLOC vs. A/F R
CMU 94 data
61
Yield ( defects found before compile)
CMU 94 data
62
Productivity
CMU 94 data
63
The PSP2.1 Process

• The objectives of PSP2.1 are to introduce
• additional measures for managing process quality
• design templates that provide an orderly
  framework and format for recording designs
• There are six new process elements.
• PSP2.1 project plan summary
• PSP2.1 design review checklist
• operational scenario template
• functional specification template
• state specification template
• logic specification template

64
PSP 2.1

• Adds design templates
• Operational Scenario Template (B61)
• Describes operational behavior of program
• Functional Specification (B63)
• Define Class interfaces for public methods
• State Specification (B65)
• Define states and transitions
• Logic Specification (B67)
• Pseudo-code for critical modules

65
Operational Specification

• Specify Scenarios
• Interactions between user and system
• Error conditions
• Each one accomplishes a goal
• Sound Familiar????

66
Example Operational Scenario
67
Functional Specification

• Specify first order logic postconditions of
  methods in a class.
• Specified as conditionaction
• and or

68
Example Function Specification

69
Logic Specification

• Pseudo-code for methods in classes
• Shows all includes, typedefs needed by pseudocode

State Specification

• Shows details of state machine implementing a
  method or class
• Defines states and their transitions and
  transition conditions

70
Logic Specification
Function Subtract Set INCLUDES ltiostreamgt
ltstringgt TYPE DEFINITIONS char
dataARRAY_SIZESTRING_LENGTH1 Declaration
int ASetSubtractSet(data D)
define ARRAY_SIZE 2
define STRING_LENGTH 32 Reference
Logic reference number
Program Logic
71
State Template Example
State Empty Description Set has no members
Attributes ListState 0

List Pos
0
Empty
Clear v Reset v Pop v StepForward v StepBack
FirstOnly
Push V AddSet size1
FirstOfSeveral
AddSet size gt 1
MiddleOfSeveral
Impossible
LastOfSeveral
Impossible
72
PSP 3

• Cyclic Development (Staged Delivery)
• Adds High-Level Design
• Bug Tracking Log
• REPLACED BY TSP!!!!!

73
Next

• So how do groups do this stuff?
• TSP Team Software Process