PSP Process Script

Purpose

    To guide you in construction of module level programs.

Requirements


Phases

    Planning

    1. On the Time Log enter your name, date, and the name of the module you are constructing.
    2. Compute the Lines of Code currently in the module and enter that value in the LOC Start field. If you are creating a new module, enter zero.

    Design

    1. Record the start time and activity code for this phase in the Time Recording Log.
    2. Read the Software Specification and User Interface Prototype for the requirement being implemented.  If there is ambiguity, inconsistency, omission or other error, notify Analyst.
    3. When the requirements are clear, read the Software Architecture Document(s) for the unit.
    4. If there are errors in the Architecture Document, notify the Designer.
    5. If the detailed design has been provided:

    6. Read the algorithm for the unit to be implemented. If the algorithm is not complete or clear, notify the Designer that clarification is needed.
    7. If there is no detailed design, collaborate with Designer to write a detailed design (algorithm pseudocode). Enter the pseudocode as comments into the header file for your module.
    8. Write the Unit Test cases you will need to verify your implementation.  Run the test cases and be sure they fail.
    9. Perform an algorithm trace ("desk check") to verify the correctness of the detailed design using the Unit Test cases you wrote in step G.
    10. Make any corrections necessary.
    11. Record the Stop time for this phase in the Time Recording Log and compute the Delta time.

    Code

    1. Record the start time and activity code for this phase in the Time Recording Log.
    2. Write the code for the unit, translating the pseudocode for the algorithm into actual programming language statements. Be sure to conform to the class coding standard.
    3. Record in the Defect Recording Log (or Defect Tally form) any Specification or Design defects found.
    4. (Recommended) Visually inspect the code for errors. (This is called a personal code review.)
    5. (Recommended) Perform a code trace ("desk check") or other personal methods to verify the correctness of the code using the Unit Test cases.
    6. (Recommended) Make any corrections necessary.
    7. Enter the code into the source file for your module by interleaving the source code in between the lines of pseudocode.
    8. Record the Stop time for this phase in the Time Recording Log and compute the Delta time.

    Compile

    1. Record the start time and activity code for this phase in the Time Recording Log.
    2. Compile the module.
    3. Repair the source code for any errors reported by the compiler.
    4. Each change you make to the source code is recorded as a separate defect in the Defect Recording Log (or Defect Tally form). (Don't count compiler errors; multiple error messages may result from a single defect).
    5. Repeat steps B - D until the compiler reports no errors. This phase ends with the first clean compile.
    6. Record the Stop time for this phase in the Time Recording Log and compute the Delta time.

    Inspection

    1. If your team has a source code walkthrough, review, or inspection procedure, perform that procedure here before proceeding to Unit Test.

    Unit Test

    1. Record the start time and activity code for this phase in the Time Recording Log.
    2. Execute the compiled module using the Unit Test cases.
    3. Repair the source code for any discrepancies from the expected test results.
    4. Each change you make to the source code is recorded as a separate defect in the Defect Recording Log.
    5. Repeat steps B - D until the code passes all the unit test cases.

        Unit Integration

    1. Merge your code with any recent changes by other developers (cvs update).
    2. Integrate the unit with your private build of the complete system.
    3. Run the unit tests again to be sure they still pass.
    4. Perform informal integration testing to be sure your unit integrates properly.  The Test Manager should have a Daily Smoke Test that you should run against your private build.
    5. Check the time to be sure it is within the allowable time limits for daily check-ins.
    6. Do one more cvs update and if there's no conflicts then commit your unit to the repository.
    7. Commit the unit test cases to the repository.  E-mail the Test Manager to notify him/her that your unit is available for integration testing.
    8. Record the Stop time for this phase in the Time Recording Log and compute the Delta time.



PSP Products



Document History
4/13/03  JD   Revised for Spring 2003 (removed Post Mortem phase)

Copyright © 1999 by John Dalbey