1. 1 PSP in CS1: not so wise after all Briana Morrison Southern Polytechnic State University Marietta, GA

2. 2 The Experiment Timeframe: late 1990s Personal Software Process Improve time estimates Improve software quality Improve programmer productivity Introduce simplified version in CS1 Collect data in closed labs Students work in pairs

3. 3 Nitty Gritty Details 2 hour closed lab Students read pre-lab problem statement and attempt design Entire class discusses problem solution Students work in pairs to implement solution Students given second (related) problem to solve and implement solution

4. 4 Nitty Gritty continued… On 4 th (out of 11) labs, students asked to collect PSP data PSP had been introduced during lecture (along with software lifecycle) One student should record times and errors, 2 nd student works on solution To validate data, question given on final to assess their ability to record data correctly

5. 5 Student(s): ________________________________Date: __________________ Class: _______________ Section: ______________Program/Lab: #__________ Phase Start Time Stop Time MinutesComments Time Log Summary: PhaseMinutesPercentActivities 1 PlanningReading & reviewing pgm spec’s, book, and notes 2 DesignCreating a design model and algorithm 3 CodingWriting code 4 ReviewReviewing design and coding 5 CompileFixing compile errors to 1 st clean compile only 6 TestFixing run-time errors & recompile errors 7 Wrap-upCompleting log & preparing package to hand in Total100% Time Log:

6. 6 NumberPhaseDescriptionFixed (Y/N) 1 2 3 4 5 Record Defects Here

7. 7 Defect Summary: Phase NumberPercentActivities 3 CodingWriting code 4 ReviewReviewing design and coding 5 CompileFixing compile errors to 1 st clean compile only 6 TestFixing run-time errors & recompile errors Total100% LOC Summary: Lines of Code (LOC) Base (B)Beginning (Reused) Code Deleted (D)Lines Deleted Modified (M)Lines Changed Added (A)New Lines Added Total(B - D + A) New LOC(A + M) LOC / Hour(NewLOC / (Total minutes / 60))

8. 8 Anticipated Results Students could calculate productivity and given approximate size of “open” assignments, determine amount of time to allocate for assignment Students could see where they spent their time (design, compile, debugging, etc.) and plan accordingly

9. 9 What Really Happened Students didn’t record design data from pre- lab Data inaccurate: Pair programming – no one recording Scribe so busy problem never solved Didn’t reduce number of late assignments

10. 10 act Actual Time by Phase LOCtimeplandesigncodereviewcomptestpost 143645112536 293778122125 511055451030105 793 2 112 13551023537 min101021102 max85335302204520302025 avg12.247.07.920.015.75.47.46.26.9 std dev17.061.56.645.911.44.67.75.44.8 Lab 9 Data

11. 11 Defects RemovedtotalDefLOC designcodereviewcomptestDefKLOChour 51125326185723.33 1 134.4847.03 000000046.67 1 120010.34 1233 910009 2 2 3 10212120012.5 0000000Min 5113105200047Max 1.01.81.12.51.4493.413.0Avg 1.63.01.12.51.3612.512.1Std dev

12. 12 Actual Data Actual time: 0 – 335 minutes Actual LOC: 1 – 85 Errors found during design: 0 – 5 Errors found during coding: 0 – 11 Errors found during compile: 0 – 10 Errors found during testing: 0 – 5 Less than 50% got full credit on final exam question

13. 13 Lessons Learned Experiment design flawed Should have done pilot first (mid-semester adjustment to data collection) Determine validity of data at the beginning Provide automation where possible No “buy-in” from students to benefits

14. 14 More Lessons Learned Use caution when asking students to learn more than one task at a time (programming, recording errors) Industry techniques and tools don’t always translate into academia