Search

While the software process improvement movement is relatively recent, the need for improvement is not new. In this paper, the author reviews his personal experiences with software process improvement and describes some of the key events that led to such current widely-used methods as the CMMI, the PSP, and the TSP. He summarizes the principles behind these methods and explains the principal reasons that these highly effective development methods have not been adopted more rapidly. In closing, he notes that their ultimate adoption is inevitable. Copyright © 2007 John Wiley & Sons, Ltd.

Summarizes work initiated at the National Cybersecurity Summit, held 2-3 December 2003 in Santa Clara, California. Attendees representing industry, academia, and the US Department of Homeland Security (DHS) formed five task forces to focus on specific topic areas. This report describes, the key problems and recommendations identified by the Software Process subgroup of the "Security Across the Software Development Lifecycle" task force. Producing secure software is a multifaceted problem of software engineering, security engineering, and management. Thus, producing secure software starts with outstanding software engineering practices, augmented with sound technical practices, and supported by management practices that promote secure software development. We discuss these practices.

This article summarizes the author's invited talk at the Charles Babbage Institute conference on unbundling held in Palo Alto, California, on 23 September 2000. Humphrey, who worked at IBM for many years and was involved in many of the company's software unbundling decisions, was in a unique position to offer his perspectives on why, and how, IBM made its decisions.

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 (PSP)SM and Team Software Process (TSP){SM}. 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.

Technical issues are important for software work, but so are personal disciplines, teamworking skills, and applicationddomain knowledge. Also, much like an artistic performance, firstdclass software engineering requires constant practice, good technique, and effective coaching. The challenge of producing highdquality largedscale software products is substantial today and will be even more demanding in the future. Without concerted action, we cannot expect software organizations' capabilities to improve. To address these problems, the Software Engineering Institute (SEI) has developed the Personal Software Process (PSP) and the Team Software Process (TSP). This paper addresses the problems of software engineering and discusses the intellectual nature of software work. It then reviews the characteristics of this kind of work and describes the principal conditions for effective software performance. In the conclusion, the author makes some observations about the challenges ahead and the future actions required.

One of the most intractable problems in software is getting engineers to consistently use effective methods. The Software Engineering Institute (SEI) has worked on this problem for a number of years and has developed effective methods for addressing it. This paper describes these methods and shows what they have accomplished with several hundred students and working engineers. After first describing the problem of changing engineers’ practices, the paper discusses the logic engineers typically follow in deciding what methods to use. Next is a description of the Personal Software Process (PSP) and the Team Software Process (TSP). Finally, the implications of SEI’s experiences with the PSP and TSP are described, with particular emphasis on software engineering and computer science education.

Improved software processes lead to improved product quality. The Personal Software Process (PSP) is a framework of techniques to help engineers improve their performance-and that of their organizations-through a step-by-step, disciplined approach to measuring and analyzing their work. This article explains how the PSP is taught and how it applies to different software engineering tasks. The author reports some promising early results.

Because of the growing impact of software and its historically poor performance in meeting society's needs, the practice of software engineering is in need of substantial changes. One challenge concerns preparing software professionals for their careers; the field must drastically change its approach to software engineering education if it hopes to consistently provide safe, secure, and reliable systems. This special issue sheds light on some of the issues both academic and industry-based educators must resolve to better address society's need for qualified and capable software professionals.

In 1987 and 1990, the Software Engineering Institute conducted process assessments of the Software Engineering Division (SED) of Hughes Aircraft in Fullerton, CA. The first assessment found the SED to be a level two organization, based on the SEI's process-maturity scale of one to five, where one is worst and five is best. The first assessment identified the strengths and weaknesses of the SED, and the SEI made recommendations for process improvement. Hughes then established and implemented an action plan in accordance with these recommendations. The second assessment found the SEP to be a strong level three organization. The authors outline the assessment method used, the findings and recommendations from the initial assessment, the actions taken by Hughes, the lessons learned, and the business and product consequences. >

A method for projecting software productivity with reasonable accuracy which uses the statistical techniques of time series analysis is described. The measure of productivity is the development time required per line of code. In making productivity projections, the key issue is the need to achieve a balance between forecasting stability and responsiveness to changing conditions. An integrated moving average process of order one, using exponential smoothing of all the previous observations, is judged appropriate for software productivity analysis, particularly where there are limited data available or where conditions are sufficiently varied to make much of the available data inapplicable. Empirical evidence suggests that most commonly encountered time series can be reasonably well described by such methods. The methods for computing the weights used for exponential smoothing are described, as are the means for determining prediction intervals, or measures of forecast uncertainty. This data analytic approach uses historical data alone, unlike structural methods where learning curves as well as prior data are used to define the predictive process. >

The personal software process (PSP) is a structured set of process descriptions, measurements and methods that can help engineers improve their personal performance. The PSP provides the forms, scripts and standards that help them estimate and plan their work. It shows them how to define processes and how to measure their quality and productivity. The PSP acknowledges that everyone is unique and that a method that suits one engineer may not suit another. The PSP helps each engineer measure and track his own work so that he can find the method best for him. >