Objective 1: Minimize Development Costs and Achieve Some Degree of Parallelism

Developing software in a cost-effective manner is the objective of all phases. If you have only started to think about it in Construction, then you will fail to achieve it. However, if you have done Elaboration correctly ”that is, if you have created a baselined, robust executable architecture ”you can develop a more cost-effective software than would otherwise be the case. This is possible since you can reuse architectural mechanisms; you can work in parallel by organizing around the architecture (see the following section, Organize Around Architecture), and you will run into fewer unexpected problems since you have mitigated many major technical risks. In this section, we will look at some of the things that especially larger teams should consider in Construction (and possibly earlier) to ensure successful software development.

Organize Around Architecture

One of the many benefits of a robust architecture is that it clearly divides the system responsibilities into well-defined subsystems. You have an architect or an architecture team worrying about the architecture and how it all ties together, and individuals can focus primarily on their assigned subsystem(s). Developers still need to understand the overall system, but they can focus primarily on a subset of a system, that is, one or several subsystems assigned to them. Organizing around the architecture prevents people from stepping on each other's feet.

Organizing around the architecture also helps with communication. Face-to-face communication is normally the most effective form of communication, but as projects grow bigger, you need to reduce the need for communication since the face-to-face method does not scale well. The upper half of Figure 8.3 shows how many possible communication paths there are among all team members (note that it grows geometrically with the size of the team). For a team of size N, the number of communication paths = N * (N “1) / 2. This means that a two-person team has 1 communication path , a three-person team has 3 communication paths, but a six-person team has 15 communication paths.

Figure 8.3. Organization Around Architecture Minimizes Communication Overload. The possible communication paths between team members grows geometrically with the size of the team. Organizing around the architecture radically reduces the number of communication paths within a team. Issues regarding subsystem interaction are resolved by the architecture team, which owns the interfaces between subsystems.

An increase in communication paths destroys project team efficiency, and you need to find better means of communication (other than everybody communicating with everybody). This can be achieved by having one team responsible for the architecture, and several small teams each responsible for one or several subsystems. Communication between these few teams is channeled through the architecture team to resolve issues around the overall solution and interfaces between subsystems. As you can see from the lower half of Figure 8.3, this leads to simplified communication, enabling effective communication even in large projects. For those same reasons, you should have one integration team.

Configuration Management

Configuration Management System

The Configuration Management (CM) system needs to be set up during Inception and refined in Elaboration when you baseline the architecture. Here, we describe why you need a CM system and how it benefits you during Construction.

As a project progresses, it becomes increasingly complex to track all versions of the many files being created and changed. Especially during iterative development, you are continually creating new versions of files, and you need help with, among others, the following tasks :

• Iterative development means frequent builds, maybe even daily builds. You need to track which version goes into each build. Sometimes it is the latest version, sometimes an earlier version because the work on a new version has not been completed.

• Iterative development means that you will try out different solutions to see if you can improve upon what you have. You need to merge successful solutions into your mainstream development paths.

• As a project grows, it is essential to be able to hide changes made by one team from other teams so they will not be negatively impacted by code that is not yet working properly. Sometimes you want to make your work visible to the rest of the project several times a day, sometimes only every few days.

• For larger projects, you may also want to control who is allowed to make certain types of changes. ^[1]

  ^[1] Note that even though some industry leaders propose that anybody should be able to change any code or design in the system, our experience shows that this practice does not scale effectively as projects grow beyond 10 people.

• When you notice that you have introduced a defect, you want to be able to go back in time to understand when the defect was introduced. You may also need to be able to go back to old builds quickly to get hold of a build that works (for example, if last night's updates to your e-commerce site made your site crash).

The solution is to use a CM system that tracks all this. You need to set up "units of responsibility/visibility" ^[2] attributes in your CM system. A robust architecture helps here since "units of responsibility/visibility" are typically mapped to the subsystem structure. It is the configuration manager's responsibility to set up the CM system.

^[2] Rational ClearCase refers to these as Versioned Object Bases (VOBs).

Once the CM system has been set up, team members can pay less attention to the thousands of code files, documents, and their versions, allowing them to focus more on core development tasks, thus increasing their efficiency.

Integration Planning

With iterative development, it becomes increasingly complex to plan builds and integration testing. Each iteration needs an Integration Build Plan specifying which capabilities should be testable in each build and which components need to be integrated to produce required capabilities, such as use cases, parts of use cases, or other testable functionality. The tests may include functional, load, stress, or other types of tests.

In many cases, a build is produced by incrementally integrating several smaller builds. This is typically done bottom-up in the layered structure of subsystems in the implementation model. For each build, define which subsystems should go into it and which other subsystems must be available as stubs (that is, as mock-up code emulating the required capabilities of the subsystem). Figure 8.4 shows three builds.

Figure 8.4. Incremental Builds Facilitate Builds for Large Systems. Builds of large systems are often done by integrating several smaller builds, starting from the bottom. This figure shows an integration performed in three builds: build 1 and test, add build 2 and test, then add build 3 and test.

Enforce the Architecture

To benefit fully from the work done with the architecture, you need to actively enforce the architecture. Small teams should be able to achieve this by frequently discussing design options. Larger teams need to pay more attention to this problem.

You have defined architectural mechanisms ”that is, reusable solutions to common problems, such as dealing with persistency or inter-process communication. You now need to prevent each developer from arbitrarily reinventing solutions for these problems. This can be done through training on the architecture and architectural mechanisms available, coupled with design reviews that include the architects and developers.

You also need to ensure that interfaces of subsystems are not arbitrarily changed and that any changes are properly communicated to other teams to minimize impact on them. This communication can be done through a Configuration Management system, where you, among others, put interfaces under CM.

Ensure Continual Progress

To ensure continual progress, you need to establish short- term goals and continually prove that you have achieved them. The following guidelines are proven recipes for success:

• Create one team, with one mission. You want to avoid functionally oriented teams, where analysts are organized in one team and throw the requirements over the wall to the developers who design and implement the requirements and in turn throw the code over the wall to the poor testers, who try to figure out what should be tested . Instead, you should have cross-functional teams, where each team member feels responsible for the application and for the team making progress. Having a quick daily meeting in which the team discusses status and decides what to focus on next can also facilitate team building. ^[3]

  ^[3] See Schwaber 2002.

• Set clear, achievable goals for developers. Each developer should have a very clear picture of what to accomplish in a given iteration, if not within a portion of the iteration. The developers should agree that the expected deliverables are achievable.

• Continually demonstrate and test code. Measure progress primarily by looking at what code is compiled and tested. Do not be satisfied with statements such as "we are 90 percent done." Continual demonstration and testing of executable code is the only way to ensure progress.

• Force continuous integration. If possible, do daily builds. For large projects, or projects with poor or nonexistent CM systems, daily builds may not be feasible . Performing frequent builds ensures frequent integration testing, which provides feedback on the recent code that has been written since the last build. Continuous integration typically also reduces gold plating .

For each of our three example projects, you do the following:

• Project Ganymede, a small green-field project: As a major component was identified (already in Elaboration), the team decided who should be the main person responsible for its design, implementation, and testing. Team members frequently get together to discuss architectural issues and to review each other's design and implementations . They set up a CM system in Elaboration, which they used to do daily builds.

• Project Mars, a large green-field project: The development group is organized as three teams, each with the responsibility for one or two of the major subsystems. Within the teams, it is also clear which person is responsible for the design, implementation, and testing of each component. The teams have weekly architecture meetings in which they discuss architectural issues, and the architect is consistently involved in reviewing the work of the various teams, resolving issues as they arise. They had set up a CM system in Inception, which they used to do biweekly builds.

• Project Jupiter, a second generation of a large project: The project staff is divided into three teams, each with the responsibility for one or two of the major subsystems that were added or had major changes made to it. Within the teams, it is also clear which person is responsible for the design, implementation, and testing of each component. The architect is consistently involved in reviewing the work of the various teams, resolving issues as they arise. Since they are building upon a stable architecture, there are few major architectural issues to resolve. A CM system was already in place when they started the project, which they used to do biweekly builds.