PSP Process Script FAQ

[ Time Recording Log FAQ ] [ Defect Recording Log FAQ ] [ Project Summary Form FAQ ]

Purpose

The purpose of these guidelines is to provide further explanation and clarification of the Time Recording Log Instructions, Defect Recording Log Instructions, Project Summary Form Instructions.

Requirements

Examine the Time Recording Log, Defect Recording Log, Project Summary Form and read the Instructions.


Time Recording Log FAQ

Q: I'm not always certain which phase I'm in. Sometimes the distinction between design and coding is vague.

A: Yes, this is sometimes confusing, because many students don't have a clear distinction in their mind between designing and coding. Usually this is because many students haven't been taught an explicit design notation, nor do they have clear criteria for assessing when their design is complete

Design is the intellectually demanding task of determining "how is this going to work." Design determines the algorithm that will solve the problem. Ideally the design is represented in a language independent notation such as pseudocode that has no syntactical details. Coding should be a purely mechanical task of translating an already completed algorithm into high level language statements. (Note that entering the design pseudocode as comments in the module has a fringe benefit of producing "pre-documented" code. This will spare you having to add comments to your code after the fact.)

Frequently as students attempt to construct a solution they write a mishmash of english and half-coded language statements. Regardless of how it is written, this activity of algorithm creation is still recorded as design. At some point when they have a general understanding of the solution, they will go to the computer and start typing in source code. This starts the coding phase. Even if mentally they are still refining details of the design "on-the-fly" so to speak, their subjective sense is that they have shifted to writing code, so it should be recorded that way. Another clue is that the visible activity is writing programming language statements so this should be recorded as coding.

Sometimes a confident student will feel like they understand the solution well enough that they can keep the design in their head and they don't need to write down the algorithm. If this happens to you, enter 0 for the design time and go directly to implementation. Of course Dr. Dalbey discourages this practice, but if that is what you actually do you should record it that way in your Log.  If you carry out the design mentally "on-the-fly" during coding, count this time as coding.  If you are designing as part of fixing a defect or hashing out an implementation problem, record your time in the phase in which you found and fixed the problem.  The criteria to keep in mind is initial design work is recorded as design, rework of flawed or inadequate design is not recorded as design.

Q: What if I'm designing and I'm not sure about some implementation detail? If I write experimental code can I count that as design activity?

A: Yes, as long as you discard the experimental code and don't reuse even a single line.

For example, say you want to create a string from an array of characters, and the API shows the constructor:
public String(char[] chars, int index, int count)
You want to know what happens if count is greater than the number of characters in the array. You try to find some documentation explaining the answer but are unsuccessful. So you decide to write a tiny program to find out.

public class StringSpike
{
static
{
char[] letters = {'h','i',' ','b','y','e'};
String words = new String(letters,1,10);
}
}
You can still consider this as the design phase, as long as you delete the program when you find out what you need to know. If you reuse even a single line, then we need to consider this as coding phase, because it could have defects that affect the rest of the solution.

Q: During testing I have to re-compile my program after I've repaired a defect. Does this count as compile time?

A: No. The time you enter for the compile phase is the time you spend getting your program to compile successfully the first time. When you are first able to get a clean compile (no errors) the compile phase ends.

As you fix defects you find during testing, these changes must be recompiled; this time should be included as part of the test phase.

With some interpretive and 4GL languages, there is no compile time. In this case, enter 0 for the compile phase and go directly from code to test.

Q: During testing I discover a design flaw. As I rework the design, does that count as design time?

A: No. Rework resulting from defects always counts as time during the phase in which the defect is found and fixed. Correcting code, changing the design, and re-compiling during testing all count as test time.

Q: In what phase do I record the time for writing test cases?

A: Record them in the phase you write them. If you write your test cases prior to coding, count it as design. If you wait until after coding to determine your test inputs and expected outputs, count it as testing.

Q: I usually make a printout and look over my source code for mistakes before I compile it. Do I record this as Review phase?

A: There is no review phase in PSP0. You are still in code phase.

Q: What if I reuse some code from a previous assignment? Does that change my LOC count?

A: Yes, it would, so don't do that. For PSP0 write all code from scratch - no reuse.

Q: What's the difference between an interrupt and stopping a work period?

A: An interrupt is unexpected and outside of your control, such as a phone call, or the battery dying on your laptop.  Stop work is when you make a choice to leave the programming activity and do something else, like stretching or getting a snack.   Sometimes the distinction is not real obvious.  The intent is to track when outside events or distractions intrude on the work process, as opposed to when we consciously intend to stop working.   Use your best judgment.
If you answer a phone call and then decide to check your email before resuming work, this is an interrupt followed by a stop work. The stop work happens when you check your email.

Q: I want to use PSP in another course where my instructor allows me to use Eclipse. The Eclipse IDE compiles my source automatically, how do I record my coding time?

A: The first line you type into the IDE gets compiled, so count it as compile time. If you don't write your code on paper or in a text editor before you enter it into Eclipse, then there is no coding phase. If you go straight from design to typing in Eclipse, then enter 0 for the coding phase and put a comment "Entering/compiling code in Eclipse".


Defect Tally/Recording Log FAQ

Q: If I write some code, then a few minutes later realize I made a mistake, do I record that as a defect?

A: If you discover a mistake in code before you do any compiles, you are still in code phase, so it isn't a defect. Mistakes found and fixed before leaving a phase aren't defects. A defect is recorded when you finish the initial development and judge the work to be complete and move on to the next phase. An error found in work from a previous phase is a defect.

Q: How many defects do I record if the compiler reports two errors resulting from one mistake?

A: One. Making one change to the program fixes the problem, so it's one defect.

Q: I left out a parameter in a method call, but I did it in two places. Is that one defect?

A: Record it as two defects, because the fix required changing the code in two places. On the Defect Tally form you can use ditto marks in the description field.

Q: What does "injected" mean?

A: "Injected" refers to when you created the defect.  You have to reflect and think back what you were doing when you made that mistake. Record the phase you were working in when you created that defect.  "Removal" on the other hand means when you discovered and fixed the defect.  Injection phase is always before the removal phase.

Q: What about if I introduce a defect while fixing another?

A: OK, you caught me. There's one special case where injection phase is not before the removal phase. If you are fixing a defect and while making the repair you cause another defect. Then later in the same phase you discover that your first repair had unwanted side effects, so you fix those. Thus you removed the defect in the same phase that you injected it.

Q: During design, I write some exploratory code to determine if a certain library module will provide the services I need. If I make an error in this exploratory code, do I record that as a defect?

A: I suggest keeping a separate defect log of defects in your exploratory code.  You can record the defects as being injected and removed during design phase.  If you really throw away the exploratory code and don't include it in the product you are building, then you can discard the defects.  But if you end up using any of the exploratory code, even a single line, in the finished product, then you need to include the defect log as well.
 

Q: Do I record defects during Acceptance Test (after development)?

A: Yes, create a separate removal phase to tally defects after development, but DO NOT record the injection phase, and don't add these defects to your total on the summary form. Similarly, record the time in this phase, but don't add it to total time.


Project Summary FAQ


Q: How do I estimate Product Size (LOC)?

A: Use the WAG method. ("Wild *ssed Guess"). In the absence of any previous data, any estimate is really a guess. Use your judgement, based on your programming experience, to anticipate how many lines of code will be required to implement the desired functionality.

A more formal approach which relies on historical data called the PROBE method is described in "A Discipline for Software Engineering." For this class, it is not important that your size estimates be accurate, so don't be overly concerned about them.


Last updated 4/7/2011
Copyright © 1999 by John Dalbey