Software Guru: His impact on Software Processes
by Sonali Parthasarathy
Abstract:
This paper examines the impact of Dr. Watts Humphrey in the field of software Engineering by analyzing the effects of Personal Software Process (PSP) which he introduced on the key performance dimensions of engineers like estimating and planning their work, quality of their work, quality of the software developed and productivity. In order to understand the impact of PSP on these performance dimensions, a case study can be examined. In particular, this paper discusses the impact of PSP training by examining each project undertaken by Advanced Information Systems, Illinois (AIS). The results of the projects with respect to the four performance areas would indicate the effectiveness of PSP. The individual parameters or variables that affect the personal software process also help in the understanding of PSP.
Few people have heard about Dr.Watts S. Humphrey outside the software world, but in the field of Software Engineering he is a “Super Star”. His vision for software quality has brought us to where we are today. Without him we would still be using software that is defective, costly and delivered way past the deadline. Founder of the Software Process Program of the Software Engineering Institute (SEI), he introduced the Capability Maturity Model (CMM) through his book Managing the Software Process, that provided companies with a framework that focused on the management environment needed to complete the work on time. It involved planning, configuration management and various policies and practices. Although CMM explained the principles to be followed, there were no clear-cut directions to actually carry it out. In 1994, Dr. Humphrey developed PSP (Personal Software Process), which provided a streamlined approach enabling software engineers to implement the CMM principles. It concentrated on how to accomplish the policies and practices laid out by CMM. “ In PSP, individuals gather measurements related to their own work products and the process by which they were developed, and use these measures to drive changes to their development behavior” (Johnson and Disney 347). By undergoing the PSP training software engineers can not only enhance their performance but also improve the quality of the software developed.
But what inspired him to introduce CMM and then PSP? Before joining the Software Engineering Institute, Dr. Humphrey worked for IBM between 1959 and 1986. His experience in IBM and discussions with other people in the software industry convinced him that software practices on the whole were terrible. Engineers were very disorganized and concentrated on coding and testing without first laying out a plan! The solution was to get people working on a framework that would improve these processes. Such a framework was the CMM. But although CMM improved the management system, it did not improve the way engineers worked. So before teaching engineers the proper method to plan their work he decided to try it out himself. As he wrote programs, he made plans and recorded the time, size and defects for all those programs. This led him to introduce the Personal Software Process (PSP). He also published two books – A Discipline for Software Engineering (1995) and PSP- A Self Improvement Process for Software engineers (2005) to teach engineers the principles of PSP.
Convincing engineers to adopt PSP was in and by itself a challenging task. Engineers as a “breed” are not open to changes unless they have hard evidence that the new method would be more effective. Dr. Humphrey realized that nothing short of compulsion would change their behaviors. PSP was introduced experimentally in 1994 in three companies– Advanced Information Systems (AIS), Motorola and Union Switch & Signals. Dr. Humphrey used the results of these companies to emphasize the importance and effectiveness of PSP. In each company, software engineers were trained in the PSP methods. The effectiveness of PSP was measured based on the results of the individual projects that implemented PSP techniques.
According to Dr. Watts Humphrey, Personal Software Process is a self-improvement process that enables software engineers to “control, manage and improve” their working habits (A Discipline for Software engineering 1). It provides a structured framework with guidelines and procedures that engineers can follow to assess and improve the quality of their work. But plunging directly into the PSP methods could be quite overwhelming. The key to understanding any new technology, is training. PSP training offered by the Software Engineering Institute (SEI) has seven process levels in which each level introduces a new element of PSP successfully building on the previous materials (Appendix B). By the end of the PSP training engineers would be well conversant in PSP methods and would be ready to apply it in the real world.
To truly understand the positive impact PSP has had on the software industry, a thorough examination of a case study is required. The rest of the paper will discuss the effectiveness of PSP by analyzing the results of projects undertaken by Advanced Information Systems (AIS), Illinois.
Advanced Information Systems located in Peoria, Illinois with a subsidiary in Madras, India offers software development, consultancy services, Internet services and process training. They set up business applications for their clients as well as take up contract work at the client site. Initially AIS offered a spring course in PSP outside working hours taught by instructors who were unqualified in PSP. Needless to say, only half the engineers completed the course. Realizing their mistake, AIS sent one engineer to the SEI for PSP instructor training. Subsequently more engineers completed the training and began adopting the techniques (Ferguson et al. 27).
The first project, which applied the PSP methods, was for a Fortune 50 client in 1995. After completing three of the nine components, AIS realized that the project was going to exceed its internal deadline as well as external commitment. In lieu of this, the management decided to train the engineers in the PSP methods. The remaining components: four to nine were then completed after negotiating new deadlines with the client (Ferguson et al. 27). For components four to eight, the schedule estimate was either greater than or equal to actual schedule (fig: 1, Appendix A). Moreover the scheduling estimation error decreased to about -10.4 percent from a whooping 394 percent (fig: 2, Appendix A). In fact, the overall defect density i.e. defects per lines of code improved by 78 percent with 0.76 defects per 1,000 lines of code before PSP training and 0.17 defects per 1,000 lines of code after training (Ferguson et al. 27). This ultimately resulted in an overall productivity of 7.4 percent.
The next three projects were carried out in 1996. All three projects used the same language platform and tools but project B was undertaken by PSP-trained engineers while C and D were not. When acceptance tests were conducted, project C had 11 defects, project D had 6 and project B had only one. However when usage tests were carried out the customers found one defect in project C, none in B and 14 in D (Ferguson et al. 28).
AIS carried out three other projects: projects E, F, G. Projects E and F, with 2,255 and 1,400 lines of code, respectively, both used one PSP-trained engineer. Project G, with 6,196 lines of code, required three engineers, two of whom were trained in PSP (Ferguson et al. 28). All three projects were completed successfully with no defects during customer tests.
The above seven projects clearly illustrate the progression in the overall productivity and quality of the software as more and more engineers were PSP-trained and gained more practical experience. Of particular interest is project E in which the engineer provided the client and the AIS management weekly schedule planning templates so that they could keep track of the project status. These PSP methods not only reduced the need for supervision but also helped shorten the project duration (Ferguson et al. 28). Further these results were typical of the study conducted by the SEI on 298 engineers (Hayes and Over 14).
To further argue the effectiveness of PSP, an examination of an experience report given by one of AIS’s project engineers Jagadish Kamatar would be helpful. He started the first project after undergoing partial PSP training. As a result the engineers overestimated the effort by 10% (Kamatar and Hayes 86). The project team then did a defect analysis to analyze where they had gone wrong. In order to use the methods properly in projects, the engineers need to be well versed in the PSP methods. According to Dr. Watts Humphrey, Limited PSP training inhibits engineers from understanding the concepts well enough to be used in real projects (“ Personal Software Process-Status and trends” 74).
In his second project Kamatar reviewed the defect log with the checklist to make sure that the defects were being caught. The effort estimation accuracy for the second project was an aggregate 6.7 percent overestimate as opposed to aggregate 9.7 percent underestimate in the first project. Moreover the defects removed before compile (Yield) was consistently above 50 percent. With all the above improvements the productivity increased by 62 percent (Kamatar and Hayes 89). He also caught a greater number of defects in his second project thereby improving his skills.
From the experience report given by Jagadish Kamatar it is crystal clear that complete PSP training improves the skills of the engineers helping them develop efficient, reliable software. Dr. Humphrey and the other SEI computer experts concluded that PSP was an effective tool in ensuring an improvement in the four performance dimensions of engineers: estimation and planning, quality of their work, quality of the work produced and the productivity (Introduction to PSP 2).
Many engineers in the field acknowledge the usefulness of PSP and have tried to single out the individual factors that influence the productivity. A team of three software engineers measured the performance of 53 engineers in university settings and used regression methods to identify variables that affect the productivity and quality of the product (Zhong 47). Their results showed that A/FR (appraisal to failure ratio) and Yield are two primary factors (predictors) affecting personal software processes. A/FR is the balance between the review effort and the compile-and-test effort. Yield is the percentage of defects removed before first compile (Zhong, Madhavji and El Emam 78). By understanding the individual factors that influence productivity we can concentrate on those aspects to improve our skills.
Software is being used in high-risk environments like missiles, spacecrafts and medicine. Therefore there exists the need to develop effective, reliable software within the time period. Personal Software Process introduced by Watts Humphrey provides a streamlined approach for software engineers to enhance their performance thereby improving productivity and quality of software. Experimental studies performed by various software engineers, re-iterate this point. PSP is a growing model and its benefits are undeniable. With further research into the critical factors influencing a personal software process, we will get a better understanding of the impacts of PSP method. So lets hail the software guru!
Appendix A
Figure 1: schedule estimates
Ferguson, Pat et al. “Results of Applying the Personal Software Process.” Computer. 30.5 (1997): 24-31.
Ferguson, Pat et al. “Results of Applying the Personal Software Process.” Computer. 30.5 (1997): 24-31.
Appendix B
A brief overview of the seven process levels:
- PSP0 – This is a generic process level in which engineers use the current practices. The new PSP technique introduced is time and defect measures (Humphrey PSP-self improvement process 20).
- PSP0.1 – This process level introduces size measurement as well as a model for engineers to record the problems and solutions to those problems (Humphrey PSP-self improvement process 36).
- PSP1 – This process introduces PROBE, a regression size-estimation technique that uses historic data to determine the size and accuracy of the current project (Humphrey PSP-self improvement process 85).
- PSP1.1 – This process level introduces earned value tracking which provides an easy way to track and report problems (Humphrey PSP-self improvement process 119).
- PSP2 – This process level uses design and code reviews to find defects before testing. Quality measures are also introduced (Humphrey PSP-self improvement process 142-143).
- PSP2.1 – In this level, design specification strategies are introduced to create defect-free programs (Humphrey PSP-self improvement process 216).
- PSP3- This process level covers design verification techniques and methods for engineers to adapt themselves to different environments.
Works Cited
Ferguson, Pat et al. “Results of Applying the Personal Software Process.” Computer. 30.5
(1997): 24-31. Expanded Academic. George Mason U Lib., Fairfax, VA. 31 May 2007 <http://www.expandedacademic.com>.
Hayes, Will and Over, James W. 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.
Humphrey, Watts S. A Discipline for Software Engineering. MA.: Addison-Wesley, 1995
Humphrey, Watts S. Introduction to the Personal Software Process. MA.: Addison-Wesley, 1997
Humphrey, Watts S. PSP-A Self-Improvement Process for Software Engineers. NJ.: Addison-
Wesley, 2005.
Humphrey, Watts S. “The Personal Software Process-Status and Trends.” IEEE Software. 17.6
(2000): 71-76
Johnson, Philip M and Disney, Anne M. “Critical Analysis of PSP Data Quality: Results from a
Case Study.” Empirical Software Engineering. 4 (1999): 295-410.
Kamatar, Jagadish and Hayes, Will. “An Experience Report on Personal Software Process.”
IEEE Software. 17.6 (2000): 85-89 ProQuest. George Mason U Lib., Fairfax, VA. 31 May 2007 <http://www.proquest.com>.
Zhong, Xiaoming, Madhavji, Nazim H. and El Emam, Khaled. “Critical Factors Affecting
Personal Software Processes.” IEEE Software. 17.6 (2000): 76-83 Expanded Academic. George Mason U Lib., Fairfax, VA. 31 May 2007 <http://www.expandedacademic.com>.
Zhong, Xiaoming. Factors influencing a personal software process [thesis]. McGill University.
2000 86 p ProQuest. George Mason U Lib., Fairfax, VA. 31 May 2007 <http://www.proquest.com>.
Home
No comments:
Post a Comment