Albuquerque, J., Coelho, C., & Meira, S. (1998) Practical limits of the PSP model. SoST'98 Symposium on Software Technology.Process Improvement: Putting Software Engineering to Work. Soc. Argentina de Inf. & Invetigacion Oper, Buenos Aires, Argentina; 1998; 230 pp. p.95-100.
Abstract: PSP, Personal Software Process, is a software process management model developed by Watts Humphrey and SEI, Software Engineering Institute. The goal of PSP is to discipline the software engineer to guarantee the discipline of the software process. We present a practical view of the PSP model. We study and use this model and observe some limitations in the course, tables and methodology adopted in the model. We also present practical suggestions if you intend to use the PSP model in a real industrial context.
Anneberg, L. & Ferguson, R. (2000) Personal Software Process (PSP) concept applied to beginning engineers. Computers in Education Journal, vol.10, no.3; July-Sept. 2000; p.6-8.
Abstract: The Personal Software Process (PSP) was designed to help software engineers produce high quality software. PSP helps in the estimating, planning, development of software systems. PSP shows the software engineer how to track performance against other related software systems, and most importantly, it shows the engineer that PSP can guide their work so they can produce quality software. As of today, only experienced practitioners of software engineering have used PSP. However, the rigor of PSP should help novice engineers better manage their time as they design, develop, test and maintain projects. This paper reports the results of a four month study conduct by the LTU Department of Electrical Engineering, with help from the GVSU Computer Science and Information Systems Department. The goal of this study was to apply PSP ideas to an introductory engineering course.
Cannon, R. L. (1999) Putting the Personal Software Process into practice. Proceedings 12th Conference on Software Engineering Education and Training. IEEE Comput. Soc, Los Alamitos, CA, USA; 1999; pp. p.34-37.
Abstract: The purpose of the workshop is to demonstrate the effectiveness of the PSP℠ for software process improvement and how PSP brought it about. Presenters from industry describe how PSP was introduced into their company and what has happened since introduction. They present data to show the benefits of PSP for their software process. Presenters from academia describe how they have introduced PSP into their courses. The goals of the workshop are to demonstrate that PSP can be adopted and can be effective in different industrial settings and to describe how it can be introduced into academic courses.
Capra, M., Escala, D. & Morisio, M. (1997) Adapting the PSP to an SME context. SPI 97. How to Improve: Practice and Experience'. The European Conference on Software Process Improvement. Conference Proceedings. SPI 97, Farnham, UK; 1997; pp. 289-296.
Abstract: This paper describes how the PSP (personal software process) defined by Humphrey (1996, 1997), and specifically the PSPO, has been adapted to be applied in the same way by all members of a software development team in a SME (small/medium enterprise). The adaptation allows each member to collect the same measures and use the same process. Therefore measures con be aggregated at the team level, on an anonymous basis. While final results regarding variations in quality and productivity due to the PSP are not yet available, the experiment demonstrates that the PSP is a superior tool to rationalize the process in SME or small teams, gaining active participation of the staff.
Cardino, G. & Valerio, A. (1999) Tailoring process improvement to small companies using a methodology focused on the individuals. International Conference on Product Focused Software Process Improvement (VTT Symposium 195).Tech. Res. Centre Finland, Espoo, Finland; 1999; 662 pp. p.497-507.
Abstract: Software development is currently characterized by rapid advances in technology, growing complexity required by customers and strong market competition. Small companies often do not have the resources to build the proper organizational framework needed to face these challenges. They can instead apply a bottom-up approach using strategies for personal process improvement. This article presents the ASPIDE project, a process improvement experiment funded by the European Community (Esprit ESSI Project 24331). The focus of the experiment is the introduction the Personal Software Process (PSP) improvement discipline in Socrate Sistemi, a small Italian software company mainly involved in the development of management system for fashion stores. This approach seems to be suitable for small enterprises needed to improve their overall development performances in order to obtain greater competitiveness. The available results show a positive impact on the corporate organization and on the competence of the employees, suggesting also solutions for possible problems.
Carrington, D., McEniery, B., & Johnston, D. (2001) PSP in the large class. Proceedings 14th Conference on Software Engineering Education and Training.In search of a software engineering profession.
Abstract: Describes our experience with teaching some elements of the Personal Software Process℠ as part of a second programming course. A distinctive feature was the class size of more than 360 students. The goals were to help students develop good software development habits early, and to encourage them to see software development as a systematic discipline rather than a trial-and-error activity. The results indicate partial success, with indicators for future improvement. We hope that other people will be able to build on our experience of teaching the concepts of PSP to large groups of students.
Couprie, D. (1998) Automated Support for a Custom Personal Software Development Process. Masters Thesis, DEPARTMENT OF COMPUTER SCIENCE, CALGARY, ALBERTA.
Abstract: The Personal Software Process is a software development process that allows the individual to apply industrial level discipline to his or her practice. It is taught through a course at post-secondary institutions as well as selected companies.
While the PSP methods are helpful, many students are discouraged from using PSP. Its detailed record keeping carries a high overhead cost. In addition, software development tasks like requirements and documentation are not covered in PSP.
It is believed that the cost to perform PSP can be reduced through providing automated support for PSP activities. It is also believed that the PSP can become a basis for developing a custom personal software process.
The investigation focuses on the development and implementation of PSP Manager. It supports the PSP data collection activities and allows the user to adjust the default PSP to confirm to his software development practices.
Disney, A. (1998) Data Quality Problems in the Personal Software Process. M.S. Thesis, University of Hawaii, August, 1998.
Abstract: The Personal Software Process (PSP) is used by software engineers to gather and analyze data about their work and to produce empirically based evidence for the improvement of planning and quality in future projects. Published studies have suggested that adopting the PSP results in improved size and time estimation and in reduced numbers of defects found in the compile and test phases of development. However, personal experience using PSP in both industrial and academic settings caused me to wonder about the quality of two areas of PSP practice: collection and analysis. To investigate this I built a tool to automate the PSP and then examined 89 projects completed by nine subjects using the PSP in an educational setting. I discovered 1539 primary errors and analyzed them by type, subtype, severity, and age. To examine the collection problem I looked at the 90 errors that represented impossible combinations of data and at other less concrete anomalies in Time Recording Logs and Defect Recording Logs. To examine the analysis problem I developed a rule set, corrected the errors as far as possible, and compared the original and corrected data. This resulted in substantial differences for numbers such as yield and the cost-performance ratio. The results raise questions about the accuracy of published data on the PSP and directions for future research.
Disney, A. & Johnson, P. (1998) Investigating Data Quality Problems in the PSP. Sixth International Symposium on the Foundations of Software Engineering (SIGSOFT'98), Orlando, FL., November, 1998.
Abstract: The Personal Software Process (PSP) is used by software engineers to gather and analyze data about their work. Published studies typically use data collected using the PSP to draw quantitative conclusions about its impact upon programmer behavior and product quality. However, our experience using PSP in both industrial and academic settings revealed problems both in collection of data and its later analysis. We hypothesized that these two kinds of data quality problems could make a significant impact upon the value of PSP measures. To test this hypothesis, we built a tool to automate the PSP and then examined 89 projects completed by ten subjects using the PSP manually in an educational setting. We discovered 1539 primary errors and categorized them by type, subtype, severity, and age. To examine the collection problem we looked at the 90 errors that represented impossible combinations of data and at other less concrete anomalies in Time Recording Logs and Defect Recording Logs. To examine the analysis problem we developed a rule set, corrected the errors as far as possible, and compared the original and corrected data. This resulted in significant differences for measures such as yield and the cost-performance ratio, confirming our hypothesis. Our results raise questions about the accuracy of manually collected and analyzed PSP data, indicate that integrated tool support may be required for high quality PSP data analysis, and suggest that external measures should be used when attempting to evaluate the impact of the PSP upon programmer behavior and product quality.
Escala, D. & Morisio, M. (1998) A metric suite for a team PSP. Proceedings Fifth International Software Metrics Symposium.Metrics. IEEE Comput. Soc, Los Alamitos, CA, USA; 1998; pp. p.89-92.
Abstract: The PSP (Personal Software Process) defined by Watts Humphrey (1997) is based on the definition of a personal process, and its monitoring and improvement through a set of metrics. The process and the related metrics are designed to be used by a single person. We have modified the PSP to be used in a consistent way by a team, introducing the personal and the team level and defining their interactions. This paper presents the team PSP as far as the metrics and the tool are concerned.
Ferguson, P., W. S. Humphrey, S. Khajenoori, S. Macke, A. Matvya (May 1997) Results of Apply the Personal Software Process. IEEE Computer, p. 24-31.
Gotterbarn, D. (1998) Cleanroom, PSP, and the Software Development Impact Statement: Developing the Right Attitude. 12th Conference on Software Engineering Education and Training, 22 - 24 March, 1999, New Orleans, Louisiana.
Abstract: The traditional distinction between education as something which is done at a university and training as something which is done by industry, is not only incorrect but the focus on this distinction leads us to ignore more critical issues in the development of competent sofnYare engineers. The adequacy and success of a variety of delivery techniques for the education and training of software engineers are discussed using three software development tools as examples. From this foundation, I argue that our traditional understanding of training is too limited and must be modified to develop software engineers who are competent to meet the changing needs of their employers and their profession. The traditional distinction between education as something which is done at university and training as something which is done by industry is not only an incorrect distinction but the focus on this distinction leads us to ignore more critical issues in the development of competent sofhYare engineers. The adequacy and success of a variety of delivery techniques for the education and training of sofmare engineers are discussed using three software development tools as examples. From this foundation, I argue that our traditional understanding of training is too limited and must be modified to develop software engineers who are competent to meet the changing needs of their employers and their profession
Green, G. & Hevner, A. (2000) The Successful Diffusion of Innovations: Guidance for Software Development Organizations. IEEE Software, 17(6), p. 96-103.
Gibson, R. (1998) Software process modeling: theory, results and commentary. Proceedings of the Thirty-First Hawaii International Conference on System Sciences. IEEE Comput. Soc, Los Alamitos, CA, USA; 1998; 7 vol. 3, pp. p.399-408.
Abstract: As an emerging technology, the effectiveness and potential impact of process improvement efforts have been debated, but not fully tested or validated. At the very core of this technological evolution is the idea that the quality of a software product is highly dependent on the quality of the process used for its development. Branching from this central idea are three categories of innovations: process models; modeling techniques; and the novel concept of process maturity assessment. The purpose of this paper is to examine the current state-of-the-practice regarding software process models, modeling techniques and assessments. Particular attention is directed at a process improvement initiative, Humphrey's (1997) Personal Software Process.
Guido, C., Baruchelli, F., & Valerio, A. (1998) Improving small companies' development process through the adoption of the Personal Software Process. CONQUEST '98.Conference on Quality Engineering in Software Technology. ASQF, Erlangen, Germany; 1998; 221 pp. p.125-133.
Abstract: This article presents the current results of ASPIDE, a process improvement experiment funded by the European Community (Esprit ESSI Project 24331). The focus of the experiment is the introduction of the Personal Software Process (PSP) improvement discipline in Socrate Sistemi, a small Italian software company mainly involved in the development of management systems for clothing and shoe stores. This strategy seems to be the best fit, among others, to fulfil the needs of market competitiveness and process improvement of small companies: only with a bottom-up effort, starting from the skill and responsibility of the software engineers, a small organization can improve in a feasible way. The available results show a positive impact on the corporate organization and on the competence of the employees, suggesting also solutions for possible problems.
Grove, R. (1998) Using the personal software process to motivate good programming practices. Proceedings of the 6th annual conference on the teaching of computing/3rd annual conference on integrating technology into computer science education on Changing the delivery of computer science education, August 18 - 21, 1998, Dublin Ireland, p. 98-101.
Abstract: A reduced form of the Personal Software Process was used in two introductory programming courses to help students learn the value of a proper programming methodology. Students collected data during the development of their programming projects and that data was summarised and presented to the class as a whole. From the data, students were able to conclude on their own the value of early software development stages (planning, design and review) in reducing debugging time and in producing better quality software.
Hayes, W. (1998) Using a Personal Software Process(SM) to Improve Performance. 5th. International Symposium on Software Metrics, November 20-21, 1998, Bethesda, Maryland.
Hayes, W. & Over, J. W. (1997) The Personal Software Process (PSP): An Empirical Study of the Impact of PSP on Individual Engineers. CMU/SEI-97-TR-001.
Abstract: The use of software measurement and process definition by individual engineers is embodied in the Personal Software Process (PSP)SM, a collection of techniques and guidelines for individual software engineers to use in building software. This paper presents a brief overview of the PSP and summarizes data collected by engineers in order to illustrate the efficacy of the PSP. Implications for the use of methods associated with statistical process control are discussed, and the power of rigorous data collection by individual software engineers is highlighted through discussion of empirical data.
Hilburn, T. B. (1999) PSP Metrics in Support of Software Engineering Education. 12th Conference on Software Engineering Education and Training, 22 - 24 March, 1999 New Orleans, Louisiana.
Abstract:This paper describes a position aboutuse of the Personal Software Process (PSP) metrics that was presented in theworkshop: "Software Metrics: Views from Education, Research, and Training". The position presented here, describes how and why PSP metrics can be used inteaching and learning about software engineering.
Hilburn, T. B. & M. Towhidnejad (1997) Doing Quality Work: The Role of Software Process Definition in the Computer Science Curriculum. Proceedings of the Twenty-eighth SIGCSE Symposium on Computer Science Education. San Jose, CA, February 27-March 1, 1997.
Abstract: This paper discusses the role of personal software process definition in the education of computing professionals and the importance of emphasizing quality in the development of software. After examining recent government and industry efforts in introducing and instituting effective software development processes, there is a description of the Capability Maturity Model (CMM) and Watts HumphreyÕs Personal Software Process (PSP) and its use in industry and academia. The rest of the paper reports on a recent project that introduced PSP concepts into CSl and CS2. Project methods and activities are described and the results of the project are analyzed. Finally, future enhancements and extensions of the project are discussed.
Hilsop, G. W. (1999) Teaching process improvement in a graduate software engineering course. FIE'99 Frontiers in Education. 29th Annual Frontiers in Education Conference. Designing the Future of Science and Engineering Education.
Abstract: This presentation discusses the experience at Drexel University (USA) in using the Personal Software Process (PSP) to teach software process improvement in a graduate software engineering course. The presentation describes the context in which the PSP is used and discusses issues related to students, course structure, PSP features, and instructor load. The faculty members participating in this work believe that the PSP is a very effective approach to teaching about process improvement and to enhancing students' understanding of software engineering. The presentation includes some preliminary results that provide insight into the impact of the course on student attitudes toward software engineering. This data is drawn from a post course survey administered six to eighteen months after students completed the course. The survey data also provides information about adoption of the PSP by the students after they complete the course. The presentation provides a useful summary of experience for faculty members considering teaching the PSP.
Holmes, J. S. & Melhart, B. E. (1998) A phased approach to the PSP. Sixteenth Annual Pacific Northwest Software Quality Conference Joint ASQ Software Division's Eighth International Conference on Software Quality. PNSQC, Portland, OR, USA; 1998; p.289-299.
Abstract: Completing the exercises for learning Humphrey's Personal Software Process (PSP) is a monumental task. After the developer has reached this milestone, what next? Implementing the PSP into an industrial setting can be very frustrating. This paper suggests ways to reduce the amount of frustration experienced by developers as they apply the practices of the PSP in their daily work activities. A process for introducing the PSP into a developer's work and results from using this process are described.
Höst, M. & Wohlin, C. (1998) An experimental study of individual subjective effort estimation and combinations of the estimates. Proceedings of the 1998 international conference on Software engineering April 19 - 25, 1998, Kyoto, Japan, p. 332-339.
Abstract: The required effort of a task can be estimated subjectively in interviews with experts in an organization in different ways. Interview techniques dealing with which type of questions to ask are evaluated and techniques for combining estimates from individuals into one estimate are compared in an experiment. The result shows that the interview technique is not as important as the combination technique. The estimate which is best with respect to mean value and standard deviation of the effort is based on an equal weighting of all individual estimates. The experiment is performed within the Personal Software Process (PSP).
Hou, L. & Tomayko, J. (1998) Applying the Personal Software Process in CS1: An Experiment. Twenty-ninth SIGCSE technical symposium on Computer science education February 26 - March 1, 1998, Atlanta, GA.
Abstract: The authors conducted an experiment in applying components of the Personal Software Processs (PSP)described in Humphrey[2,3] to a large group of CSl students. Half of the students were taught selected PSP principles and the other half were asked only to keep track of total time spent on programming assignment. Results indicate-that PSP is of value not only to software professionals involved in large projects, or to students in a software engineering school, but also to novices at the CS1 level, regardless of their background.
Humphrey, Watts S. (2002) Three Process Perspectives: Organization, Teams, and People. Annals of Software Engineering , Volume 14, 2002, pages 39-72.
Abstract: This paper provides the author's personal views and perspectives on software process improvement. Starting with his first work on technology assessment in IBM over 20 years ago, Watts Humphrey describes the process improvement work he has been directly involved in. This includes the development of the early process assessment methods, the original design of the CMM®, and the introduction of the Personal Software Process SM (PSP℠ ) and Team Software Process℠ (TSP℠ ). In addition to describing the original motivation for this work, the author also reviews many of the problems he and his associates encountered and why they solved them the way they did. He also comments on the outstanding issues and likely directions for future work. Finally, this work has built on the experiences and contributions of many people. Mr. Humphrey only describes work that he was personally involved in and he names many of the key contributors. However, so many people have been involved in this work that a full list of the important participants would be impractical.
Humphrey, W. S. (2000) The Personal Software Process: Status and Trends. IEEE Software, 17(6), p. 71-75.
Humphrey, W. S. (2000) Softwae - A performing science? Annals of Software Engineering, 10, pp. 261-271.
Humphrey, W. S. (2000) The Personal Software Process: Status and Trends. IEEE Software, 17(6), p. 71-75.
Humphrey, W. (1999) Pathways to Process Maturity: The Personal Software Process and Team Software Process. SEI Interactive 2(2), June 1999.
Humphrey, Watts S. (1998) Three Dimensions of Process Improvement:
Humphrey, W. S. (May 1998) Why don't they practice what we preach? Software Engineering Institute, Carnegie Mellon University. Also appears in Annals of Software Engineering 6, 1998, p. 201-222.
Humphrey, W. S. (1997) What do we know about programming?. seventh workshop on Empirical studies of programmers, October 24 - 26, 1997, Alexandria, VA USA p. 224-232.
Abstract: This brief paper summarizes an invited talk I gave at the 7th Workshop on Empirical Studies of Programmers, in Alexandria, VA, on October 24-26, 1997. The paper describes the methods of the Personal Sothvare Process (PSP) and shows how PSP data can be used to illuminate some questions about programming work. The paper concludes with two additional questions that need to be addressed as the software business grows and matures. To keep this paper at a reasonable size, I only include selections of the PSP data I showed in the talk.
Humphrey, W. S. (May 1996) Using a Defined and Measured Personal Software Process. IEEE Software. p. 77-88.
Humphrey, W. S. (July 1995) Why Should You Use A Personal Software Process? Software Engineering Notes 20(3), p 33-36.
Humphrey, W. S. (1994) The personal process in software engineering. Proceedings.Third International Conference on the Software Process. Applying the Software Process (Cat. No.94TH8001). IEEE Comput. Soc. Press, Los Alamitos, CA, USA; 1994; pp. p.69-77.
Abstract: The personal software process (PSP) provides software engineers a way to improve the quality, predictability, and productivity of their work. It is designed to address the improvement needs of individual engineers and small software organizations. A graduate level PSP course has been taught at six universities and the PSP is being introduced by three industrial software organizations. The PSP provides a defined sequence of process improvement steps coupled with performance feedback at each step. This helps engineers to understand the quality of their work and to appreciate the effectiveness of the methods they use. Early experience with the PSP shows that average test defect rate improvements of ten times and average productivity improvements of 25% or more are typical.
Humphrey, W. S. (1994) Process feedback and learning. Proceedings.Ninth International Software Process Workshop. IEEE Comput. Soc. Press, Los Alamitos, CA, USA; 1994; p.104-106.
Abstract: The personal software process (PSP) has been developed by the Software Engineering Institute (SEI) to address the need for process improvement in small organizations and projects. Its principal focus is to help individual software engineers and small software teams to improve their performance. The PSP provides engineers with a defined sequence of improvement actions and explicit feedback on their performance at each step. This helps them to improve the quality of their work and to understand the effectiveness of the methods they use. A PSP course has been developed to show students how to define, measure, analyze, and improve their personal software development practices. This graduate or senior level undergraduate course is currently being taught at six universities. The PSP is also being tested at four industrial software organizations. Early results indicate that the method effectively motivates engineers to use a disciplined personal process and to strive for personal process improvement.
Johnson, P. & Disney, A. (1998) The Personal Software Process: A Cautionary Case Study. IEEE Software, 15(6), November, 1998.
Abstract: In 1995, Watts Humphrey introduced the Personal Software Process in his book, A Discipline for Software Engineering. Programmers who use the PSP gather measurements related to their own work products and the process by which they were developed, then use these measures to drive changes to their development behavior. After almost three years of teaching and using the PSP, we have experienced the educational benefits of the PSP. As researchers, however, we have also uncovered evidence of certain limitations, which we believe can help improve appropriate adoption and evaluation of the method by industrial and academic practitioners. This paper presents an overview of a case study we performed that presents evidence of potential data quality problems, along with recommendations for those interested in adopting PSP within industry or academia.
Johnson, P. & Disney, A. (1999) A Critical Analysis of PSP Data Quality: Results from a Case Study. Journal of Empirical Software Engineering. February, 1999.
Abstract: The Personal Software Process (PSP) is used by software engineers to gather and analyze data about their work. Published studies typically use data collected using the PSP to draw quantitative conclusions about its impact upon programmer behavior and product quality. However, our experience using PSP led us to question the quality of data both during collection and its later analysis. We hypothesized that data quality problems can make a significant impact upon the value of PSP measures---significant enough to lead to incorrect conclusions regarding process improvement. To test this hypothesis, we built a tool to automate the PSP and then examined 89 projects completed by ten subjects using the PSP manually in an educational setting. We discovered 1539 primary errors and categorized them by type, subtype, severity, and age. To examine the collection problem we looked at the 90 errors that represented impossible combinations of data and at other less concrete anomalies in Time Recording Logs and Defect Recording Logs. To examine the analysis problem we developed a rule set, corrected the errors as far as possible, and compared the original and corrected data. We found significant differences for measures such as yield and the cost-performance ratio, confirming our hypothesis. Our results raise questions about the accuracy of manually collected and analyzed PSP data, indicate that integrated tool support may be required for high quality PSP data analysis, and suggest that external measures should be used when attempting to evaluate the impact of the PSP upon programmer behavior and product quality.
Kamatar, J. & Hayes, W. (2000) An Experience Report on the Personal Software Process. IEEE Software, 17(6), p. 85-89.
Koch, A. S. (2001) Personal quality management with the Personal Software Process. Proceedings 14th Conference on Software Engineering Education and Training.In search of a software engineering profession.
Abstract: Summary form only given, as follows. Software development organizations have a variety of mechanisms at their disposal to help in managing and improving the quality of the products they produce. Quality assurance organizations, problem reporting systems, software process improvement and peer reviews (to name just a few) are important tools for product quality enhancement, but an often-overlooked piece of the quality puzzle may well provide the most effective means to improve product quality: the individual software engineer. In this paper, we begin with an overview of the ways in which individual engineers (and their organizations) can benefit from adding the Personal Software Process's (PSP's) personal quality management techniques to their professional repertoires. We take a brief look at the benefits that have been achieved by those who have already learned to apply these principles in their work. Then we examine in more detail the specific activities PSP-trained engineers engage in to manage the quality of the software they produce. We look at everything from simple defect logging, to personal and peer reviews, to developing a personal quality plan and using it to guide your work.
Kopanas, V. & Karvounidis, T. (1998) Industrial experiences from introducing the Personal Software Process (PSP). CONQUEST '98.Conference on Quality Engineering in Software Technology. ASQF, Erlangen, Germany; 1998; 221 pp. p.114-124.
Abstract: This paper reports on experiences acquired from a Process Improvement Experiment funded under the European Systems and Software Initiative (ESSI). The experiment, called PIBOP, introduced W.H. Humphrey's (1995) Personal Software Process (PSP) at Intracom's Software Development Centre. PSP, focusing on the individual software engineer, allows for systematic implementation of proven practices on planning, tracking and analysis of software engineering work and products. Through PSP, Intracom is enabled to meet well defined customer needs, to provide reliable and safe products, to increase the productivity of its software engineers and improve its competitiveness as a supplier of software products.
Krishnan, M. & Kellner, M. (1999) Measuring Process Consistency: Implications for Reducing Software Defects. IEEE Trans. on Software Engineering, 25(6), p. 800-815.
Abstract: In this paper, an empirical study that links software process consistency with product defects is reported. Various measurement issues such as validity, reliability, and other challenges in measuring process consistency at the project level are discussed. A measurement scale for software process consistency is introduced. An empirical study that uses this scale to measure consistency in achieving the CMM goal questions in various key process areas (KPAs) in 45 projects at a leading software vendor is reported. The results of this analysis indicate that consistent adoption of practices specified in the CMM is associated with a lower number of defects. Even a relatively modest improvement in the consistency of implementing these practices is associated with a significant reduction in field defects.
Lisack, S. (2000) The Personal Software Process in the Classroom: Student Reactions (An Experience Report). Thirteenth Conference on Software Engineering Education & Training, 6 - 8 March, 2000 Austin, Texas.
Abstract: Most people would agree that the quality of a product is related to the quality of the process used to develop that product. The quality of a computer program is often measured by the number of defects it contains. The Personal Software Process was developed to help programmers measure and improve their personal productivity. A subset of the Personal Software Process has been suggested as appropriate for beginning college students in introductory programming courses. This subset has been used over the past two years in several sections of a large first and second semester programming course, with mixed success. Students recorded data during the development of their lab assignments and major programming project, and submitted these along with their programs. Surveys were taken at the end of each course to determine student attitudes toward the Personal Software Process. Many students failed to recognize the benefits of such a process, and felt that it just took time away from learning the programming language. This paper explores the results of these surveys.
Maletic, J. I., Howald, A., & Marcus, A. (2001) Incorporating PSP into a traditional software engineering course: an experience report. Proceedings 14th Conference on Software Engineering Education and Training.
Abstract: This paper presents an approach to incorporate PSP (Personal Software Process) into a traditional software engineering course that is typically contained within a computer science curriculum. Advantages and disadvantages of similar approaches are discussed. The approach has been implemented twice in an undergraduate course at the University of Memphis. This successful experience is described and gives support that the proposed approach is beneficial to both students and educators.
McAlpin, J. & Liu, J. B. (1995) Experiencing disciplined software engineering at the personal level. IEEE Pacific Rim Conference on Communications, Computers, and Signal Processing.Proceedings. IEEE, New York, NY, USA; 1995; pp. 124-127.
Abstract: Personal Software Process (PSP) is a new process management technique based on personal software development statistics developed at the Software Engineering Institute. This paper discusses the experiences we have gained in implementing PSP in software development and a new disciplined software engineering certificate program developed based on PSP and Capability Maturity Model (CMM).
Miller, J. & Mingins, G. (1998) Putting the practice into software engineering education. Proceedings.1998 International Conference Software Engineering: Education and Practice. IEEE Comput. Soc, Los Alamitos, CA, USA; 1998; pp. p. 200-208.
Abstract: The paper describes a subject called Software Engineering Practise, which introduces software engineering concepts to students in a generalist computing degree. The course has three aims: to establish a foundation of good practice which will form the basis for a personal software improvement process in subsequent studies and in professional life; to introduce object oriented design in a context firmly embedded in software engineering; and to give students a taste of working in groups on a reasonably large project. The success of this course is due to the way in which the object oriented design, the software engineering process aspects and the project work so well together to bring the concepts associated with each part of the course to life and to reinforce each other in a relatively realistic context. Other aspects, which contribute to the success of the course, such as the team approach to course management, individual student assessment, and choice of development environment, are also highlighted.
Mingins, G., Miller, J., Dick, M., & Postema, M. (1999) How we teach software engineering. JOOP.vol.11, no.9; Feb. 1999; p.64-6, 74.
Abstract: For several years we have been teaching software engineering using object-oriented principles. The success of the course comes from the way in which object-oriented design, the software engineering process and the case study work so well together. An essential ingredient in the recipe is Eiffel, which provides not only an attractive integrated development environment, but also a whole life-cycle method and language supporting the software engineering principles we are attempting to impart. We have achieved a balance between the conflicting requirements of dealing with the complexities of real-world software engineering based on large projects, and the need to establish a firm personal software process that students can use as a basis for reflection and further professional development.
Morisio, M. (2000) Applying the PSP in Industry. IEEE Software, 17(6), p. 90-95.
Phipps, G. (1999) Comparing observed bug and productivity rates for Java and C++. Software --Practice-and-Experience.vol.29, no.4; 10 April 1999; p.345-58.
Abstract: An experiment was conducted to compare programmer productivity and defect rates for Java and C++. A modified version of the Personal Software Process (PSP) was used to gather defect rate, bug rate, and productivity data on C++ and Java during two real world development projects. A bug is defined to be a problem detected during testing or deployment. A defect is either a bug, or an error detected during compile time. A typical C++ program had two to three times as many bugs per line of code as a typical Java program. C++ also generated between 15 per cent and 50 per cent more defects per line, and perhaps took six times as long to debug. Java was between 30 per cent and 200 per cent more productive, in terms of lines of code per minute. When defects were measured against development time, Java and C++ showed no difference, but C++ had two to three times as many bugs per hour. Statistics were generated using Student's t-test at a 95 per cent confidence level. Some discussion of why the differences occurred is included, but the reasons offered have not been tested experimentally. The study is limited to one programmer over two projects, so it is not a definitive experimental result. The programmer was experienced in C++, but only learning Java, so the results would probably favour Java more strongly for equally-experienced programmers. The experiment shows that it is possible to experimentally measure the fitness of a programming language.
Postema, M., Dick, M., Miller, J. & Cuce, S. (2000) Tool support for teaching the Personal Software Process. Computer Science Education, vol. 10, no. 2, 2000, p.179-193.
Abstract: Software engineering education can be viewed as a challenging task. Computer science students tend to focus on the programming aspects of a project and take a "hacking approach" to completing a project, rather than viewing the process as a whole. Our course material includes teaching the Personal Software Process (PSP). Students are required to produce defect and effort metrics, as well as project summary reports. Tools to assist with information recording and the production of reports are difficult for students to access. The cost in terms of finance and learning time is usually too high at the educational level to justify using commercial tools that are available for the professional software engineer. We have developed a tool - the Personal Assistant for Software Engineers - to aid students in the learning of the PSP. The tool has been successfully used in four subjects for a semester. Following feedback and evaluation, it has been re-designed and is currently in Stage 2. The tool has been useful for students and has automated the previous manual process of producing time and defect reports, along with project summaries, thus allowing them to focus on the meaning of the information.
Prechelt, L. & Unger, B. (2001) An Experiment Measuring the Effects of Personal Software Process (PSP) Training. IEEE Transactions on Software Engineering, Vol. 27, No. 5, May 2001, pp. 465-472.
Abstract: The Personal Software Process is a process improvement methodology aiming at individual software engineers. It claims to improve software quality (in particular defect content), effort estimation capability, and process adaptation and improvement capabilities. We have tested some of these claims in an experiment comparing the performance of participants who had just previously received a PSP course to a different group of participants who had received other technical training instead. Each participant of both groups performed the same task.
We found the following positive effects: The PSP group estimated their productivity (though not their effort) more accurately, made fewer trivial mistakes, and their programs performed more careful error-checking; further, the performance variability was smaller in the PSP group in various respects. However, the improvements are smaller than the PSP proponents usually assume, possibly due to the low actual usage of PSP techniques in the PSP group.
We conjecture that PSP training alone does not automatically realize the PSP's potential benefits (as seen in some industrial PSP success stories) when programmers are left alone with motivating themselves to actually use the PSP techniques.
Prechelt, L. & Unger, B. (1999) A controlled experiment on the effects of PSP training: Detailed description and evaluation.
Abstract: The Personal Software Process (PSP) is a methodology for systematic and continuous improvement of an individual software engineerÕs software production capabilities. The proponents of the PSP claim that the PSP methods improve in particular the program quality and the capability for accurate estimation of the development time, but do not impair productivity.
We have performed a controlled experiment for assessing these and related claims. The experiment compares the performance of a group of students that have just previously participated in a PSP course to a comparable set of students from a ÒnormalÓ programming course. This report presents in detail the experiment design and setup, the results of the experiment, and our interpretation of the results.
The results indicate that the claims are basically correct, but the improvements may be a lot smaller than expected. However, we found an important additional benefit from PSP that is not usually mentioned by the PSP proponents: The performance in the PSP group was consistently less variable for most of the many variables we investigated. Less variable performance in a software team greatly reduces the risk in software projects.
Rosca, Daniela, Chao-Ying Li, Kimberly Moore, Mark Stephan and Steven Weiner (2001) PSP-EAT - ENHANCING A PERSONAL SOFTWARE PROCESS COURSE. FIE 2001, Reno, NV, Oct. 10-13, 2001.
Abstract: The main objective of teaching the Personal Software Process (PSP) is to develop in students a professional attitude towards producing software. PSP improves performance in size and effort estimation accuracy, software reusability, product quality while maintaining or increasing overall productivity. This work presents the experience of the first author in teaching PSP at graduate level for three years, and a tool, PSP-EAT, we have built to reduce both student and instructor clerical work in learning and teaching PSP. The tool helps also in increasing the studentsÕ data collection accuracy and their receptability to the PSP principles.
Runeson, P. (2001) Experience from Teaching PSP for Freshmen. Conference on Software Engineering Education & Training, Charlotte, NC, 2001.
Abstract: The Personal Software Process (PSP) is launched as a means for improving software development capabilities for the individual engineer. It is proposed that it should be used in software engineering curricula; some authors propose it to be used already during the first student year. The PSP course is successfully given for graduate students at Lund University since 1996. During the spring semester of 1999, it was given to undergraduate students at the software engineering program in their first year of university studies, directly after their first programming course. This paper reports results and experiences from the course given to these freshmen students. A quantitative analysis is conducted to compare the freshmen student data to data from graduate student courses, and a qualitative evaluation is conducted concerning the differences between the courses. It can be concluded that mostly the same improvement trends can be identified with freshmen students as with graduate students. However, the qualitative analysis shows that the freshmen students are more concerned with programming than with the software process issues. Based on the results, it is decided to move the PSP course to the second year in order to enable the programming skills to be better established before the PSP is launched.Sauer, L., Lindquist, T., & Cairney, J. (1999) Tracking Personal Software Process in Group Projects. Twenty-Third Annual International Computer Software and Applications Conference, 25 - 26 October, 1999, Phoenix, Arizona.
Abstract: Software engineering continues to develop methods for process improvement and quality. The Personal Software Process is one way to introduce software engineers to aspects of process tracking, assessment and improvement. In this paper, we describe the software tools that we've constructed to support the planning and postmortem of software activities. We describe an approach that allows the personal software process to be used in group projects, while still allowing the individual engineer to employ personal process quality and improvement techniques in their own activities. The tools supporting planning and postmortem are used in the context of a workflow system developed at Arizona State University (ASU), called Open Process Components, whose aim is to componentize software services and provide interoperability among various approaches. These tools and approaches explore software development in the increasingly distributed environment in which the software engineer is responsible for their own assessment and improvement.
Shendil, K. & Madhavji, N. H. (1994) Personal 'progress functions' in the software process. Proceedings. Ninth International Software Process Workshop. IEEE Comput. Soc. Press, Los Alamitos, CA, USA; 1994; pp. 117-21.
Abstract: Individual developers can expect improvement in software productivity as a consequence of (i) a growing stock of knowledge and experience gained by repeatedly doing the same task (first-order learning) or (ii) due to technological and training programs supported by the organization (second-order learning). Organizations have used this type of progress behavior in making managerial decisions regarding cost estimation and budgeting, production and staff scheduling, product pricing, etc. Such progress is studied in productivity, product-quality and personal skills, in an experiment involving a sample of 12 software developers, who complete one project every week for ten weeks. Second-order training is provided to the subjects through Humphrey's Personal Software Process. A modified GQM method for measurement is used to execute the research method.
Silberberg, D. (1998) Applying the personal software process (PSP) with Ada. Proceedings of the ACM SIGAda annual international conference on Ada technology, p. 219-.
Abstract: This report documents my successful experience applying the Personal Software Process to Ada software development. Using the PSP data generated during the completion of my PSP Instructor training at the Software Engineering Institute (SEI), this report shows examples of these improvements (e.g., improved size and time estimating accuracy, reduction of the amount of total project time spent in the compile and test phases, removal of design defects earlier, improved defect removal yield, etc.). I completed this training with Ada95 using the GNAT Ada95 compiler (version 3.04) on a Unix system. This experience report also provides a brief introduction to the PSP and compares the PSP with the Capability Maturity Model for Software (CMM). It analyzes the process and product data collected during my PSP Instructor training to highlight how Ada in conjunction with the PSP helped me to improve the quality of my software products.
Smith, M. R. (1997) Parachuting software engineering practices into the hostile environment of 4th year final term. Proceedings.Frontiers in Education 1997, 27th Annual Conference. Teaching and Learning in an Era of Change
Abstract: Two years ago, an elective 4th year microprocessor course taught to a small class of 35 was switched to become a compulsory 3rd year course taught to 150. Student grades became bimodal, either D+/C- or A-/A, and the instructor's teaching evaluation plummeted. A rework of the program the following year made no significant difference. To overcome these problem, elements from Humphrey's personal software process were parachuted into the undergraduate program. Modified versions of the earned value analysis procedure and review sheets were developed, together with a defect analysis approach directed towards improving the manner in which laboratories were handled.
Wesslèn, A. (2000) A Replicatied Empirical Study of the Impact of the Methods in the PSP on Individual Engineers. Empirical Software Engineering: An International Journal, Vol. 5, No. 2, pp. 93-123.
Abstract:The Personal Software Process (PSP) has during the last couple of years gained attention as a way to individual improvements in software development. The PSP is introduced to students and engineers through a course, which introduces a personal software development process. The personal software development process is improved in steps during the course and a collection of methods is introduced to support the personal development process. The question is, however, how do these methods influence the performance of an individual engineer? This question has been studied in a study made at the Software Engineering Institute, and the study has shown that the methods in the PSP have a positive effect on the performance of the individuals. There is however a need to replicate this study to confirm the findings in other settings and with other individuals. This paper describes a replication of the study made at the Software Engineering Institute. Both the original study and this replication are made on data reported from the students taking the PSP course. The differences between the two studies are the programming languages used, which held the courses, the class sizes, and the experiences of the students. In summary, the results from this replication confirm the results in the original study: Size estimation accuracy gets better, the defect density gets lower, the defects are found earlier and that the pre-compile yield gets better during the PSP course. Basically, the two studies show that the methods in the PSP help engineers to improve their performance.
Williams, L. A. (2001) Integrating pair programming into a software development process. Proceedings 14th Conference on Software Engineering Education and Training. IEEE Comput. Soc, Los Alamitos, CA, USA; 2001; p. 27-36.
Abstract: Anecdotal and statistical evidence indicates that pair programmers - two programmers working side-by-side at one computer collaborating on the same design, algorithm, code or test - outperform individual programmers. One of the programmers (the driver) has control of the keyboard/mouse and actively implements the program. The other programmer (the observer) continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects, and also thinks strategically about the direction of the work. On demand, the two programmers can brainstorm any challenging problem. Because the two programmers periodically switch roles, they work together as equals to develop software. This practice of pair programming can be integrated into any software development process. As an example, this paper describes the changes that were made to the Personal Software Process (PSP) to leverage the power of two programmers working together, thereby formulating the Collaborative Software Process (CSP). The paper also discusses the expected results of incorporating pair programming into a software development process in which traditional, individual programming is currently used.
Williams, L. A. (1997) Adjusting the instruction of the personal software process to improve student participation. Proceedings Frontiers in Education 1997, 27th Annual Conference. Teaching and Learning in an Era of Change.
Abstract: No customer is fully satisfied unless they receive a product that does what they want, and they receive it when they want it, defect-free and at an agreed upon price. To address all four of these requirements, Watts Humphrey, at the Software Engineering Institute (SEI), developed the personal software process (PSP), which applies proven quality principles to the work of individual software engineers. PSP was initially taught to practicing software engineers in industry and to graduate students. Earlier this year, Humphrey published a new text, suitable for the beginning software engineering student. This text outlines a process for managing and producing high quality software, reducing the mathematical and statistical rigor of the original PSP, but maintaining a solid base of disciplined practices and an overriding quality philosophy. This paper describes how the PSP has been incorporated into the undergraduate computer science courses at the University of Utah, USA. It highlights how instruction has been adapted to improve student participation, retention and utilization of the material.
Wohlin, C. & A. Wesslèn (1998) Understanding Software Defect Detection in the Personal Software Process. Ninth International Symposium on Software Reliability Engineering, 4 - 7 November, 1998, Paderborn, Germany.
Abstract: There is a general need to understand software defects and our ability to detect defects during different activities. This is particularly important in relation to software process improvement, where one objective may be to decrease the number of defects. The Personal Software Process (PSP) has gained attention during the last couple of years as a way to individual improvement in software development. Thus, the PSP is an interesting starting point to understand software defects and in particular the detection process. This paper presents a study of software defect detection for 59 students taking a PSP course. In summary, the study provides valuable insight into software defect detection in the PSP. Some of the results are interesting not only for the PSP, but from a general perspective in our understanding of software defect detection. The understanding of software defects forms the basis for improving the reliability of software.
Yarar, H. & Kuru, S. (1998) Computer assisted Personal Software Process. European Software Measurement Conference. FESMA 98. Business Improvement through Software Measurement. (A continuation of ESCOM: European Software Control and Measurement Conference). Proceedings. Technologisch Instituut Vzw, Antwerpen, Germany; 1998; 641 pp. p.37-44.
Abstract: This work is related to Personal Software Process (PSP) which is a process assessment and improvement methodology at the personal level. Since the need for quality in the software world is increasing each day, PSP is becoming more popular and its importance is increasing. PSP uses lines of code (LOC) as the main measure for system sizing. With the development of new techniques and tools in the software world, LOC is no more a reliable size measure. Function point analysis (FPA) is a more sound and predictive measure than LOC. FPA is a technology and environment independent system sizing measure. This study proposes using FPA in PSP. A software tool (PSP Assistant) is developed to automate the proposed approach.
Zhong, X., Madhavji, N. & El Emam, K. (2000) Critical Factors Affecting Personal Software Processes. IEEE Software, 17(6), p. 76-83.