Among the major phases of any development process (i.e., requirements/analysis, design, code, test, and customer validation), code development is perhaps the most fundamental activity. Completion of coding and unit testing, and therefore the inte-gration of code into the system library (to be ready for formal testing) is perhaps the most concrete intermediate deliverable of a project. Code completion by no means implies that the project is near completion. The earlier the code is complete and integrated into the system library relative to the project completion date, the better chance it will be adequately tested . In most software development projects, code completion does not occur only once for the entire project. Different pieces of function are completed at different times, within a certain calendar-time range on the project schedule. There is a common practice of continual code integration into the system library and the starting of component tests (functional tests), usually until the start of system testing. The pattern of code integration over time, relative to the product delivery date, therefore, is a crucial variable for schedule and quality management.
Figure 9.7 shows the code integration pattern of a systems software relative to the product's ship date. The vertical bars are the amount of code completed and integrated into the system library over time. Their values are expressed via the first Y -axis. The S curve is the cumulative percentage of code integrated over time, and is represented by the second Y -axis.
Figure 9.7. Code Integration Pattern of a Systems Software
We call the code integration pattern a pattern, not a model. However, meaningful use of this pattern can make it function like a heuristic model. There are at least three meaningful ways to use it:
Figure 9.8 shows a project-to-project comparison of code integration patterns. Products X, Y, and A are completed projects with positive quality in the field. Product B is a new project in the beginning stage, with the code integration plan just established. Product B's pattern is clearly back-end loaded with steep increases in the S curve up through the end of the code integration cycle. More important, it is significantly different from the other three projects, via the Kolmogorov-Smirnov test (Rohatgi, 1984). If the difference is not statistically significant, the plan can be recovered via effective quality improvement actions and sound project management practices. For examples, break big chunks of functions into smaller pieces and allow the pieces that get done earlier to integrate into the system library earlier, analyze the amount of new function and workload distribution across teams and balance the workload, or take actions on the front-end analysis and design work and attempt to move up the starting date of code integration. When the difference is statistically significant, it means that the feasibility of the project ” on-time delivery with a field quality level similar to that of previous projects ”is in question. In other words, the process capability of the development organization is being challenged. In such cases, the structural parameters of the project may need to be reevaluated. By "structural parameters," we mean the delivery date, the schedule, the amount of functions to be developed and delivered, the quality goals, and so forth. The project team can use this metric to articulate the team's evaluation to the executive project sponsor.
Figure 9.8. Code Integration Patterns of Four Projects
The code integration pattern metric is a simple and useful project management and quality management tool. Its objective fits perfectly with the overall framework of the Rayleigh model that the earlier defect removal, the better. We also recommend that the development team capture its experiences over time and derive its own "heuristic model." The model may include heuristic values of parameters such as a lower limit (the best pattern), an upper limit (the most challenged pattern and yet the project was completed successfully), the largest step function in the code integration process that was handled successfully, the strategies that can transform a negative pattern to an acceptable one, and other meaningful parameters and criteria pertinent to the model's objectives. This metric should be implemented by software projects of all kinds and sizes, and can be implemented easily with well-established tracking system, a simple Lotus 1-2-3 spreadsheet, or pencil and paper.
What Is Software Quality?
Software Development Process Models
Fundamentals of Measurement Theory
Software Quality Metrics Overview
Applying the Seven Basic Quality Tools in Software Development
Defect Removal Effectiveness
The Rayleigh Model
Exponential Distribution and Reliability Growth Models
Quality Management Models
In-Process Metrics for Software Testing
Complexity Metrics and Models
Metrics and Lessons Learned for Object-Oriented Projects
Measuring and Analyzing Customer Satisfaction
Conducting In-Process Quality Assessments
Conducting Software Project Assessments
Dos and Donts of Software Process Improvement
Using Function Point Metrics to Measure Software Process Improvements
A Project Assessment Questionnaire