From a management perspective, you go through four lifecycle phases to develop a system, or a new generation of a system. From the development perspective, you develop iteratively versions of the system that are incrementally more and more complete. The activities you perform during an iteration have in our Process been grouped into a set of core workflows. Each core workflow focuses on describing some aspect of the system, resulting in a model of the system, or a set of documents.

In our process, the development lifecycle is presented and discussed from two perspectives: the management perspective and the development perspective.

The lifecycles do, of course, have dependencies. To manage those dependencies correctly is one of the challenges of developing a system of interconnected systems. The dependencies are of the following kind:

• The lifecycles are dependent in time. The lifecycle of the superordinate system starts first. Once the superordinate system has gone through at least one iteration and the interfaces of the subordinate systems are relatively stable, the lifecycles of the subordinate systems can start. In fact, you may not even know which the subordinate systems are until you’ve gone through at least one iteration on the superordinate system.
  
  

• The lifecycle of the superordinate system may go into maintenance once the interfaces of the subordinate systems are stable. This means that no active development is done, only if issues occur that requires changes of the interfaces of the subordinate systems.
  
  

• The interfaces of the subordinate systems are owned by those who develop the superordinate system. For more on interfaces, see [3] and [5].
  
  

• The classes that implement the subordinate system’s interfaces are owned by those who develop the subordinate systems.

A natural assumption is that the superordinate system, as well as the subordinate systems, can be developed with the same set of artifacts and developed through the same workflows as are typical for non-composite, systems. Before we can proceed showing how this can be done, these artifacts and workflows have to be introduced. In our process, we introduce five core process workflows, see figure 4. These are:

• Business modeling – the purpose is to assess the organization in which the system will be used, to better understand the needs and problems that is to be solved by the system. The result is a business use-case model and a business object model. This workflow can be considered optional. If the organization in which the system is to be employed is very simplistic it may not add value.
  
  

• Requirements - with the purpose to capture and evaluate the requirements, placing usability in focus. This results in a use-case model, with actors representing external units communicating with the system, and use cases representing transaction sequences, yielding measurable results of value to the actors.
  
  

• Analysis & Design – with the purpose to investigate the intended implementation environment and the effect it will have on the construction of the system. This results in an object model (the design model), including use-case realizations that show how the objects communicate to perform the flow of the use cases. This might include interface definitions for classes and subsystems, specifying their responsibilities in terms of provided operations. This object model is also adapted to the implementation environment in terms of implementation language, distribution etc. It is sometimes useful to consider the results of analysis a separate model, then called the analysis model.
  Implementation – with the purpose to implement the system in the prescribed implementation environment. This results in source code, executables, and files.
  
  

• Test – with the purpose to ensure that the system is the one intended, and that there are no errors in the implementation. This results in a certified system that is ready for delivery.

To mitigate the risks mention above, it is critical to have a group of people assigned to overlook the whole development effort. This group is often called an architect team and should focus on the following key concerns:

• That there is an overall architecture defined and that it is followed in the subordinate systems.
  
  

• That there is a reasonable focus on reuse and sharing of experience between the subordinate systems.
  
  

• That there is a clear understanding of what artifacts to produce and what the relations are between artifacts of the subordinate and superordinate systems.
  
  

• That an effective change management strategy is defined and followed by all teams.

The architecture team can, but doesn’t always, own the development of the superordinate system.