CS-489 Process Details

by Dr. Durant
This process is based on materials developed by Dr. Welch and Dr. Sebern.

Overview

As part of the software development process for this course, all team members are expected to track and report process data. A more detailed discussion of this process, including spreadsheets for some of the tables, can be found on Dr. Welch's SE280 page.

Acknowledgement

The time and defect tracking tools used here are taken from Watts Humphrey's Personal Software Process (PSP). However, they represent only one small part of the PSP; as the course goes on, other parts of the process will be discussed. Unfortunately, the time available does not permit training in the complete PSP, and students are encouraged to pursue additional PSP study on their own or as part of another course.

Time tracking and reporting

Time tracking is done with a time log sheet, resembling the following form:

Date	Start	Stop	Interruption Time	Delta Time	Phase	Comments

The project phases are:

Planning (includes analysis)
Design
Design review
Coding
Code review
Compile
Test
Postmortem

Note that these are phases, not activities. For example, the "compile" phase begins on the first compile and ends when a "clean compile" has been achieved, even if fixing defects in this phase requires going back and redoing some of the analysis or design. Time spent in team meetings and research should be included in the phase you are in, though it should be labeled (in "comments") separately in the time recording log.

During the postmortem, the time in each phase should be summarized by developer (team member) and for the team as a whole.

Defect tracking and reporting

Defect tracking is done with a defect recording log:

Date	ID Number	Occurrences	Type	Inject Phase	Remove Phase	Fix Time	Fix Defect	Description

Some notes on these items:

ID Number - a sequential serial number assigned to each defect.
Occurrences - number of instances of the same defect (e.g., incorrect data object name) found at the same time.
Type - defect type code (see table below).
Fix defect - if you inject another defect (defect B) while fixing a previous defect (defect A), put the ID number of defect A in the "fix defect" field of defect B.

Defect types:

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

During the postmortem, the number of defects injected and removed in each phase should be summarized, by developer and for the team as a whole. The defect types should be used to improve the design and code review checklists.

Excel spreadsheets containing versions of these form can be downloaded from Dr. Welch's website [no longer online].