This article covers the art of deciding which components or segments of a system should be developed and unit tested before others. Which segments should be verified first, to be used to as a basis of test and verification of components and functionality to follow.
Can this actually be controlled? Yep. And a poorly planned integration phase can wreck a job. Ignore this at your own peril.
Example: You are developing an embedded product to integrate sensor inputs, with a user display which enables user comprehension and control. You have a team developing the user interface, and a team developing the sensor interface.
Do you....
Get a set of displays working first, make sure they are rock solid, and use them to check out the sensor integration application, or....
Do you get a set of sensors working working with the application (using tabular lists as the output), test it completely, then use the sensor application to verify the display and control is useful and practical?
One thing you don't want to do is throw everything together at once. This would require the two teams to create their own interface test rig ($$$), and it is certain that they would differ in some very nasty ways.
The goal of integration (hell, any scientific method) is to have only one unknown at a time, while everything else is known - that way when something is wrong, it is clear where the problem is likely to be found. In the simple example above, you may get away with just hooking the two pieces together. But if your system is made up of several subsystems (wireless, memory, user interface, storage, mechanical controllers, displays, redundancy, etc) it is best to determine an order of integration that is most efficient. This depends on the maturity and complexity of the components, which progress during any development based on the effort and difficulty of the task. Most tasks have different maturity schedules. It is all a question of when you tie things down.
A lot of schedules I see shows everyone finishing unit/component testing at once - which then links to "integration", an arbitrary period with no specifically defined order or tasks. Magic happens! It all works!
The method described here addresses that portion of planning, and makes the whole integration/acceptance thing more tractable. It is not perfect, but it is way better than screwing everything together and hitting the power button to see what happens.
As a note, many functional departments "reduce" their estimate by planning only one delivery at the very end, removing the cost of intermediate deliveries to support integration. They remove efforts I just mentioned above to support integration from the bid, thus lower the estimate of expected costs. I have occasionally accepted this, but I never seen this method even coming close to meeting either the original schedule or budget. Interim builds are always required to support project completion.
I have, however, used the method described in this article to come in under budget many times. Even as a exercise for a project manager, that no one else sees or uses, it is beneficial.
As you put together your project plan based on the estimates you receive, you may find that each functional area has assumed that the other functions they depend upon are completely tested, rock solid and bug free when they show up to integrate. This could be true for one area (the last arrival), but can't be true for all in the real world. If you throw it all together at once, it is exactly the opposite of what everyone assumed during their estimates, and you exceed your expected costs - big time.
Pay for the intermediate deliveries to support integration. Keep the number of intermediate deliveries down, because they do cost money. You may need to bump your budget a bit (especially if the estimates were based on the impossible assumption above), but you will finish sooner than other methods, and with a better product.
Here is a completely generic drawing of a typical integration. Note there are four paths, User, Hardware Software, and two Software integrations.
The boxes represent activities, which should be clear enough. The secret is the meaning of the ARROWS.
Each of the arrows represents an expectation. For instance, the Sensor Filter Function has expectations of the Sensor Data integration, which can be described and verified prior to integration. In order to integrate the Remote Support Functions, the Software Integration Must have achieved a certain maturity. Each arrow reflects an expected maturity of the capability by the subsequent user. This expectation can be defined, and this definition is critical to the developing activity. Since expectations are defined, the delivered integration product can be tested to insure that maturity. That way each integration begins with known inputs, and each player knows what will be expected of them. Capture and publish what the arrows contain. Email, text, diagram, whatever.
Ever wonder how people figure out what should be included in Build 1, Build 2, etc? Now you know how to figure this out.
In this drawing, the yellow boxes represent fixed data to use as a baseline for integration. Yes, even the data should be tied down, to produce repeatable results. At some point you go live - presumably, when everything else has been checked out. Start testing with fixed data - or go insane, your pick.
The tan boxes are integration and/or unit tests that occur to establish the various baselines that are required.
The green box shows a breadboard activity. This code or platform may not be production, or even used after the user interface methods are defined. The results of this activity are used to drive the user interface requirements. The arrow between Customer Accept. and User Interface defines what is passed to the User Interface developer - requirements, goals, testing. The arrow before Customer Accept. is what you thought they were looking for, the arrow after Customer Accept. is what you have confirmed. These two arrows could even be versions of the same interface requirement document. Or the input could be a stand up presentation, and the output a video.
Customer witness and acceptance is shown as red boxes. Note that the customer may have intermediate acceptances during development. In the example above, final integration is dependent upon customer acceptance of the User Interface.
The big boxes in the background are locations, functional departments, teammates, or capital assets.
Any one of these arrows could be a deliverable that sponsor demands, if they determine that the success of the product depends heavily on it.
This is just an example, but you can quickly see that each of the recipients of an arrow will probably have very specific expectations of what will be provided by others. Expect to put together several different versions, and push things around a bit based on feedback before settling the whole process out.
Just to stretch your brain a bit, these integrations typically occur in stages - that is, each arrow can have version 1, version 2, version 3, with more functionality/certainty with each version (version 1 supports audio, version 2 supports remote log in, etc). Putting the arrows on the diagram above, provides a framework for an intelligent conversation on the subject. Careful with budget, each "delivery" has a fixed cost, and too many "deliveries" can overwhelm you and your budget. Strive for simplicity.
Theoretically, you can add a time scale on the bottom of the drawing. I have not found this to be very useful. Once you have got the relative dependencies together using this diagram, then go to your planning tool and make something for the other half of your brain.
In fact, your favorite planning tool probably has an output that looks something like this. Examining that mapping could show errors you would not see any other way. But don't show these plots to anybody. Charts developed by analysis tools are notoriously difficult to use. For those of you who are thinking, "He's crazy, I can go straight to MS Project to do this", I don't recommend it. Despite all the marketing, MSProject is an analysis tool, not a design tool. Use MSProject to analyze a diagram like the one above. If you try to use MSProject to design your integration staging, when you next look up, you may notice your your wife has divorced you, moved to Cincinnati, and remarried.
This diagram is an design document to work with before formalizing its output in MS Project, or whatever your integrated planning tool is. The boxes and arrows will get moved around a lot, and most planning tools are numerically based, and the internal calculations get out of hand. Most people understand this type of drawing much more quickly, and can participate without knowing the nuances of manloading and linking tasks. Once you have some agreement, transpose the data into your planning tool, and course correct as necessary. I recommend the first version of this be presented at the Preliminary Design Review, and the final version be included as part of an integrated test plan.
Typically, the first integration uses a formal interface control document (ICD), and works to that document. The followers then assume that the first element is correct and design to be compatible with it. The first element better be correct, since it will be used as a reference. It needs to be rock solid. And certainly, there will be disagreements about what the ICD REALLY means, but straightening these situations out is why we get the big Yankee dollar. And if you do it early, everyone is happier at the end.
What if I am using a standard product, that claims compliance with an ICD? Then the arrow defines what you will check out as a risk reduction, before committing to the function to support of subsequent integration.
Wouldn't hurt to jot up Interface Control notes under the graphic for each of the arrows, and definitions for each of the boxes, too. Graphics tools (like the Google app I used above) have a field for this. In a very formal, large development, each box and arrow could link to it's own document - or at least it's own number or name. You get the idea.
Your problem as a manager: Everyone will want to integrate last, since that gives them the most development time, and a fully functioning system is the best test bed. The person going first has a tougher time, since every test is by hand, and there is less time for development. And the first items need to be rock solid.
Who should get to be last? The toughest one to debug on its own. Who should go first? The most fundamental, immutable element, that can provide concrete results everyone can depend upon.
You may decide based on the personality of the developers. A meticulous, detail oriented (anal-retentive is good) developer should go first, while your arm waving, big picture, imagine this developer should go last.
Draw your boxes, start defining the arrows. Hash it out in the beginning, and everyone will get along much better at the end.