急急急！帮忙翻译下！3Q

wang514

Personal Software Process for Module-Level Development

  




Status
Complete

Purpose and Origin
The Personal Software Process (PSP)1 is a set of advanced process and quality techniques to help software engineers improve their performance in their organizations through a step-by-step, disciplined approach to measuring and analyzing their work. Software engineers that use the PSP can substantially improve their ability to estimate and plan their work and significantly improve the quality, i.e., reduce the defects, in the code they develop. PSP is a result of research by Watts Humphrey into applying process principles to the work of individual software engineers and small software teams [Humphrey 95]. The objective was to transfer the quality concepts of the Capability Maturity Model (CMM)2 for Software [Paulk 95] to the individual and team processes. The PSP provides the foundational skills necessary for individuals to participate on teams using the Team Software Process (TSP)3.


Technical Detail
The foundations of PSP are the advanced process and quality methods that have been used in manufacturing to improve all forms of production. These concepts include the following:

definition of the processes
use of the defined processes
measurement of the effects of the processes on product
analysis of the effects on the product
continuous refinement of the processes based on analysis
Some of the engineering methods used in PSP are data gathering, size and resource estimating, defect management, yield management, and cost of quality and productivity analysis. The basic data gathered in PSP are

the time the engineer spends in each process phase
the defects introduced and found in each phase
the size of the developed product
All PSP process quality measures are derived from this basic set of data. Size and resource estimating is done using a proxy-based estimating method, PROBE [Humphrey 96b], that uses the engineer's personal data and statistical techniques to calculate a new item's most likely size and development time, and the likely range of these estimates. A key PSP tenet is that defect management is an engineer's personal responsibility. By analyzing the data gathered on the defects they injected, engineers refine their personal process to minimize injecting defects, and devise tailored checklists and use personal reviews to remove as many defects as possible. Yield, the principal PSP quality measure, is used to measure the effectiveness of review phases. Yield is defined as the percentage of the defects in the product at the start of the review that were found during the review phase. The basic cost-of-quality measure in PSP is the appraisal-to-failure-ratio (A/FR), which is the ratio of the cost of the review and evaluation phases to the cost of the diagnosing and repair phases. PSP-trained engineers learn to relate productivity and quality, i.e., that defect-free (or nearly so) products require much less time in diagnosing and repair phases, so their projects will likely be more productive.

The PSP (and the courses based on it) concentrates on applying PSP to the design, code, and Unit Test phases, i.e. module-level development phases of software development [Humphrey 95]. As such, an instance of PSP for module-level development is created. In PSP for module-level development, the individual process phases are planning, design, design review, code, code review, compile, test, and postmortem. Size is measured in lines of code and size/resource estimating is done using functions or objects as the proxies for the PROBE method. Engineers build individually tailored checklists for design review and code review based on the history of the defects they inject most frequently. Yield is the percentage of defects found before the first compile, engineers are taught to strive for a 100% yield and can routinely achieve yields in the range of 70%. A/FR is the ratio of the time spent in design review and code review phases to the time spent in compile and test phases, and engineers are encouraged to plan for an A/FR of 2 or higher, which has been shown to correlate well with high yield.

The PSP substantially improves engineering performance on estimating accuracy, defect injection, and defect removal. Class data from 104 engineers that have taken the PSP course shows reductions of 58% in the average number of defects injected (and found in development) per 1,000 lines of code (KLOC), and reductions of 72% in the average number of defects per KLOC found in test. Estimating and planning accuracy also improved with an average 26% reduction in size estimating error and an average 46% reduction in time estimating error. Average productivity of the group went up slightly [Humphrey 96a].


Usage Considerations
The PSP is applicable to new development and enhancement work on whole systems or major subunits. The PSP has been demonstrated and used in organizations at all levels of the CMM. Because PSP emphasizes early defect removal, i.e., spending time in the design through code review phases to prevent and remove as many defects as possible before the first compile, PSP introduction will likely be difficult in organizations that are concerned primarily with schedule and not with product quality.

PSP is an individual development process; however, it can be used by small teams if all members are PSP-trained and team conventions are established for code counting and defect types. PSP does not require sophisticated tools or software development environments; however, simple spreadsheet-based tools can significantly help individual engineers reduce the effort needed to track and analyze their personal data. For teams to apply these principles, the TSP should be applied.

The principles of PSP can be applied to other areas such as developing documentation, handling maintenance, conducting testing, and doing requirements analysis. Humphrey describes how the PSP can be adapted to these and other areas [Humphrey 95].


Maturity
PSP is a relatively new technology. It is already being taught in a number of universities, but industrial introduction has just begun and only limited results are available. Early industrial results are similar to the PSP course results, showing reduced defects and improved quality. Work on industrial transition methods, support tools, and operational practices is ongoing.


Costs and Limitations
PSP training (class room instruction, programming exercises, and personal data analysis reports) requires approximately 10 days of instruction on the part of each engineer. Through the use of 10 programming exercises and 5 reports, engineers are led through a progressive sequence of software processes, taking them from their current process to the full-up PSP for module-level development process. By doing the exercises, engineers learn to use the methods and by analyzing their own data, engineers see how the methods work for them.

Based on demonstrated benefits from course data, it is projected that the costs of training will be recovered by an organization within one year through reduced defects, reduced testing time, improved cycle time, and improved product quality.

Attempts by engineers to learn PSP methods by reading the book and then trying to apply the techniques on real projects have generally not worked. Until they have practiced PSP methods and have become convinced of their effectiveness, engineers are not likely to apply them on the job.

PSP introduction requires strong management commitment because of the significant effort required to learn PSP. It is also recommended that you follow TSP into strategy. Management must provide engineers the time to learn PSP and track their training progress to ensure the training is completed.


Complementary Technologies
The TSP is a follow-up approach to Humphrey's work on PSP. The TSP was designed to provide both a strategy and a set of operational procedures for using disciplined software process methods at the individual and team levels. The TSP has been used with software-only teams and with mixed teams composed of hardware, software, systems, and test professionals. The TSP can be used on teams that typically range in size from 2 to about 150 individuals. The TSP has been used for both new development and enhancement, and on applications ranging from commercial software to embedded real-time systems. It is also applicable in maintenance and support environments. The TSP is being developed for a wider range of project applications, including large multi-teams, geographically distributed teams, and functional teams [McAndrews 00].