Personal Software Process

1
Personal Software Process Day 2
CS4320 Fall 2002
2
Lecture Overview

• Review of PSP 0, 0.1
• Individual Planning (PSP1)
• Quality Management (PSP2)
• Transition to TSPi

3
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
4
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.

5
Effort Measurement

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

6
Size Measurement

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

7
Correlation Between Size and Effort
CMU 1994 Data
8
Defect Measurement

• 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).

9
The PSP0 Process Flow
10
The PSP0.1 Process

• Emphasizes making accurate and precise size
  measurements
• Incorporates measuring the size of the programs
  produced
• Accounts for various types of LOC in the programs
  produced
• Begins to look at process improvement
• The following elements are added
• Estimating and reporting software size
• Use of a coding standard
• Recording process problems and improvement ideas

11
Process Improvement Proposal

• 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

12
Coding and Counting Standards

• Coding and LOC counting standards are needed to
  write the PSP programs.
• Exercise R1 involves developing a counting
  standard. (See tables 4.2 and 4.3 in DSE.)
• Exercise R2 involves developing a coding
  standard. (See table C29 in DSE.)
• These standards are
• tailored to a students language and needs
• designed to make LOC counting easier
• The standards provide for the collection of
  consistent data.
• Consistent data is necessary for good estimates.

13
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

14
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

15
PSP0 Processes Summary

• Students establish a baseline process.
• Students learn to measure and record effort,
  size, and defect.
• Students collect historical data that will serve
  as a basis for planning in PSP1.

16
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

17
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
• size estimating template
• test report template

18
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

19
The PSP Estimating Strategy

• The PSP strategy for making estimates requires
  students to
• estimate the size of a job
• estimate the effort required
• base these estimates on their own data
• calculate the prediction intervals for their
  individual estimates
• This results in
• more accurate estimates
• students who are committed to their estimates

20
Size Estimating Accuracy

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

Effort Estimation Accuracy
Assignment Average
PSP Level Average
Assignment Number
1997 SEI Study
22
The PROBE Method

• The PSP uses the PROBE (PROxy-Based Estimating)
  method to estimate size and resources.
• PROBE addresses a basic estimating issue.
• Good size measures are detailed.
• At the beginning of a job, estimators generally
  dont have detailed size measures.
• With the PROBE method, students
• identify a suitable proxy for size
• use the size proxy to make 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
C Object Category-Size Table
27
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
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
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.
32
Size EstimatingTemplate

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

33
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
34
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
• schedule planning template
• These elements of PSP are embodied in the TSPi
  task and schedule planning activities.

35
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?

36
Task Planning Template (C47)

• 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

37
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

38
Example Task Template
39
Schedule Planning Template (C49)

• 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

40
Example
Hours Avail 40 .25 10
41
Am I behind schedule?
42
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).

43
Defect Removal Techniques

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

44
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

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

46
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)

47
The PSP Review Process 2

• Table 8.2 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.

48
Design Review Checklist

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

49
Code Review Checklist

• Table C58 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

50
PSP Quality Measures
51
AF/R
CMU 94 data
52
Test Defects/KLOC vs. A/F R
CMU 94 data
53
Yield
CMU 94 data
54
Productivity
CMU 94 data
55
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

56
Operational Specification

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

57
Functional Specification

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

58
Example Function Specification

59
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