Code Integration Pattern

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:

• Establish a plan code integration curve as early in the development cycle as possible. Normally at the beginning of the project, team leaders are able to put down target dates for key activities of the line items they are responsible for, such as design complete, design review complete, code complete and integration, and testing start and completion. Use the plan curve to track the progress of code completion and integration.
• As early as a plan curve is available, study its pattern and take early actions to improve the pattern. For example, the S curve with a concave pattern at the top, such as the example in Figure 9.7, is a normal and healthy pattern. If the S curve shows some steep step increases at the right side, then it is a back-end loaded integration pattern, which may pose risks to testing schedules, defect arrival pattern during testing, and even schedules and quality outcome of the project.
• Perform project-to-project or release-to-release comparisons when baselines are available. Assess the feasibility of the current project based on the comparison results and take early actions.

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.