3.1 Using the System Architecture as the Starting Point

Essential to developing and maintaining high-quality software is the definition of the system's architecture. The Rational Unified Process states that defining and using a system architecture is one of the six best practices to follow in developing software. A system architecture is the highest level concept of a system in its environment. The Rational Unified Process states that a system architecture encompasses the following:

• The significant decisions about the organization of a software system

• The selection of the structural elements and their interfaces of which the system is composed, together with their behavior as specified in the collaboration among those elements

• The composition of the structural and behavioral elements into progressively larger subsystems

• The architectural style that guides this organization, these elements, and their interfaces, their collaborations, and their composition

A well-documented system architecture improves the software development process. It is also the ideal starting point for defining the structure of your configuration management environment.

Mapping System Architecture to Components

Just as different types of blueprints represent different aspects of a building's architecture (floor plans, electrical wiring, plumbing, and so on), a good software system architecture contains different views to represent its different aspects. The Rational Unified Process defines an architectural view as a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns and omitting entities that are not relevant to this perspective.

The Rational Unified Process suggests using five architectural views. Of these, the implementation view is most important for configuration management. The implementation view identifies the physical files and directories that implement the system's logical packages, objects, or modules. For example, your system architecture may include a licensing module. The implementation view identifies the directories and files that make up the licensing module.

From the implementation view, you should be able to identify the set of UCM components you need for your system. Components are groups of related directory and file elements, which you develop, integrate, and release together. Large systems typically contain many components. A small system may contain one component.

Deciding What to Place Under Version Control

In deciding what to place under version control, do not limit yourself to source code files and directories. The power of configuration management is that you can record a history of your project as it evolves so that you can re-create the project quickly and easily at any point in time. To record a full picture of the project, include all files and directories connected with it. These include, but are not limited to the following:

• Source code files and directories

• Model files, such as Rational Rose files

• Libraries

• Executable files

• Interfaces

• Test scripts

• Project plans

• Compilers, other developer tools, and system header files

• System and user documentation

• Requirements documents

Mapping Components to Projects

After mapping your system architecture to a set of components and identifying the full set of files and directories to place under version control, you need to determine whether to use one project or multiple projects. In general, think of a project as the configuration management environment for a project team working on a specific release. Team members work together to develop, integrate, test, and release a set of related components. For many systems, all work can be done in one project. For some systems, work must be separated into multiple projects. In deciding how many projects to use, consider the following factors:

• Amount of integration required

• Whether you need to develop and release multiple versions of the product concurrently

Amount of Integration

Determine the relationships between the various components. Related components that require a high degree of integration belong to the same project. By including related components in the same project, you can build and test them together frequently, thus avoiding the problems that can arise when you integrate components late in the development cycle.

Need for Parallel Releases

If you need to develop multiple versions of your system in parallel, consider using separate projects, one for each version. For example, your organization may need to work on a patch release and a new release at the same time. In this situation, both projects use mostly the same set of components. (Note that multiple projects can modify the same set of components.) When work on the patch release project is complete, you integrate it with the new release project.

If you anticipate that your team will develop and release numerous versions of your system over time, you may want to create a mainline project. A mainline project serves as a single point of integration for related projects over a period of time. See Chapter 9, Managing Parallel Releases of Multiple Projects for additional information about using a mainline project.

Example

Figure 9 shows the initial set of components planned for the Transaction Builder system. A team of 30 developers work on the system. Because a high degree of integration between components is required, and most developers work on several components, the project manager included all components in one project.

Figure 9 Components Used by Transaction Builder Project