Activity:
|
Purpose
|
Role: Software Architect |
Frequency: As required, typically once in each iteration starting with Elaboration. |
Steps |
Input Artifacts: | Resulting Artifacts: |
Tool Mentors: |
Workflow Details: |
A software architect proposes the technical contents and the order of successive iterations by selecting a certain number of scenarios and use cases to be analyzed and designed. This technical proposal is completed and refined by the various development teams, based on personnel availability, customer requirements in terms of deliverables, availability of tools and COTS products, and the needs of other projects.
The selection of scenarios and use cases that constitute the use-case view is driven by some key driving factors, summarized below. These factors are defined in more detail in the Guidelines: Requirements Management Plan.
There may be two scenarios that hit the same components and address similar risks. If you implement A first, then B is not architecturally significant. If you implement B first, then A is not architecturally significant. So these attributes can depend on the iteration order, and should be re-evaluated when the ordering changes, as well as when the requirements themselves change.
These driving factors should be captured as attributes of the requirements, so that they can be managed effectively. See Guidelines: Requirements Management Plan.
Architecturally significant use cases that are poorly understood or likely
to change should be prioritized for clarification and stabilization. In some
cases, this means further requirements analysis should be done before implementing
the requirement. In other cases, some form of prototyping may be best.
The use-case view is documented in the use-case view section of the Software Architecture Document. This section contains a listing of the significant use cases and scenarios within each package in the use-case model, together with significant properties such as descriptions of the flow of events, relationships, use-case diagrams, and special requirements related to each use case. Note that if the use-case view is developed early in the iteration, some of these properties may not yet exist.
The use-case view should be checked at this stage to verify that the work is on track, but not to review the use-case view in detail. See especially checkpoints for use-case view in Activity: Review the Architecture.
Rational Unified Process |