Work Assignment Style

In the 1960s, Conway [1968] formulated a law that the architectural structure mirrors the organizational structure. He based his law on ease of communication within as opposed to across groups. This law is an organizational articulation of coupling and coherence. Software work breakdown structures have always been based on some decomposition of the system being built into parts: a software architecture. More recently, Paulish [2001] has observed that accurate time and budget estimates depend on basing them on the software architecture. Paulish's observation has a strong intuitive base, as the time and budget estimates depend on the work breakdown structure, which in turn depends on the software architecture.

Because work assignments represent a mapping of the software architecture onto groups of humans, it is an important allocation style. Teamsand hence work assignmentsare not simply associated with building software that will run in the final system. Even if software is purchased in its entirety as a commercial product without the need for any implementation work, someone has to be responsible for procuring it, testing it, and understanding how it works, and someone has to "speak" for it during integration and system testing. The team responsible for that has a place in the work assignment view. Also, software written to support the building of the systemtools, environments, test harnesses, and so onand the responsible team have a first-class place in the work assignment style.

5.5.1 Elements, Relations, and Properties

Table 5.4 summarizes the discussion of the characteristics of the work assignment style. The elements of this style are software modules and people elements.

• The production, acquisition, testing, and/or integration of software modules are the responsibility of an individual or a team of people. Documentation of the work assignment style must include information about each module to bound its scope and responsibilities: in essence, to give its team its charter.
• The people elements denote organizational units or specific teams of people or personnel roles. People within a people element may belong to multiple teams for multiple purposes. For example, a common practice is for a person to have one reporting relationship for personnel matters, such as reviews, and other reporting relationships for development. Within the work assignment style, we are concerned only with those teams that have developmental responsibilities.

In this style, the allocated-to relation maps from software elements to people elements.

A well-formed work assignment relation has the property of completenessall work is accounted forand no overlapno work is assigned to two places. Properties of the software elements may include a description of the required skill set, whereas properties of the people elements may include provided skill sets.

5.5.2 What the Work Assignment Style Is For and What It's Not For

The work assignment style shows the major units of software that must be present to form a working system and who will produce them, as well as the tools and environments in which the software is developed. This style is well suited for managing team resource allocations and for explaining the structure of a projectto a new hire, for example. This style is the basis for work breakdown structures and for detailed budget and schedule estimates.

The work assignment style does not show runtime relations, such as calls or passes-data-to. Nor does it show dependency relations among the modules.

5.5.3 Notations for the Work Assignment Style

No special notations for architectural work assignments exist.

5.5.4 Relation to Other Styles

The work assignment style is strongly related to and uses the module decomposition style as the basis for its allocation mapping. This style may extend the module decomposition by adding modules that correspond to development tools, test tools, configuration management systems, and so forth, whose procurement and day-to-day operation must also be allocated to an individual or a team.

The work assignment style is often combined with other styles. For example, team work assignments could be the modules in a module decomposition style, the layers in a layered diagram, the software associated with tiers in an n-tier architecture, or the tasks or processes in a multiprocess system. Although this style is a conflation of conceptually different views, it sometimes works well enough. The creation of a work assignment style as a separate stylewhether maintained separately or carefully overlaid onto anotherenables the architect and the project manager to give careful thought to the best way to divide the work into manageable chunks and keeps explicit the need to assign responsibility to software, such as the development environment, that will not be part of the deployed system. A danger of combining work assignments with other styles is that the work assignments associated with tool building may be lost.

Be careful about combining the work assignment style with another one. Remember that decomposing work assignments yields the same kind of element. The same is not true of processes, tiers, layers, and many other architectural elements. If it is based on decomposition, the work assignment structure will not map well to those kinds of elements. On the other hand, mapping to a module decomposition obtained under the principle of information hiding or encapsulation is a natural fit. The compartmentalization of information within modules is greatly aided by a compartmentalization of information among teams.

5.5.5 Example of the Work Assignment Style

Figure 5.6, taken from Appendix A, shows a portion of the work assignment view for the ECS system.

Figure 5.6. Primary presentation for the ECS work assignment view. The software elements are modules defined in the decomposition view. The environmental elements are teams, which are elaborated in the view's supporting documentation (not shown here).