responsive img

Software Integration

responsive img

Software system integration refers to the practice of combining individually tested software components into an integrated whole. Software is integrated when components are combined into subsystems or when subsystems are combined into products. Components may be integrated after all are implemented and tested as in a waterfall model or a "big bang" approach. In either, software system integration appears as a discrete step toward the end of the development life cycle between component development and integration testing. Continuous integration is a much less risky approach wherein the components and subsystems are integrated as they are developed into multiple working mini-versions of the system. Object technologists were early proponents of incremental development, and object-oriented development methods, such as the Unified Process , are based on the principle of ongoing integration practices.

Continuous integration offers several advantages over a waterfall, "big bang" approach. Developers split a product into several builds, or partial products, that can be integrated individually. These builds may be chunked into "vertical" increments, covering subsystems, or increments may cross subsystem boundaries to produce a partial end-to-end product. In both cases, integration is iterative in that a sequence of incremental builds yields results successively closer to the desired product. Customers gain an advantage in seeing a working product early in the development, and developers can verify performance or other quality factors in a working environment, rather than relying on models or simulations. Continuous integration also decreases integration risk, because developers can identify integration problems, often the most complex to address, during early iterations of software integration.

Integration is bound up in the concept of component interfaces. Recall from the "Architecture Definition" practice area that an interface between two components is the set of assumptions that the programmers of each component can safely make about the other component . These assumptions include the component's behavior, the resources it consumes, how it acts in the face of an error, and other assumptions that should be documented as part of a component's interface. This definition is in stark contrast to the simplistic (and quite insufficient) notion of interface that merely refers to the "signature" or syntactic interface that includes only the component's name and parameter types. This definition of interface may let two components compile together successfully, but only the Parnas definition (which subsumes the simpler one) defines how two components work together correctly. When interfaces are defined thoughtfully and documented carefully, integration proceeds much more smoothly, because they define how the components will connect to and work with each other.