Compartimentalisation is often dangerous: there is no big picture supervision, there is a lack of coordination, teams do not share information

Project Risk - Integration Failure
Project Risk - Integration Failure
jdalbey/206/Lectures/Integration Strategies.html
Integration failure is one of the largest areas of technical risk for most projects.
What is integration failure? When the team is unable to combine individually unit tested modules into a complete working system.

Few research efforts have attempted to understand systems development and integration risks. This paper reports preliminary findings, based on an analysis of data gathered via focus groups at an organization poised to embark on an integration project, about how organizational participants perceive these risks.
The prerequisites of success and reasons for failure for code integration projects are still not well-understood as evidenced by large failure rates, including cost or schedule overruns, abandoned projects, and projects delivered with diminished functionality.

These failures point to the inherently human activities of planning and overseeing that are critical to successful large-scale integration. The analysis shows that risk perception is fuzzy, it differs significantly across organizational actors, and points to considerable information asymmetry between risk managers, developers and other project participants.


How does this happen?
1. The team has no source code repository. Developers write their modules independently, and uses the "Big Bang" approach below.

2. The team has a source code repository, but no integration plan and no process to control how units get submitted. Developers are allowed to commit to the repository at will. This is the "Chinese Water Torture" approach below.

Is the a better way?
Yes, the incremental approach described below, which gets realized as an Integration Schedule.


Integration Strategies
Issue: How do we combine individually unit tested modules into a complete system?
---------------
Six Solutions
---------------
Big Bang
Chinese Water Torture
Incremental
Bottom - Up
Top - Down
Threads

----------------------------------------------
Big Bang (or "shake and bake") Method
----------------------------------------------
Throw all the modules together into a large bag and shake vigorously... it usually goes "bang." In other words, integration doesn't begin until all modules are unit tested, then all modules are integrated and tested simultaneously. This is most common when the team has no shared code repository, or developers are "hoarding" their work and not committing it.
Disadvantages
Defects difficult to isolate.
Crucial design features, e.g. interfaces between modules, aren't tested till late when rework is expensive.
Makes no distinction between critical and peripheral parts of the system.
No flexibility in scheduling. Concentrated use of resources (testers).
Progress is very hard to measure. Many projects "die on the vine" because the modules won't integrate.
Advantages
Requires little or no planning. Just hold a "coding party" and keep shoving pizzas under the door.
Coding Party Critique


----------------------------------------------
Chinese Water Torture
----------------------------------------------
Method
The team has a source code repository, but there is no integration planning and no process to control how units get submitted. Developers are allowed to commit to the repository at will. Usually at the end of the work day all developers submit their new code to the repository, and the next morning everyone comes in to find something unexpected broken. Frequently developers spend a large amount of time isolating problems and then reworking their code.
It's like the "big bang" but in slow motion and without the pizza. Excruciating and demoralizing.

----------------------------------------------
Incremental Approach
----------------------------------------------
Method
Implement the interfaces first (this was a requirement in our project; coding and compiling the module headers).
Code and unit test an individual module.
Add the module to the system.
Test and debug the system.
Repeat until the system is complete.
Disadvantages
Requires planning.
Advantages
Defects can be isolated!
Major interfaces are tested first and most frequently.
Testing resources are evenly distributed.
Easier for management to monitor progress. Project behind schedule less likely to be axed.
Implementors see early results - motivating!
The planning process is a kind of design review.
Template for Integration Schedule.
Suggested detailed incremental development process.

----------------------------------------------
Top-Down Approach
----------------------------------------------
Method
Use the incremental approach. The order of integration proceeds from the top of the structure chart down.
Disadvantages
May require "stubs" or "fakes" for lower level modules yet to be coded. Fake come in several varieties:
Do nothing (stub). It compiles okay so you can do a build.
Display a trace message.
Test or display input parameters.
Return a constant value.
Accept input from a tester at the terminal.
Be a simple version of the real module.
UMBRELLA appoach is sometimes more practical than strict Top-Down.
Advantages
Users can be shown a partial version early during implementation to get feedback
Easier for users to deal with overdue project if they have a partial system to work with.
Users may actually use the partial (or skeleton) versions as part of a transition from their current system.
Stubs are easier to write than drivers.

----------------------------------------------
Bottom -Up Approach
----------------------------------------------
Method
Use the incremental approach. The order of integration proceeds from the bottom of the structure chart toward the top.
Disadvantages
Drivers are expensive to write and error prone.
No partial system implemented. (lacks control modules)
Advantages
Lower level modules receive more testing (often key functionality is located here).
In crunch mode, coding can begin early (at the risk of integration failure).


----------------------------------------------
Threads (or "staged") Approach
----------------------------------------------
Method
Use the incremental approach. The order of integration proceeds as follows:
Determine which subset of modules (a "thread") are needed to perform each function required in the specification.
Allocate the threads to "stages," where each stage demonstrates a significant partial functioning system.
Implement in top-down order.
Disadvantages
Requires a lot of planning.
McConnell doesn't like it because it creates partially implemented units.
Advantages
Allows integrators to prioritize the system features to be integrated.
Partial system is available early.
Threads can be implemented in parallel.

Exercise: Can you identify which integration strategy is implied by the directions in this memo?

Learn a simple three-step technique to create an integration schedule for the modules in a class diagram.

(Winter 2011) Discuss: What were the advantages and disadvantages that you experienced following the Crazy Eights integration schedule in lab?