LECTURE 6 PSP.pdf

LECTURE 6: PERSONAL SOFTWARE PROCESS (PSP) ISP573 - SOFTWARE IMPROVEMENT  Lecture Content ◦ PSP objectives, problems and solutions ◦ PSP Concepts and Structure ◦ PSP Planning and Measurement ◦ PSP Quality Management ◦ PSP Results  Personal Software Process...

LECTURE 6: PERSONAL SOFTWARE PROCESS (PSP) ISP573 - SOFTWARE IMPROVEMENT  Lecture Content ◦ PSP objectives, problems and solutions ◦ PSP Concepts and Structure ◦ PSP Planning and Measurement ◦ PSP Quality Management ◦ PSP Results  Personal Software Process Objectives: ◦ To describe the personal software process (PSP) ◦ To show where and how the PSP can be used to improve individual software engineering performance 3 The Software Problem ◦ Poor software quality in delivered systems is expensive ◦ expensive service and enhancement ◦ potential for accident or loss of life ◦ Organizational progress with process improvement is limited because ◦ process improvement takes time, and is hard to sell 4 The PSP Solution ◦The PSP addresses these problems by ◦ providing convincing evidence of the benefits of process improvement ◦ exposing the engineers to the benefits of using effective processes in their work ◦ teaching the engineers effective process improvement methods ◦ providing the historical data to better manage cost, schedule, and quality 5 The PSP Paradigm ◦ The PSP is based on process improvement principles. ◦ Software engineers establish personal process goals ◦ they define the methods to use ◦ they measure their work ◦ they analyze the results ◦ based on the results, they adjust their methods to improve towards personal goals 6 The PSP Strategy ◦ Start with the s/w engineer’s current process ◦ Gradually introduce new methods ◦ Practice these methods on module-sized programs ◦ The engineers then see for themselves how these methods help them. 7  PSP Concepts ◦ The Personal Software ProcessSM (PSPSM) is software process developed at the SEI to address some of the SW-CMM practices at the level of the individual programmer [Humphrey 1995]. ◦ The PSP provides an incremental approach that helps engineers develop an individual “level 5” process. PSP: self-improvement PSP: how to make and meet commitments PSP: forms + guidelines + procedures (Watts Humphrey, SEI, 1995)  Software Engineering and the PSP ◦ The PSP offers an opportunity and framework for incorporating software engineering best practices into an individual engineer’s process. ◦ The PSP address’s 12 of the SW-CMM 18 KPA’s. ◦ For this reason, PSP sometimes referred to as a “Level 5” process. ◦ Data about PSP training show that students and engineers can improve their planning capabilities and produce higher quality products without an increase in cost.  PSP Key Process Areas Level Focus Key Process Area 5: Optimizing Continuous Defect Prevention (PSP) Process Technology Change Management (PSP) Improvement Process Change Management (PSP) 4: Managed Product and Quantitative Process Management (PSP) Process Quality Software Quality Management (PSP) 3: Defined Engineering Organizational Process Focus (PSP) Process Organizational Process Definition (PSP) Integrated Software Management (PSP) Training Program Software Product Engineering (PSP) Intergroup Coordination Peer Reviews (PSP) 2: Repeatable Project Requirements Management Management Software Project Planning (PSP) Software Project Tracking and Oversight (PSP) Software Subcontract Management Software Quality Assurance Software Configuration Management  PSP Structure Team Software PSP3 Process Cyclic development Requirements Configuration management PSP2 PSP2.1 Code reviews Design templates Design reviews PSP1.1 PSP1 Task planning Size estimating Schedule planning PSP components Test report - forms, logs and templates - process scripts PSP0.1 - standards Coding standard PSP0 Process improvement - benchmarks Current process proposal Basic measures Size measurement The PSP0 Process ◦ With PSP0, engineers use their current design and development methods. ◦ They gather data on their work. ◦ the time spent by phase ◦ the defects found in compile and test ◦ They analyze and report these data. 12 The PSP0 Lessons ◦ With PSP0, engineers learn to use a basic personal process. ◦ they gather data on their personal work and personal processes ◦ they learn how and why to measure the sizes of the products they produce 13 The PSP1 Process ◦The PSP0 is augmented to include ◦ coding standards ◦ size estimating ◦ resource estimating ◦ schedule estimating ◦ test report ◦ earned value tracking ◦ process improvement proposal (PIP) 14  The PSP1 Lessons ◦ With PSP1, engineers estimate the sizes and development times of the work they produce. ◦ they use their historical data to improve their estimates ◦ they project the likely statistical ranges of their estimates and learn how to reduce these ranges 15  PSP2 and PSP3 Lessons ◦ With PSP2, engineers use their historical data to improve the quality of the program modules they produce. ◦ they measure the efficiency of their defect removal methods ◦ they use various process quality measures, including yield, COQ (cost of quality), and A/FR (appraisal/failure ratio) ◦ With PSP3, engineers learn how to adjust their personal processes for different types of work. 16  PSP Structure PSP0: PSP1: PSP2: PSP3: establish a make size, measured learn defect scale up PSP resource, and performance and yield methods to schedule baseline management larger projects plans ◦ The PSP can be extended to team development of large-scale software systems. ◦ The PSP is a pre-requisite for the Team Software Process(TSP).  The PSP0 Process Flow Requirements PSP0 Process Planning Development Process Design Time scripts Code and defect Compile logs Test Plan Postmortem summary Finished product  PSP0 Process Script Purpose: To guide you in developing module-level programs. Inputs Required 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 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 with estimated and actual data - Completed defect and time logs  PSP Planning ◦ The PSP shows engineers how to estimate and plan their work. ◦ The keys to making better estimates and plans are to use ◦ relevant historical data ◦ statistically sound methods ◦ a defined estimating and planning process ◦ As engineers gain experience, they learn to make better estimates and plans.  Measurement in a Defined Process ◦ Measured historical data is needed for effective planning. ◦ Measurement tells when and how process tasks are carried out. ◦ Measured data is used to evaluate and improve a process. ◦ The PSP uses three types of measures. ◦ effort ◦ size ◦ defects  Effort Measurement ◦ The PSP measures effort as time in minutes. ◦ appropriate for small programs ◦ easy to measure precisely ◦ You keep accurate records of time spent on each programming task. ◦ A Time Recording Log is used for this purpose. ◦ Interruption time is recorded and subtracted from time spent on development tasks. ◦ Record all time spent on software development. Time Recording Log 1 Student Date Instructor Class Program Date Start Stop Int delta t Activity Comment  Time Recording Log 2 ◦ Phase ◦ note the phase on which you were working ◦ Date - Enter the current date (e.g., 9/5/03) ◦ Start - Enter the time in minutes (e.g., 11:25 am) when you start a project phase. ◦ Interruption time - Enter any time you lost due to interruptions in the start to stop period. (e.g., 15 minute coffee break) ◦ Stop - Enter the time in minutes when you stop work on a project phase, even if you are not done with that phase. ◦ Comments - describe ◦ the interruption ◦ the task you were doing ◦ anything else that significantly affects your work  Size Measurement 1 ◦ Size data is used in estimating development time and the expected number of defects. ◦ There are a number of criteria for good size measures. ◦ has good correlation with effort ◦ has a precise definition ◦ can be counted automatically ◦ is suitable for planning ◦ is sensitive to language, design, and development method ◦ A lines of code (LOC) measure satisfies most of the criteria for good size measures.  Size Measurement 2 ◦ The PSP uses LOC for measuring size. ◦ There are various ways to define and interpret the meaning of a line of code. ◦ A physical LOC count is the number of non- blank, non-comment lines of source code. ◦ A logical LOC count is related to a program’s logical content, but it depends on the programmer’s definition of a logical line of code. ◦ For simplicity, the PSP uses a coding standard that requires each logical LOC to use one physical line.  Defect Measurement ◦ A PSP defect is ◦ something that must be changed to correct an error made in a software artifact (design, code, etc.) ◦ classified according to a defect type standard ◦ For each defect, students record the defect type, a description of the defect, and the fix time. ◦ All changes related to a single error are counted as one defect. ◦ Fix time is recorded in the phase in which the defect is removed (e.g, compile or test). ◦ A Defect Recording Log is used for this purpose. Defect Recording Log 1 Student Date Instructor Class Program Date Def. Type Phase Phase Fix Description Num. Injected Removed Time type code name description doc 10 Documentation comments, messages syn 20 Syntax spelling, punctuation, typos, instruction formats, etc. bld 30 Build, Package change management, library, version control asg 40 Assignment declaration, identifier names, scope, limits int 50 Interface procedure calls, context clauses, and references, I/O, user prompts, output labeling chk 60 Checking error messages, inadequate checks and exception handling dat 70 Data structure, content fun 80 Function logic, pointers, loops, recursion, computation, function defects sys 90 System system configuration, timing, memory env 100 Environment tool support and operating system problems  Defect Recording Log 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. ◦ Inject - Enter the phase in which you judge the defect was injected. ◦ Remove - Enter the phase in which you found and fixed the defect. ◦ Fix time - Enter the time you took to fix the defect. You may time it exactly or use your best judgment.  Plan Summary Form Program Size (LOC) Plan Actual To Date Total New & Changed Measured data is used for Maximum Size Minimum Size planning, tracking and analyzing Time in Phase (min.) Planning Plan Actual To Date To Date % software development activities. Design Design Review The Plan Summary form is used for Code Code Review recording the planning data and Compile Test summarizing the results. Postmortem Total Tables 19.1 and 19.2 in [Humphrey Maximum Time Minimum Time 1997] give instructions and an Defects Injected Plan Actual To Date To Date % Design example for completing the form. Design Review Code Code Review Compile Test Total Defects Removed Plan Actual To Date To Date % Design Design Review Code Code Review Compile Test Total Summary Plan Actual To Date LOC/Hour Defects/KLOC Pre-Compile Yield  PSP Quality Measures Q uality Me asure De scription Total defects/KLOC the number of defects found in development, per P roduct 1000 lines of code Q uality Test defects/KLOC the number of defects found in test, per pe r 1000 lines of code Yield the percent of defects found before compile Appraisal COQ the percent of total develoment time spent in P roce ss (Cost of Quality) design review and code code review Q uality Failure COQ the percent of total develoment time spent in compile and test Total COQ Appraisal COQ + Failure COQ A/F R Appraisal COQ Failure COQ Review rate the number of lines of code reviewed per hour in a - LOC/hour review (code review or design review) Defect removal rate the rate at which defects are removed in a defect - defects/hour removal phase (design review, code review, compile, test)  Personal Quality Management ◦ In the PSP, students conduct personal design and code reviews. ◦ Engineers use a defined review process. ◦ They design their own review checklists. ◦ They use a review script and rigorously follow the checklists. ◦ They collect data on reviews and used to improve their review process. ◦ Engineers collect data, compute metrics from the data, analyze the metrics, and use the results to improve the quality of their process and products. Total Defects/KLOC Removed Total Defects/KLOC Removed 140 Mean Defects Per KLOC Design review 120 and code review introduced 100 80 60 40 1 2 3 4 5 6 7 8 9 10 Assignment Number Productivity 1997 SEI Study The Costs of the PSP ◦The time investment ◦process development takes about 1 to 2 hours per form and script ◦process updates will be needed at least every 3 months ◦data entry and analysis will take about an hour for each PSP- sized project The Costs of the PSP ◦The emotional investment ◦ the PSP takes a lot of work ◦ there will be occasional frustrations ◦Software engineer have clear view of own limitations ◦ if software engineer cannot face their personal limitations, they should not use the PSP ◦ and perhaps they should reconsider their decision to be a software engineer ☺  PSP Results for Industrial Use ◦ Although there have been some notable successes [Ferguson 1997], replicating the results in PSP training in an industrial setting has not been easy. ◦ In most cases, the classroom PSP has to be adapted/tailored to the development environment and the domain of application. ◦ PSP requires a great deal of discipline and most people need a supportive environment to maintain such discipline. ◦ PSP does not fit well in an organization with a low maturity level. ◦ More positive results have been achieved when the PSP is coupled with the Team Software ProcessSM (TSPSM) [Davis 2003].  Messages to Remember ◦ The PSP implements CMM key practices at the individual and team level respectively. oThe PSP is a “level 5” process. ◦ The PSP is flexible and tailorable, but requires discipline and commitment. ◦ The PSP can oreduce schedule deviation oimprove the quality of the delivered product oimprove productivity (or cause not decrease)  References ◦ [Davis 2003] Davis, N. and Mullaney, J., The Team Software Process (TSP) in Practice: A Summary of Recent Results, CMU/SEI-2003-TR-014, Software Engineering Institute, Carnegie Mellon University, September 2003. ◦ [Ferguson 1997]Ferguson, P., Humphrey, W., Khajenoori, S., Macke, S., and Matvya, A. "Introducing the Personal Software Process: Three Industry Case Studies," Computer, pp. 24-31, May 1997. ◦ [Hayes 97] Hayes, W. and Over, J.W., The Personal Software Process: An Empirical Study of the Impact of PSP on Individual Engineers, CMU/SEI-97-TR-001, Software Engineering Institute, Carnegie Mellon University, December 1997. ◦ [Humphrey 1995] Humphrey, Watts S., A Discipline for Software Engineering, Addison Wesley, 1995 ◦ [Humphrey 1997] Humphrey, Watts S., Introduction to the Personal Software Process, Addison Wesley, 1997. ◦ [Paulk 1993] Paulk, Mark C., et. al., Capability Maturity Model for Software, Version 1.1, CMU/SEI-93-TR-024, Software Engineering Institute, Carnegie Mellon University, 1993. ◦ [SEMA 2003] Software Engineering Measurement and Analysis, Process Maturity Profile: Software CMM, CBA IPI and SPA Appraisal Results, 2003 Mid-Year Update, Software Engineering Institute, Carnegie Mellon University September 2003, http://www.sei.cmu.edu/sema/pdf/SW-CMM/2003sepSwCMM.pdf.