LEAP

Participants

• CSDL: Carleton Moore
• Affiliates: Digital Equipment Corporation, SUN, NSF, Tektronix, Inc.

Summary

Project LEAP results from a recognition that many software process improvement initiatives suffer from one or more of the following problems:

• Heavyweight development process constraints. For example, many process improvement initiatives require adherence to strict documentation, audit, and development phase constraints.
• Measurement dysfunction. The use of process metrics for employee performance evaluation can lead to "dysfunctional" behavior which skews the metric in the desired direction while compromising overall organizational performance.
• Organization-level analysis and improvement. Typical process measurements aggregate data collected from multiple projects and organizations. Such data takes time to accumulate, analyze, and produce meaningful process improvements.
• Manual data gathering. Measurement may involve time-consuming clerical overhead that lowers the quality of the data and produces resistance to its collection.

• Light-weight. LEAP support must be "light-weight". It must be easy to learn, easy to integrate with existing methods and tools, and above all, not impose significant new overhead on the developer unless that investment of overhead will provide a direct return-on-investment to that same developer.
• Empirical. LEAP support should be quantitative as well as qualitative. Software developer improvement should be able to be shown through measurements of effort, defects, size, and so forth.
• Automated. Light-weight support for empirically-based developer improvement virtually demands some form of automation. On the other hand, automation does not by itself guarantee light-weight processes or meaningful empirical evidence of improvement.
• Portable. As a developer-oriented approach, Project LEAP recognizes that any long-term improvement mechanism must accommodate the fact that software developers change jobs and companies on a regular basis. Useful support cannot be locked into a particular organization such that the developer must "give up" the data and tools when they leave the organization. Rather, LEAP support will be a kind of "personal information assistant" for their software engineering skill set.

To investigate some of the issues of data collection and analysis, I conducted a case study of 16 graduate students in an advanced software engineering course at the University of Hawaii, Manoa. The case study investigated: (1) the relationship between the Leap toolkit's time collection tools and ``collection stage'' errors; and (2) different time estimation techniques supported by the Leap toolkit. The major contributions of this research includes (1) the LEAP design philosophy; (2) the Leap toolkit, which is a novel tool for individual developer improvement and software engineering research; and (3) the insights from the case study about collection overhead, collection error and project estimation.

Software

Publications

Status

Completed. This general area continues to be a research focus in CSDL through the Hackystat project.

Keywords

Personal process improvement, empirically guided software developer improvement.