Essay: The Personal Software ProcessSM (PSPSM)

CRITICAL REVIEW
The Personal Software ProcessSM (PSPSM)
Abstract : The Personal Software ProcessSM (PSPSM) has become a very effective idea in the modern era. It provides the engineers with a disciplined framework for doing the software work. PSP can be used with any programming language and helps in writing assignments, running tests, defining processes and repairing defects. The primary goal of PSP is to produce zero-defect products on schedule and within the desired cost. Another process called the Team Software ProcessSM (TSPSM), compliments the PSP in achieving the objectives. The major focus of the report is how PSP works, major components and the likely future trends of PSP.
Keywords :
1. INTRODUCTION
Many years back, the quality strategy in most organizations was entirely based on testing. In 1970s and 1980s W. Edwards Deming and J.M. Juran convinced U.S. industry to shift the focus on how to improve the way in which people did their jobs [Deming 82, Juran 88]. The testing phenomenon was starting to be seen as expensive, time-consuming and ineffective for the engineers. The first step in this process was taken by Michael Fagan by introducing Software Inspection, which greatly helped in improving the software quality. The next step was the introduction of Capability Maturity Model® (CMM®) in 1987[Humphrey 89, Paulk 95] with major focus on management system and the support and assistance provided to the development engineers. The next step was the Personal Software Process (PSP) [Humphrey 95]. It was developed to help the engineers make use of the sound engineering practices.
The major question arising those days were hat how to apply the CMM to small organizations and small software teams. Humphrey decided to use CMM principle himself, to figure out a way to convince software engineers to adopt it. Software Engineering Institute (SEI) made Humphrey a SEI fellow, while he was working on this project. This enabled him to spend full time on the PSP research. Humphrey and the SEI tried applying the same principles to work of engineering teams. This work was called as Team Software Process.
2. PSP OVERVIEW
2.1 Principles of PSP
PSP is majorly based on the following planning and quality principles
• Every engineer is different.
• Engineers must use well defined and measured processes to improve their performance.
• Engineers must personally feel responsible for the quality of their product to produce good quality products.
• Finding and fixing defects earlier in the process costs less.
• Prevention of defects is more efficient than fixing them.
• The fastest and the cheapest way is always the right way to do a job.
2.2 Process Structure
The first step in the PSP is planning, where a plan summary is made for storing the data. The engineers record their time and defect data on the time and defect logs. In the postmortem phase (PM), the defect data and the time are summarized from the logs, the program size is measured, and it is entered in the plan summary form.
Figure 1 : PSP Process Flow
The PSP process has a number of methods that are not generally practiced by the engineers, they are introduced in a series of seven process versions. These versions are labeled PSP0 to PSP3, with each version having similar logs, forms, scripts, and standards. The scripts act like checklists, with the purpose to guide engineers to use a process they understand.
The table below shows the PSP process script.
Table 1 : PSP Process Script
2.2.1.1 PSP Planning
The PSP planning process is shown in the figure below. It makes use of the PROBE method.
Figure 2 : Project Planning Process
Requirements : The work to be done is defined in as much detail as possible . The accuracy of the plan depends on how much the engineers know about the work to be done.
Conceptual Design : To have an idea of the product, engineers define how the product is to be designed and built. Producing a complete design is not possible in the planning stages, a conceptual design is made. It is a rough design of the actual product.
Estimate Product Size and Resources : Engineers estimate the size of the products they will develop and based on this size , they estimate the time required to do the work. This estimation in PSP is done using the PROBE method.
2.2.2 Size Estimation using PROBE
PROBE stands for PRoxy Based Estimating. It uses proxies or objects for estimating the likely size of a product [Humphrey 95]. Historical data is referred for sizes of similar objects which have been developed previously and linear regression is used to determine the likely overall size of the finished product. After estimation of sizes of objects, linear regression is again used to estimate the total amount of code to be developed.
2.2.3 Resource Estimation with PROBE
PROBE method is also used to estimate the development resources. After estimating the total time of the job, historical data is used to estimate the time needed for each job phase. Percentages are used as guide to help engineers allocate their total time to planning, design, design review, code, code review, compile, unit test, and postmortem phases. Once they know the time required for each process step, they estimate the time they will spend on the job each day or week.
3. Data Gathering in PSP
To monitor their work and make better plans, engineers gather data on the time the spent in each process phase, the sizes of products they produce, and quality of new products.
3.1 Time Measures
The engineers note the time they started working on a task, the time when they stopped a task, and any interruption time. An interruption can be anything from a phone call to a brief break. Using time measures, engineers track the effort actually spent on a project task.
3.2 Size Measures
The time to develop a product is determined by the size of that product. After they are done, engineers measure the sizes of the products they produced. This provides the engineers with the size data they need to make accurate size estimates. Because there are many ways to define logical LOC, engineers must define how the measure LOC [Park 92]. Lines of Code (LOC) is the principal PSP size measure. When engineers work on a team or in a larger software organization, they should use the team’s or organization’s LOC standard. PSP guides engineers in writing two automated LOC counters for the PSP course.
There are various categories of product LOC :
BASE : Size of the original product before any modifications
ADDED : Code written for new program or added to existing base program.
MODIFIED : The base code in an existing program that is changed.
DELETED : The base code in an existing program that is deleted.
NEW AND CHANGED : The added or modified code to make size and resource estimates.
REUSED : Code taken from a reuse library and used, without modification.
NEW REUSE : The LOC that an engineer develops and contributes to reuse library.
TOTAL : Total size of the program, regardless of the source of the code.
The New and Changed LOC is defined as follows
N&C LOC = Added + Modified
The calculations for the total size of the product are as follows:
Total LOC = Base – Deleted + Added + Reused
Neither the modified nor the “NEW REUSE” LOC are included in the total.
3.3 Quality Measures
The principal quality focus of the PSP is on defects. The term defect refers to something that is wrong with a program.
The major PSP quality measures are
Defect Density : Defects per new and changed KLOC found in a program. It is measured for the entire development process and for specific process phases.
Figure 3 shows IBM data on a major product that demonstrates the relationship [Kaplan 94].
This data implies that when engineers find relatively fewer defects in unit test, assuming that they have performed a competent test, their programs are of relatively higher quality.
Figure 3 : Development vs. Usage Defects; IBM Release 1 (r2=.9267)
Review Rate : When engineers review designs or code faster than about 150 to 200 new and changed LOC per hour, they miss many defects. Engineers gather data on their reviews and determine how fast they should review to find most of the defects.
Development Time Ratios : Ratio of the time spent by an engineer in any two development phases. The three development time ratios are design time to coding time, design review time to design time, and code review time to coding time. These ratios are decided based on the defects injected and removed per hour.
Defect Ratios : Compare the defects found in one phase to those found in another. Principal defect ratios are defects found in code review divided by defects found in compile, and design review divide by defects found in unit test.
Yield : Phase yield is the percentage of defects that are found and removed in a phase. Process yield is the percentage of defects removed before the first compile and unit test.
Defects Per Hour : Number of defects injected and removed per hour.
Defect Removal Leverage : Measures the relative effectiveness of two defect removal phases.
A/FR : The appraisal to failure ratio(A/FR) measures the quality of the engineering process, using cost-of-quality parameters [Juran 88]. The appraisal cost is the time spent in design and code reviews. The F in A/FR stands for the failure quality cost, which is the time spent in failure recovery and repair.
4. PSP Quality Management
When a system becomes faster, increasingly complex and more automatic, catastrophic failures become more damaging. So, in order to produce high-quality programs, every software engineer who develops system’s parts must do high-quality work.
4.1 Defects And Quality
The software products must meet the users functional needs and perform efficiently. The engineers major concern should be on finding and fixing defects. PSP data show that even the experienced programmers inject a defect in every seven to ten lines of code [Hayes 97].
Simple coding errors can lead to destructive defects. The source of most software defects is simple programmer oversights and mistakes.
4.2 Engineer’s Responsibility
The major PSP quality principle is that engineers are responsible for the quality of programs they produce.
4.3 Early Defect Removal
Another quality objective is to find and fix the defects before the first unit test. People make the same mistake repeatedly. So, engineers have made a check list and fix these errors quickly.
4.4 Defect Prevention
Three different ways to prevent defects are to have engineers record data on each defect they find, use an effective design method and notation produce complete designs, and making a more thorough design to reduce coding time, thus reducing defect injection.
5. Design, Discipline and Result
PSP can be used with any design, it requires the design to be complete. A design is said to be complete if it defines all four dimensions shown in the table below [De Champeaux 93].
Table 2 : Object Specification Structure
The principle focus of the PSP discipline is on providing a working environment that supports PSP practices. This was the main reason why SEI developed the Team Software Process : to provide the disciplined environment for engineers to use PSP methods.
PSP has been introduced in various universities with a PSP course in which students write 10 programs and complete 5 data analysis reports [Humphrey 95].
The figure below shows the PSP course structure
Figure 4 : PSP/TSP Course Structure
Hayes and Over have shown that PSP course substantially improves performance in estimating accuracy and defect removal in early stages, while not affecting the productivity significantly [Hayes 97]. Figure 5 shows the productivity results.
Figure 5 : Productivity Results
When taught by qualified instructors, students show significant improvement. Engineering performance after PSP training gives better results than before [Ferguson 97, Seshagiri 00].
6. Process Improvement and Future Trends
The PSP is a series of three complementary process-improvement approaches, namely Capability Maturity Model (CMM), PSP, and the Team Software Process (TSP). These address various aspects of organizational capabilities, like
• To produce superior products, there must be a plan meeting the market’s needs.
• Management must obtain superior performance from engineers.
• Engineers must be able to work together effectively as a team.
• The engineering team must be properly trained.
In future, the software engineering groups must deliver quality products on time and within the desired costs. Contract performance penalties will become normal engineering staffs. The future will have a closer integration of PSP, TSP, and CMM methods.
7. Conclusion
The paper is majorly about Personal Software Process (PSP) and involves all the aspects regarding it. PSP being taken up as courses in all the universities will be beneficial for the students. Inclusion of topics like PROBE and TSP will always be an added advantage in making efficient software engineers. It will help in improving the growth and success rate of the individual as well as the organization, and in return also helps in improving the quality of the desired product. PSP, CMM and TSP used together can prove to be very beneficial for the future of software engineering and related fields .
REFERENCES
[De Champeaux 93] – De Champeaux, D., Lea, D., and Faure, P. Object-Oriented System Development, Reading MA: Addison-Wesley, 1993.
[Deming 82] – Deming, W. E. Out of the Crisis. MIT Center for Advanced Engineering Study, Cambridge, MA, 1982.
[Ferguson 97] – Ferguson, P., Humphrey, W., Khajenoori, S., Macke, S., and Matvya, A. “Introducing the Personal Software Process: Three Industry Case Studies,” IEEE Computer, 30, 5 (May 1997): 24-31
[Hayes 97] – Hayes, W. and Over, J. The Personal Software Process: An Empirical Study of the Impact of PSP on Individual Engineers (CMU/SEI- 97-TR-001), Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1997 <http://www.sei.cmu.edu /pub/documents/97.reports/pdf/97tr001.pdf>.
[Humphrey 89] – Humphrey, W. Managing the Software Process. Reading, MA: Addison-Wesley, 1989.
[Humphrey 95] – Humphrey, W. A Discipline for Software Engineering. Reading, MA: Addison-Wesley, 1995.
[Juran 88] – Juran, J. and Gryna, F. Juran’s Quality Control Handbook, Fourth Edition. New York: McGraw-Hill Book Company, 1988.
[Kaplan 94] – Kaplan, C., Clark, R., and Tang, V. Secrets of Software Quality, 40 Innovations from IBM. New York, N.Y.: McGraw-Hill, Inc., 1994.
[Park 92] – Park, R. Software Size Measurement: A Framework for Counting Source Statements (CMU/SEI-92-TR-20, ADA258304). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University (Sept. 1992) <http://www.sei.cmu.edu/pub/documents/92.reports /pdf/tr20.92.pdf>.
[Paulk 95] – Paulk, M., et al. The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA: Addison Wesley, 1995.
[Seshagiri 00] – Seshagiri, G. “Making Quality Happen: The Managers’ Role, AIS Case Study,” Crosstalk (June 2000).