personal software process 2004.7.26 kaist se lab

Personal Software Process

2004.7.26

KAIST SE

Lab.

2004-07-26 2/98

Contents

Introduction of Personal Software Process

Exercise 1 : PSP0– Assignment #1

Exercise 2 : PSP0.1– Assignment #2, #3

2004-07-26 3/98

Introduction of PSP

2004-07-26 4/98

Problems(1/2)

You have to manage your work, assess your talent, and build your skills!

2004-07-26 5/98

Problems(2/2)

You need to understand your own abilities using your process

– To apply to your assigned tasks

– To manage your weaknesses

– To build on your strengths

You have to improve your own process to be had high quality

goalMore

aggressive goal

World-class runners know their best time for a mile, and they know the world record

2004-07-26 6/98

What is the PSP?

Self-improvement process – To help you control, manage, and improve your working way

Personal process for developing software– Defined steps

– Forms

– Standards

Measurement and analysis framework – To help you to characterize your process

Defined procedure to help you to improve your performance

2004-07-26 7/98

PSP Principles(1/2)

Quality of a software system is governed by the quality of the process used to develop and evolve it

Quality of a software system is determined by the quality of its worst components

Quality of a software component is governed by the individual who developed it

Individual performance is governed by the individual’s knowledge, discipline, and commitment

2004-07-26 8/98

PSP Principles(2/2)

As software professionals, you should know your own

performance

You should measure, track, and analyze your work

You should learn from your performance variations

You should incorporate lessons learned into your

personal practices

2004-07-26 9/98

Logic for the PSP

Software professionals will better understand what they do if they define, measure, and track their work

They will then have a defined process structure and measurable criteria for evaluating and learning from their own and others’ experiences

With this knowledge and experience, they can select those methods and practices that best suit their particular tasks and abilities

By using a customized set of orderly, consistently practiced, and high-quality personal practices, they will be more effective members of their development teams and projects

2004-07-26 10/98

What Does the PSP Provide?

Stable, mature PSP allows you to– Estimate and plan your work

– Understand your current ability to develop software

– Meet your commitments

– Resist unreasonable commitment pressures

– Gives the data and analysis techniques that you can use to determine • Which technologies to adopt • Which methods work best for you

PSP provides– Proven basis for developing and practicing industrial-strength personal

disciplines

– Discipline that shows you how to improve your personal process

– Data to continually improve the productivity, quality, and predictability of your work

2004-07-26 11/98

PSP maturity framework(1/2)

PSP0

Current processTime recording

Defect recordingDefect type standard

PSP0



PSP0.1

Cording standardSize measurement

Process improvement proposal

PSP0.1



PSP1

Size estimatingTesting report

PSP1

Size estimatingTesting report

PSP1.1

Task planningSchedule planning

PSP1.1

Task planningSchedule planning

PSP2

Code reviewsDesign reviews

PSP2

Code reviewsDesign reviews

PSP2.1

Design templates

PSP2.1

Design templates

PSP3

Cycle development

PSP3

Cycle development

Baseline Personal Process

Personal PlanningProcess

Personal Quality Management

CyclicPersonalProcess

2004-07-26 12/98

PSP maturity framework(2/2)

PSP0:– You establish a measured performance baseline

PSP1:– You make size, resource, and schedule plans

PSP2:– You practice defect and yield management

PSP3:– You scale up PSP methods to larger projects

2004-07-26 13/98

PSP strategy(1/4)

PSP0 : Baseline process– Provides a consistent basis for measuring progress and a define

d foundation on which to improve• Time recording

• Defect recording

• Defect type standard

– Should be your current process

– PSP0.1• Coding standard

• Size measurement

• Process improvement proposal(PIP)– Structured form to record process problems, experiences and improve

ment suggestions

2004-07-26 14/98

PSP strategy(2/4)

PSP1 : Personal planning process– Adds planning steps to PSP0

• Test report

• Size and resource estimating

– Reasons of making explicit and documented plans

• To help you understand the relation between the size of the

programs and the time

• To help you to make commitments you can meet

• To give you an orderly plan for doing the work

• To give you a framework for determining the status of your work

– PSP1.1

• Task and schedule planning

2004-07-26 15/98

PSP strategy(3/4)

PSP2 : Personal quality management process– Adds review techniques to PSP1 to help you find defects early

• Code reviews

• Design reviews

– Defect management with review techniques• Gathering and analyzing the defects found in compile and test for

your earlier programs

• Establishing review checklists

• Making your own process quality assessments

– PSP2.1 • Design templates

• Establishes design completeness criteria and examines various design verification and consistency techniques

2004-07-26 16/98

PSP strategy(4/4)

PSP3 : Cyclic personal process

– Apply PSP works to large projects• Strategy is to subdivide a larger program into PSP2-sized

pieces

2004-07-26 17/98

Team Software Process(TSP)

Framework and a process structure for building and guiding engineering teams that develop software

TSP contains– Team-building process

• Team goals, commitment, cohesion, and structure issues

– Team-working process • Engineering processes and practices used by the team

Prerequisite for a team to use the TSP – Understanding of the software engineering and process skills

taught in the PSP

2004-07-26 18/98

CMM(Capability Maturity Model)(1/2)

Developed by the SEI with the help of leading software groups

Characterizes the most effective large-scale software practices– Key process areas(KPAs) provide goals and example practices

Upgraded to CMMI(Capability Maturity Model Integration) from 2000– SEI no longer maintains CMM– Many industrial organizations have to change their SPI policy fro

m CMM-based to CMMI-based

2004-07-26 19/98

CMM(2/2)

CMM KPAs

Level 1- initialLevel 1- initial

Level 2- Repeatable

Software configuration managementSoftware quality assurance

Software subcontract managementSoftware project tracking and oversight

Software project planningRequirements management

Level 2- Repeatable




Level 3 – Defined

Peer reviewsIntergroup coordination

Software product engineeringIntegrated software management

Training programSoftware process definition

Software process focus

Level 3 – Defined





Level 4 – Managed

Quality managementQuantitative process management

Level 4 – Managed


Level 5 – Optimizing

Process change managementTechnology change management

Defect prevention



Defect prevention

2004-07-26 20/98

CMM and PSP

Level 1- initialLevel 1- initial

Level 2- Repeatable




Level 2- Repeatable




Level 3 – Defined





Level 3 – Defined





Level 4 – Managed


Level 4 – Managed




Defect prevention



Defect prevention

Not individual level

Its implications are better demonstrated in a small-team environment

Broader organizational issues

2004-07-26 21/98

PSP, TSP, and CMM

CMMSM - Builds organizational

capability

TSP - Builds quality products on cost and

schedule

PSP - Builds individual skill and

discipline

2004-07-26 22/98

PSP process flow

Requirements

Finished product

ProjectsummaryProject

summary

Project and processdata summary report

Planning

Design

Code

Compile

Test

PM

ScriptsScripts guideLogs

2004-07-26 23/98

Productivity and PSP : example(1/6)

Student 1– System engineer

– Experience : over 13 years, 20 KLOC of programs

– Uses C

Student 2– Software engineer

– Experience : over 11 years, 100 KLOC of programs

– Uses Ada

2004-07-26 24/98


Development Time

0

2

4

6

8

10

12

14

16

18

20

1A 2A 3A 4A 5A 6A 7A 8A 9A 10A

Program number

Hou

rs

Stu1

Stu2

2004-07-26 25/98


Program sizes

– Programs are in different languages

– LOC give some indication of the amount of development work involved

0

50

100

150

200

250

300

1A 2A 3A 4A 5A 6A 7A 8A 9A 10A

Program number

Line

s of

cod

e

Stu2

Stu1

2004-07-26 26/98


Different points between 2 students– From program 1A to 10A

Student1 Student2

Called for the user to enter file names Hard-coded the file name

Return the input back to the user to

ensure it was correct

Did not

Constructed a linked list and then did the

calculations

Did the calculations on the input data as

they were entered

Produced extensive comments No comments

Added a design description for each

program

Included only for 9A and 10A

2004-07-26 27/98


Development productivity

0

5

10

15

20

25

30

35

40

45

50

1A 2A 3A 4A 5A 6A 7A 8A 9A 10A

Program number

Line

s of

cod

e pe

r ho

ur

Stu2

Stu1

stable

fluctuate

2004-07-26 28/98


Test defects per KLOC

0

20

40

60

80

100

120

140

1A 2A 3A 4A 5A 6A 7A 8A 9A 10A

Program number

Def

ects

per

KLO

C

Stu2

Stu1

2004-07-26 29/98

Summary

PSP is a defined process to help you do better

work

PSP is not a magic answer to all your software

engineering problems

– You must make the improvements yourself!

2004-07-26 30/98

Exercise 1 : PSP0

PSP0



PSP0



2004-07-26 31/98

Contents

PSP0 process

PSP0 measure– Time record log

– Defect recording log

– Defect type standard

– PSP0 plan summary

Assignment#1 : JD scenario

2004-07-26 32/98

PSP0 Process

Purpose

– Provides the framework for gathering your initial

process data• Build a quantitative understanding of each step

Provides

– Convenient structure for doing small-scale tasks

– Framework for measuring these tasks

– Foundation for process improvement

2004-07-26 33/98

PSP0 Process

Requirements

Finished productProject and Process Data

Summary Report

Planning

Design Code Compile Test

Postmortem

Development

2004-07-26 34/98

PSP0 Process scriptPhaseNumber

Purpose To guide you in developing module-level programs

Entry Criteria • Problem description• PSP0 Project Plan Summary form• Time and Defect Recording Logs• Defect Type Standard• Stop watch (optional)

1 Planning • Produce or obtain a requirements statement.• Estimate the required development time.• Enter the plan data in the Project Plan Summary form.• Complete the Time Recording Log.

2 Development • Design the program.• Implement the design.• Compile the program and fix and log all defects found.• Test the program and fix and log all defects found.• Complete the Time Recording Log.

3 Postmortem Complete the Project Plan Summary form with actual time, defect, and size data.

Exit Criteria • A thoroughly tested program• Completed Project Plan Summary form with estimated and

actual data• Completed Defect and Time Recording Logs

2004-07-26 35/98

PSP0 Planning script

Phase Number

Purpose To guide the PSP planning process

Entry Criteria • Problem description• Project Plan Summary form• Time Recording Log

1 Program Requirements

• Produce or obtain a requirements statement for the program.• Ensure that the requirements statement is clear and

unambiguous.• Resolve any questions.

2 Estimate Resources

Make your best estimate of the time required to develop this program.

Exit Criteria • Documented requirements statement• Completed Project Plan Summary form with estimated

development time data• Completed Time Recording Log

2004-07-26 36/98

PSP0 Development scriptPhase Number

Purpose To guide the development of small programs

Entry Criteria • Requirements statement• Project Plan Summary form with planned development time• Time and Defect Recording Logs• Defect Type Standard

1 Design • Review the requirements and produce a design to meet them.• Record time in Time Recording Log.

2 Code • Implement the design.• Record in the Defect Recording Log any requirements or design

defects found.• Record time in Time Recording Log.

3 Compile • Compile the program until error-free.• Fix all defects found.• Record defects in Defect Recording Log.• Record time in Time Recording Log.

4 Test • Test until all tests run without error.• Fix all defects found.• Record defects in Defect Recording Log.• Record time in Time Recording Log.

Exit Criteria • A thoroughly tested program• Completed Defect and Time Recording Logs

2004-07-26 37/98

PSP0 Postmortem script

Phase Number

Purpose To guide the PSP postmortem process

Entry Criteria • Problem description and requirements statement• Project Plan Summary form with planned development time • Completed Time Recording Log • Completed Defect Recording Log • A tested and running program

1 Defects Injected • Determine from the Defect Recording Log the number of defects injected in each PSP0 phase.

• Enter this number under Defects Injected–Actual on the Project Plan Summary form.

2 Defects Removed • Determine from the Defect Recording Log the number of defects removed in each PSP0 phase.

• Enter this number under Defects Removed–Actual on the Project Plan Summary form.

3 Time • Review the completed Time Recording Log.• Enter the total time spent in each PSP0 phase in the Actual

column of the Project Plan Summary form.

Exit Criteria • A fully tested program• Completed Project Plan Summary form• Completed Defect and Time Recording Logs

2004-07-26 38/98

PSP0 measure

Time spent per phase– Time recording log

– Simple record of the clock time you spend in each part of the PSP process

Defects found per phase– Defect recording log

– Record data on every defect you find during compile and test

– Defect is counted every time you make a program change

Multiple-defect problem

2004-07-26 39/98

Time record log(1/2)

Header

– Enter name, date, instructor, and

program number

Date

– Enter the current date

Start

– Enter the time in minutes when

you start a project phase

Stop

– Enter the time in minutes when

you stop work on a project phase,

even if you are not done with that

phase

Table C16 Time Recording Log

Student DateInstructor Program #

Date Start Stop InterruptionTime

DeltaTime

Phase Comments

2004-07-26 40/98

Time record log(2/2)

Interruption time– Enter any time that you lost due to interruptions in the start to stop

period

Delta time– Enter the elapsed time less the interruption time (start to stop)

Phase– Note the phase on which you were working

– Use the phase name

Comments describe– Interruption, task you were doing, and anything else that significantly

affects your work

2004-07-26 41/98

Defect recording log(1/2)

Header

– Enter the name, date, instructor,

and program number

Date

– Enter the date when you found

and fixed the defect

Number

– Enter a unique number for this

defect

– Start each project with 1

Type

– Enter the defect type from the

defect type standard

Table C18 Defect Recording Log

Student DateInstructor Program #Date Number Type Inject Remove Fix Time Fix Defect

Description:

Date Number Type Inject Remove Fix Time Fix Defect

Description:


Description:


Description:


Description:


Description:


Description:


Description:

Defect Types10 Documentation 60 Checking20 Syntax 70 Data30 Build, Package 80 Function40 Assignment 90 System50 Interface 100 Environment

2004-07-26 42/98

Defect recording log(2/2) Inject

– Enter the phase during which you judge the defect was injected

Remove– Enter the phase in which you found and fixed the defect

Fix time– Enter the time that you took to both find and fix the defect

Fix defect– If this defect was injected while fixing another defect, enter the number of that defect

(or an X if you do not know)

Description– Enter explanation of what the defect was (not the symptom, but the defect!)

Note– Defect is anything in the program that must be changed for it to be properly developed,

enhanced, or used

2004-07-26 43/98

Defect type standard

Type Number Type Name Description

10 Documentation comments, messages

20 Syntax spelling, punctuation, typos, instruction formats

30 Build, Package change management, library, version control

40 Assignment declaration, duplicate names, scope, limits

50 Interface procedure calls and references, I/O, user formats

60 Checking error messages, inadequate checks

70 Data structure, content

80 Function logic, pointers, loops, recursion, computation, function defects

90 System configuration, timing, memory

100 Environment design, compile, test, or other support system problems

General set of defect categories

2004-07-26 44/98

PSP0 Plan Summary(1/2)

Header– Enter name, date, program,

instructor, and language

Enter your best estimate of the total time that the development will take

Enter the actual time in

minutes that you spent in

each phase

Table C14 PSP0 Project Plan Summary

Student DateProgram Program #Instructor Language

Time in Phase (min.) Plan Actual To Date To Date % Planning Design Code Compile Test Postmortem Total

Defects Injected Actual To Date To Date % Planning Design Code Compile Test Total Development

Defects Removed Actual To Date To Date % Planning Design Code Compile Test Total Development After Development

2004-07-26 45/98

PSP0 Plan Summary(2/2) Time to date

– Enter the total time spent in each phase to date

Time to date %– Enter the percent of the total To date time that was spent in each phase

Defects injected and removed– Enter the actual numbers of defects injected and removed in each phase

Defects to date– Enter the total defects injected and removed in each phase to date

Defects to date %– Enter the percent of the total To date defects injected and removed in each

phase

2004-07-26 46/98

Assignment #1 : JD scenario

30 minutes

2004-07-26 47/98

Summary

PSP0 measures – Time that you spend in each development phase

– Defects that you inject and find per phase

PSP0 uses– Standard formats for defect and time recording

PSP0 is– Framework for gathering your initial process data

2004-07-26 48/98

Exercise 2 : PSP0.1

PSP0



PSP0



PSP0.1



PSP0.1



2004-07-26 49/98

Contents

PSP0.1 Process

Planning

Size measurement

LOC counting standard template

Coding standard

Assignment#2 : Counting LOC

PSP0.1 project plan summary


Assignment#3 : PPS for JD’s program

2004-07-26 50/98

PSP0.1 Process

2004-07-26 51/98

PSP0.1 Process script additions

Additions to the PSP0.1 process scripts include new

steps for– Estimating and reporting software size

– Distributing development time over planned project phases

– Using a counting and coding standard

– Recording process problems and improvement ideas

2004-07-26 52/98

PSP0.1 Process scriptPhase Number

Purpose To guide you in developing module-level programs

Entry Criteria • Problem description• PSP0.1 Project Plan Summary form• Time and Defect Recording Logs• Defect Type Standard• Stop watch (optional)

1 Planning • Produce or obtain a requirements statement.• Estimate the total new and changed LOC required.• Estimate the required development time.• Enter the plan data on the Project Plan Summary form.• Complete the Time Recording Log.

2 Development • Design the program.• Implement the design.• Compile the program and fix and log all defects found.• Test the program and fix and log all defects found.• Complete the Time Recording Log.

3 Postmortem Complete the Project Plan Summary form with actual time, defect, and size data.

Exit Criteria • A thoroughly tested program• Completed Project Plan Summary form with estimated and actual data• Completed PIP forms• Completed Defect and Time Recording Logs

2004-07-26 53/98

PSP0.1 Planning script

Phase Number

Purpose To guide the PSP planning process

Entry Criteria • Problem description• PSP0.1 Project Plan Summary form• Time Recording Log

1 Program Requirements

• Produce or obtain a requirements statement for the program.• Ensure the requirements statement is clear and unambiguous.• Resolve any questions.

2 Size Estimate Make your best estimate of the total new and changed LOC required to develop this program.

3 ResourceEstimate

• Make your best estimate of the time required to develop this program.

• Using the To Date % from the most recently developed program as a guide, distribute the development time over the planned project phases.

Exit Criteria • Documented requirements statement• Project Plan Summary form with estimated program size and

development time data• Completed Time Log

2004-07-26 54/98

PSP0.1 Development scriptPhase Number

Purpose To guide the development of small programs

Entry Criteria • Requirements statement• Project Plan Summary form with estimated program size and development time

• Time and Defect Recording Logs• Defect Type Standard and Coding Standard

1 Design • Review the requirements and produce a design to meet them.• Record time in Time Recording Log.

2 Code • Implement the design following the Coding Standard.• Record in the Defect Recording Log any requirements or design defects

found.• Record time in Time Recording Log.

3 Compile • Compile the program until error-free.• Fix all defects found.• Record defects in Defect Recording Log.• Record time in Time Recording Log.

4 Test • Test until all tests run without error.• Fix all defects found.• Record defects in Defect Recording Log.• Record time in Time Recording Log.

Exit Criteria • A thoroughly tested program that conforms to the Coding Standard• Completed Defect and Time Recording Logs

2004-07-26 55/98

PSP0.1 Postmortem scriptPhase Number

Purpose To guide the PSP postmortem process

Entry Criteria • Problem description and requirements statement• Project Plan Summary form with planned program size and development time• Completed Time Recording Log • Completed Defect Recording Log • A tested and running program that conforms to the Coding Standard

1 Defects Injected • Determine from the Defect Recording Log the number of defects injected in each PSP0.1 phase.

• Enter this number under Defects Injected–Actual on the Project Plan Summary form.

2 Defects Removed • Determine from the Defect Recording Log the number of defects removed in each PSP0.1 phase.

• Enter this number under Defects Removed–Actual on the Project Plan Summary form.

3 Size • Count the LOC in the completed program.• Determine the base, reused, deleted, modified, added, total, total new and changed,

and new reused LOC.• Enter these data on the Project Plan Summary form.

4 Time • Review the completed Time Recording Log.• Enter the total time spent in each PSP0.1 phase in the Actual column of the Project Plan

Summary form.

Exit Criteria • A fully tested program that conforms to the Coding Standard• Completed Project Plan Summary form• Completed PIP forms describing process problems, improvement suggestions, and

lessons learned• Completed Defect and Time Recording Logs

2004-07-26 56/98

Planning

2004-07-26 57/98

Why make plans?

Plans – Allow you to make commitments that you can meet– Provide a basis for agreeing on the job– Guide your work– Help to track your progress– Ensure project completion

In mature software organizations, plans are used as– Basis for agreeing on the cost and schedule for a job– Organizing structure for doing the work– Framework for obtaining the required resources– Record of what was initially committed

2004-07-26 58/98

Project planning framework

Definerequirements

Produceconceptual

design

Estimatesize

Estimateresources

Produceschedule

Developproduct

Processanalysis

Resourcesavailable

Sizedatabase

Productivitydatabase

Customer needs

DeliveredProduct

TrackingReports

Management

Customer

Tasks

Item

Size, resource,schedule

data

2004-07-26 59/98

Size measurement

2004-07-26 60/98

Why measure size?

Size measures

– Help you to make better plans

– Assist you in tracking development

– Normalize other measures• Development resources

• Defect rates

2004-07-26 61/98

Size measurement criteria

Size measurements must be

– Related to development effort

– Precise

– Machine countable

– Suitable for early planning

2004-07-26 62/98

Size vs. development effort

Principal requirement– If the size measure is not directly related to development cost, it

is not worth using

There are many possible measures– Lines of code (LOC)

– Function points

– Pages, screens, scripts, reports etc.

Size measure should be sensitive to language, design, and development practice

2004-07-26 63/98

C++ LOC vs. development time

0

1000

2000

3000

4000

5000

6000

0 100 200 300 400 500 600 700 800

C++ LOC

Tim

e (m

in.)

2004-07-26 64/98

Pascal LOC vs. development time

0

2000

4000

6000

8000

10000

12000

14000

0 200 400 600 800 1000 1200 1400 1600 1800 2000

Pascal LOC

Tim

e (m

in.)

2004-07-26 65/98

Text Pages vs. time

Text Pages

0

20

40

60

80

100

120

0 5 10 15 20 25 30 35 40 45

Tim

e (h

ou

rs)

2004-07-26 66/98

Screen LOC vs. time

0

10

20

30

40

50

60

70

80

90

100

0 500 1000 1500 2000 2500 3000 3500 4000

Screen LOC

Tim

e (h

ou

rs)

2004-07-26 67/98

Precision and accuracy

Imprecise and inaccurate Precise and inaccurate

Imprecise and accurate Precise and accurate

x x

x

x

x

xx xx

x x

xx

x

x

x

x

x

xx

x x xx xx x

x

Precision– Deals with the granularity or level of detail in measure

Accuracy– Concerns the relation between an assertion and the actual fact

2004-07-26 68/98

Size measurement framework

Developed by SEI for describing software size measurements

Has two principal criteria– Communication

– Repeatability

Uses logical LOC metric– Statement specification

• Executable

• Nonexecutable

2004-07-26 69/98

Counting program size Counting lines

– Logical lines• Invariant to editing changes• Correlate with development effort• Uniquely definable• Complex to count

– Physical lines• Easy to count • Not invariant• Not uniquely definable

PSP uses – Defined coding standard

– Physical LOC counter• Physical line for each logical line

2004-07-26 70/98

Example of LOC accounting(1/2)

Version 0350 LOC

Enhance to version 1+ 125 new and changed LOC

Expected size350+125=475 LOC

What happened?

Measured size 450 LOC

2004-07-26 71/98

Example of LOC accounting(2/2)

Added Subtracted Base

Base V0 0

Deleted 0

Modified 0 0

Added 350

Total V0 LOC 350 -0 350

Deleted 0

Modified 25 25

Added 100

Final Product 125 -25 450

Total New and Changed LOC 475

2004-07-26 72/98

LOC counting standard

2004-07-26 73/98

LOC Counting Standard Template

Definition Name: Language:

Author: Date:

Count Type Type Comments

Physical/Logical

Statement Type Included Comments

Executable

Nonexecutable:

Declarations

Compiler Directives

Comments

On own lines

With source

Banners

Blank lines

Clarifications Examples/Cases

Nulls continues, no-ops, ...

Empty statements “;;”, lone ;’s, etc.

Generic instantiators

Begin...end when executable

Begin...end when not executable

Test conditions

Expression evaluation when used as sub program arguments

End symbols when terminating executable statements

End symbols when terminating declarations or bodies

Then, else, otherwise

Elseif

Keywords procedure division, interface, implementation

Labels branch destinations when on separate lines

LOC counting standard template

You can tailor it to fit your needs or language

2004-07-26 74/98

Completing the header

Example Pascal LOC Counting Standard

Definition Name: Example Pascal LOC std. Language: Pascal

Author: W.S. Humphrey Date: 12/20/93

The name you give this standard

The language you are using

Your name The date you produced this standard (or revision)

Complete the header as follows

2004-07-26 75/98

Count type

Choices are logical and physical LOC– Logical LOC counts language elements

– Physical LOC counts text lines

For this counting standard, you are counting logical LOC

Count Type Type Comments

Physical/Logical Logical

2004-07-26 76/98

Statement type

Use this section to define how you will count various

types of statements. Consider the following.– How are you going to count procedure declarations and function

prototypes?

– How will you count compiler directives?

– Will you count comments? Why or why not?

Statement Type Included Comments

Executable yes

Nonexecutable:

Declarations yes

Compiler Directives yes

Comments no

On own lines no

With source no

Banners no

Blank lines no

2004-07-26 77/98

Clarifications

A fully operational standard generally requires many

notes and comments

Use the clarification section for this purpose.Clarifications Examples/Cases

Nulls yes continues, no-ops, ...

Empty statements yes “;;”, lone ;’s, etc.

Generic instantiators

Begin...end note 1 when executable

Begin...end note 1 when not executable

Test conditions yes

Expression evaluation yes when used as sub program arguments

End symbols notes 1,2 when terminating executable statements

End symbols notes 1,2 when terminating declarations or bodies

Then, else, otherwise note 1

Elseif note 1

Keywords notes 1,3 procedure division, interface, implementation

Labels yes branch destinations when on separate lines

note 1 unless followed by ; or. or included in {}, count the followingkeywords once: BEGIN, CASE, DO, ELSE, END, IF,RECORD, REPEAT, THEN, UNTIL

note 2 count every ; and . that is not within a {} or ()

note 3 count each , between USES and the next ; or between VARand the next ;

2004-07-26 78/98

Coding standard

2004-07-26 79/98

Coding standard : example (1/4)Purpose: To guide the development of C++ programs

Program Headers Begin all programs with a descriptive header.

Header Format /*************************************************************//* Program Assignment: the program number *//* Name: your name *//* Date: the date program development started *//* Description: a short description of the program *//* function *//*************************************************************/

Listing Contents Provide a summary of the listing contents.

Contents Example /*************************************************************//* Listing Contents: *//* Reuse instructions *//* Modification instructions *//* Compilation instructions *//* Includes *//* Class declarations: *//* CData *//* ASet *//* Source code in c:\classes\CData.cpp: *//* CData *//* CData() *//* Empty() *//*************************************************************/

2004-07-26 80/98

Coding standard : example (2/4)Reuse Instructions • Describe how the program is used. Provide the declaration format, parameter values and

types, and parameter limits. • Provide warnings of illegal values, overflow conditions, or other conditions that could potentially result in improper operation.

Reuse Example /*************************************************************//* Reuse Instructions *//* int PrintLine(char *line_of_character) *//* Purpose: to print string, 'line_of_character', on one print line *//* Limitations: the maximum line length is LINE_LENGTH *//* Return: 0 if printer not ready to print, else 1 *//*************************************************************/

Identifiers Use descriptive names for all variables, function names, constants, and other identifiers. Avoid abbreviations or single letter variables.

Identifier Example int number_of_students; /* This is GOOD */float x4, j, ftave; /* These are BAD */

2004-07-26 81/98

Coding standard : example (3/4)Comments • Document the code so that the reader can understand its operation.

• Comments should explain both the purpose and behavior of the code.• Comment variable declarations to indicate their purpose.

Good Comment If (record_count > limit) /* have all the records been processed? */

Bad Comment if(record_count > limit) /* check if record_count is greater than limit */

Major Sections Precede major program sections by a block comment that describes the processing that is done in the next section.

Example /************************************************************//* This program section will examine the contents of the array “grades” *//* and will calculate the average grade for the class. *//************************************************************/

Blank Spaces • Write programs with sufficient spacing so that they do not appear crowded.• Separate every program construct with at least one space.

2004-07-26 82/98

Coding standard : example (4/4)Indenting • Indent every level of brace from the previous one.

• Open and close braces should be on lines by themselves and aligned with each other.

IndentingExample

while (miss_distance > threshold){ success_code = move_robot (target_location); if (success_code == MOVE_FAILED) { printf(“The robot move has failed.\n”); }}

Capitalization • Capitalized all defines.• Lowercase all other identifiers and reserved words.• Messages being output to the user can be mixed-case so as to make a clean user

presentation.

Capitalization Example

#define DEFAULT-NUMBER-OF-STUDENTS 15int class-size = DEFAULT-NUMBER-OF-STUDENTS;

2004-07-26 83/98

Assignment #2 : Counting LOC

15 minutes

2004-07-26 84/98

Project plan summary

2004-07-26 85/98

PSP0.1 Project plan summary(1/6)

PSP0.1 adds estimated and

actual LOC in summary form

Types of LOC include

– Base [B]

– Deleted base [D]

– Modified base [M]

– Added–new and base [A]

– Reused [R]

– Total new and changed [N]

– Total new reuse

Table C25 PSP0.1 Project Plan Summary

Student Student 11 Date 2/1/94Program Object LOC Counter Program # 3AInstructor Humphrey Language C

Program Size (LOC) Plan Actual To DateBase(B) 87

(Measured)

Deleted (D) 0(Counted)

Modified (M) 6(Counted)

Added (A) 113(T B + D R)

Reused ® 0(Counted)

Total New & Changed (N) 90 119(A + M)

Total LOC (T) 200(Measured)

Total New Reused 0

Time in Phase (min.) Plan Actual To Date To Date % Planning 10 11 36 6.4 Design 25 21 63 11.2 Code 75 97 249 44.2 Compile 20 4 35 6.2 Test 45 39 105 18.7 Postmortem 20 33 75 13.3 Total 195 205 563 100

Defects Injected Actual To Date To Date % Planning 0 0 0 Design 1 3 11.5 Code 8 23 88.5 Compile 0 0 0 Test 0 0 0 Total Development 9 26 100

Defects Removed Actual To Date To Date % Planning 0 0 0 Design 0 0 0 Code 0 0 0 Compile 2 13 50 Test 7 13 50 Total Development 9 26 100 After Development 0 0

2004-07-26

2004-07-26 86/98

Types of program LOC

New & Changed

Base program New program

Deleted

Added

Untouched

Modified

New Reused

Reused

2004-07-26 87/98

Before development

– If this is an enhancement, measure the size of the base program and enter these LOC in the Base (B) space under Actual

– Estimate the new and changed LOC and enter these LOC in the Total New & Changed (N) space under Plan.


(Measured)

Deleted (D) (Counted)

Modified (M)(Counted)

Added (A)(T-B+D-R)

Reused (R)(Counted)

Total New & Changed (N) 90(A+M)

Total LOC (T)(Measured)

Total New Reuse


2004-07-26

2004-07-26 88/98

Table C25 PSP0.1 Project Plan Summary

Student Student 11 Date 2/1/94Program Object LOC Counter Program # 3AInstructor Humphrey Language C


(Measured)



Added (A) 113(T B + D R)

Reused ® 0(Counted)

Total New & Changed (N) 90 119(A + M)

Total LOC (T) 200(Measured)

Total New Reused 0

Time in Phase (min.) Plan Actual To Date To Date % Planning 10 11 36 6.4 Design 25 21 63 11.2 Code 75 97 249 44.2 Compile 20 4 35 6.2 Test 45 39 105 18.7 Postmortem 20 33 75 13.3 Total 195 205 563 100

Defects Injected Actual To Date To Date % Planning 0 0 0 Design 1 3 11.5 Code 8 23 88.5 Compile 0 0 0 Test 0 0 0 Total Development 9 26 100

Defects Removed Actual To Date To Date % Planning 0 0 0 Design 0 0 0 Code 0 0 0 Compile 2 13 50 Test 7 13 50 Total Development 9 26 100 After Development 0 0


Before development, – Distribute development time

over project phases

• Using To Date % Time in

Phase from previous

programs.

2004-07-26

2004-07-26 89/98


(Measured)



Added (A) 113(T-B+D-R)

Reused (R) 0 0(Counted)

Total New & Changed (N) 90 119 315(A+M)

Total LOC (T) 200 396(Measured)

Total New Reuse 0 0

PSP0.1 Project plan summary(4/6) After development

– Measure total program size and enter these LOC in the Total LOC

(T) space under Actual.

– Count the deleted LOC and enter in the Deleted (D) space under

Actual.

– Count the modified LOC and enter in the Modified (M) space under

Actual.

2004-07-26

2004-07-26 90/98

After development (continued)


(Measured)







Total New Reuse 0 0


Calculate the added LOC as A = T - B + D - R.

Calculate the Total New and Changed LOC as N = A + M.

Count the reused LOC and enter in the Reused (R) space under Actual.

Count or estimate the number of new and changed LOC that will be added to the reuse library.

2004-07-26

2004-07-26 91/98

PSP0.1 Project plan summary(6/6) After development ,

–Adds the actual reused, new and changed, total, and total new reuse LOC from this and all previous programs

–Enter these data in the To Date column.


(Measured)







Total New Reuse 0 0

The To Date data are used to calculate various process parameters in later PSP versions.

2004-07-26

2004-07-26 92/98

Project improvement proposal

2004-07-26 93/98

Process improvement proposal(1/2)

To improve your process, you will need to – Capture process problems

– Propose improvements for future reference.

You will need to know– Any problems you have encountered in using the process

– Any suggestions you have for process improvements

– Your observations and findings from doing the exercise

2004-07-26

2004-07-26 94/98

Process improvement proposal(2/2)

PIP holds process

improvement information– PIP number

– Problem description

– Proposed solution

– Notes and comments

Table C27 Process Improvement Proposal (PIP)

Student Student 11 Date 2/1/94Instructor Watts Humphrey Program # 3AProcess Elements

PIP Number Problem Description:1 Discovered a missing string parsing library function in the string

Libraries at test. Had to do extensive redesign of program in testTo use existing library routines.

ProposalPIP Number

Proposal Description

1 Add a step to the design process to verify the existence of a libraryRoutine before incorporating it into the design. This will requirePrinting a list of library routines in alphabetical order.

Notes and Comments

2004-07-26

2004-07-26 95/98

Assignment #3 : PPS for JD’s program

15 minutes

2004-07-26 96/98

Summary

To effectively plan and manage your work, you must measure product size

PSP uses LOC as the size measure

For other measures, size must correlate with development time

Every size measure should be precisely defined and automatically countable

2004-07-26 97/98

Reference

[1] Watts S. Humphrey,” A discipline for Software Engineering,” Addi

son Wesley, 1995

[2] Watts S. Humphrey,”Introduction to the Personal Software Proce

ss,” Addison Wesley, 1997

[2] SEI, PSP lecture materials, 2004

2004-07-26 98/98

Thank you

personal software process 2004.7.26 kaist se lab

Documents

work slide

personal process data

performance slide

introduction of psp

selfimprovement process

psp software professionals

commitment slide

defined process structure