Review changes
The System Architect is prompted to perform this activity by:
The System Architect examines these changes to determine what effect, if any, they have on the logical viewpoint, that
is, the way the system is decomposed into collaborating subsystems.
|
Refactor/augment subsystems
The System Architect determines the subsystem structure initially in Task: System Architectural Analysis, then the detail of how
subsystems collaborate is added by the System Designer in Task: System Operation Analysis and then Task: System Operation Design perhaps doing some refactoring in the process. In the light of this work and any other
changes or feedback, the System Architect examines the System Use-Case Realizations (subsystem interactions) to check
the validity of the subsystem model, and then adjusts it if necessary.
|
Capture updated Logical viewpoint in System Architecture Document
Decisions made in this activity are captured in the System Analysis Model (if this is separately maintained) and System Design Model; those aspects which the System Architect considers to be significant are also recorded in the Work Product: System Architecture Document (in this case as part of the Logical viewpoint). |
Update subsystem requirements artifacts
Evaluate the results
The effectiveness of proposed solutions at all levels need to be reviewed with the stakeholders and the development team to ensure that all requirements (cost, capability, constraints) are satisfied, and that the rationale (domain conventions, architectural considerations of cohesion and coupling, and so on) for arriving at the particular decomposition is sound. The chosen decomposition must also satisfy any political or economic mandate for subcontracted development of subsystems. Techniques such as simulation and prototyping can be used to provide more objective demonstrations of the adequacy of the design(s). |
|