Build an Architectural Prototype (Initial Iteration in Elaboration)
Context
Inception Phase has been completed and the project has been funded. An initial Artifact: Project Plan exists, along with preliminary Artifact: Iteration Plans for at least the Elaboration Phase. The requirements of the system, captured by the Artifact: Use-Case Model and Artifact: Supplementary Specifications, have been briefly outlined (see Initial Iteration in Inception).
Sample Iteration Workflow
Start up: Outline the iteration plan, risks, and architectural objectives. |
The Worker: Project Manager starts by sketching a an Artifact: Iteration Plan for the current iteration, based on the Artifact: Project Plan outlined during the Initial Iteration in Inception. Evaluation criteria for the architecture are outlined by the Worker: Architect in the Artifact: Software Architecture Document, taking into consideration the "architectural risks" that are to be mitigated (see Artifact: Risk List). Remember that one of the goals of Elaboration is establishing a robust, executable architecture; the plan for doing this needs to be developed in the initial Elaboration iteration. |
Requirements: Decide what will "drive" the development of the architecture. |
The Worker: Architect and the Worker: Project Manager then determine which use cases and/or scenarios should be addressed in the current iteration; these use cases and/or scenarios drive the development of the architecture (see Workflow Detail: Manage Scope of the System in the Requirements Workflow). The Artifact: Iteration Plan created in previous step should be updated accordingly. |
Understand the "drivers" in detail, if necessary; inspect results. |
A number of Worker: Use-Case Specifiers then describe in detail the architecturally significant subsets of the selected use cases/scenarios (see Workflow Detail: Refine the System Definition in the Requirements workflow). As the model evolves, the Worker: System Analyst may restructure the Artifact: Use-Case Model to improve the comprehensibility of the model. The changes to the Artifact: Use-Case Model are then reviewed and approved (see Workflow Detail: Manage Changing Requirements in the Requirements Workflow) |
The "drivers" of the architecture are reconsidered according to new information; risks need also be reconsidered. |
The use-case view is revisited again by the Worker: Architect, taking into consideration new use-case descriptions, and possibly a new structure of the Artifact: Use-Case Model (revisit Workflow Detail: Manage Scope of the System in the Requirements Workflow). The task now is to select what set of use cases and/or scenarios should be analyzed, designed and implemented in the current iteration. Note again that the development of these use cases and/or scenarios set the software architecture. The Worker: Project Manager again updates the current iteration plan accordingly (see Artifact: Iteration Plan), and might also reconsider risk management, because new risks might have been made visible according to new information (see Artifact: Risk List). |
Use-Case Analysis: Find obvious classes, do an initial (high-level) subsystem partitioning, and start looking at the "drivers" in detail. |
To get a general feeling of the obvious classes needed, the Worker: Architect then considers the system
requirements, the glossary, the use-case view (but not use case descriptions), and the
team's general domain knowledge to sketch the outline of the subsystems, possibly in a
layered fashion (see Workflow Detail: Define
the Architecture in the Analysis &
Design Workflow). The analysis mechanisms (common solutions to frequent analysis
problems) are also identified by the architect. In parallel with this effort, a team of Worker: Designers, possibly together with the
architect, will start finding Artifact: Analysis Classes
for this iteration's use cases and/or scenarios, as well as beginning to allocate
responsibilities to the identified classes and analysis mechanisms. The designers will use
the obvious classes found by the architect as input. Then, a number of designers refine the classes identified in the previous step by allocating responsibilities to the classes, and updating their relationships and attributes. It is determined in detail how the available analysis mechanisms are used by each class. When this is done, the Worker: Architect identifies a number of classes that should be considered as architecturally significant, and includes these classes in the logical view section of the Artifact: Software Architecture Document. The resulting analysis artifacts are then reviewed. |
Design: Adjust to the implementation environment, decide how the "drivers" are to be designed, and refine the definition of classes, packages and subsystems; inspect results. |
The Worker: Architect then refines the
architecture by deriving the design mechanisms (e.g. programming language, database,
distribution mechanism, communication mechanism) needed by the earlier identified analysis
mechanisms (see Workflow Detail: Define the
Architecture in the Analysis & Design
Workflow). Artifact: Design Subsystems are
defined and design classes are allocated to them;
the interfaces to subsystems are identified.
Remaining design classes are partitioned into packages,
and responsibilities for subsystems and packages are allocated to Worker: Designers. Instances of classes and subsystems are used by designers to describe the realizations of the selected use cases and/or scenarios (see Workflow Detail: Elaborate the Design in the Analysis & Design workflow). This puts requirements on the employed model elements and their associated design mechanisms; in the process the interaction diagrams previously created are refined. The requirements put on each design mechanism are handled by the architect (revisit Workflow Detail: Define the Architecture in the Analysis & Design workflow). The logical view is updated accordingly by the architect. The resulting design artifacts are then reviewed. |
Consider the concurrency and distribution aspect of the architecture. |
The next step for the architect is to consider the concurrency and distribution required by the system. This is done by studying the tasks and processes required and the physical network of processors and other devices (revisit Workflow Detail: Architecture in the Analysis & Design workflow). An important input to the architect here are the designed use cases in terms of collaborating objects in interaction diagrams; these objects are allocated to tasks and processes, which in turn are allocated to processors and other devices. This results in both a logical and physical distribution of functionality. |
Inspect the architecture |
The architecture is reviewed. |
Implementation: Consider the physical packaging of the architecture. |
An Worker: Architect now considers the impact of the architectural design onto the implementation model, and defines the implementation view (revisit Workflow Detail: Architecture in the Analysis & Design workflow). |
Implementation: Plan the integration. |
A system integrator now studies the use cases that are to be implemented in this iteration, and defines the order in which subsystems should be implemented, and later integrated into an architectural prototype (see Workflow Detail: Plan the Integration within an Iteration in the Implementation workflow). The results of this planning should be reflected in the Artifact: Project Plan. |
Test: Plan integration tests and system tests. |
A test designer now plans the system tests and the integration tests. Selects measurable testing goals to be used when assessing the architecture. These goals could be expressed in terms of being able to execute a use-case scenario, with a certain response time, or response time under specified load. The test designer also identifies and implements test cases and test procedures. (See Workflow Detail: Plan and Design Integration Test and Workflow Detail: Plan and Design System Test in the Test workflow.) |
Implementation: Implement the classes and integrate. |
A number of implementers now implements and unit test the classes identified in the architectural design (Step 5, 6, and 7). The implementations of the classes are physically packaged into components and subsystems in the implementation model. The implementers also fix defects (see Workflow Detail: Implement Classes Within an Iteration in the Implementation workflow). The integration testers test the implementation subsystem (see Workflow Detail: Execute Integration Test in the Test workflow), and then the implementers release the subsystems to integration. |
Integrate the implemented parts. |
The system integrators incrementally integrate the subsystems into an executable architectural prototype (see Workflow Detail: Integrate the System within an Iteration in the Implementation workflow). Each build is tested (see Workflow Detail: Execute Integration Test in the Test workflow). |
Test: Assess the executable architecture. |
Once the whole system (as defined by the goal of this iteration) has been integrated, the system tester tests the system (see Workflow Detail: Execute System Test in the Test workflow). The test designer then analyzes the results of the test to make sure the testing goals have been reached (see Workflow Detail: Evaluate System Test in the Test workflow). The Worker: Architect will then assess this result and compare it with the risk initially identified. |
Assess the iteration itself. |
Lastly, the Worker: Project Manager compares the iteration's actual cost, schedule, and content with the iteration plan; determine if rework needs to be done, and if so, assign to future iterations; update the risk list (see Artifact: Risk List); update the project plan (see Artifact: Project Plan); and prepare an outline of an iteration plan for the next iteration (see Artifact: Iteration Plan). Productivity figures, size of code, and size of database might be interesting to consider here. |
Result
The result of this initial iteration would be a first cut at the architecture, consisting of fairly described architectural views (use-case view, logical view, process view, deployment view, implementation view) and an executable architecture prototype.
Subsequent Iterations In Elaboration
Subsequent iterations can be initiated to further enhance the understanding of the architecture. This might imply a further enhancement of the design or implementation model (that is, the realization of more use cases, in priority order, of course). Whether this needs to take place depends on considerations such as the complexity of the system and its architecture, associated risks, and domain experience.
