General
In general the architecture must support the needs of the development team for the current iteration:
-
Does the architecture appear to be stabilizing? Although the architecture may be unstable during early Inception
and Elaboration iterations, it should become more stable towards the end of Elaboration, with sufficent stability
during Construction to allow the software to be built efficiently and with confidence. The architecture should be
very stable during Transition.
-
Does the architecture divide the system’s responsibilities into well-defined subsystems with well-defined
interfaces?
-
Are all of the subsystem components (for the iteration) identified?
-
Are the number and types of components reasonable?
-
Does the packaging approach reduce complexity and improve understanding?
-
Are packages defined to be highly cohesive within the package, while the packages themselves are loosely coupled?
-
Can team members understand enough from the architecture to successfully design and code their allocated
components?
-
Is the architecture description current?
-
Have the design guidelines been followed?
-
Are all technical risks either mitigated or addressed as a planned for contingency?
-
Does the architecture address all of the non-behavioural requirements contained in the Supplementary Requirements?
If not, is there a plan for them to be addressed?
|
Architecture Qualities
-
The architectural qualities are specified, with appropriate Architecture Mechanisms in place to meet them. For example;
-
-
Error Recovery
-
-
For each error or exception, a policy defines how the system is restored to a "normal" state.
-
For each possible type of input error from the user or wrong data from external systems, a policy
defines how the system is restored to a "normal" state.
-
There is a consistently applied policy for handling exceptional situations.
-
There is a consistently applied policy for handling data corruption in the database.
-
There is a consistently applied policy for handling database unavailability, including whether data
can still be entered into the system and stored later.
-
If data is exchanged between systems, there is a policy for how systems synchronize their views of
the data.
-
In the system utilizes redundant processors or nodes to provide fault tolerance or high
availability, there is a strategy for ensuring that no two processors or nodes can 'think' that
they are primary, or that no processor or node is primary.
-
The failure modes for a distributed system have been identified and strategies defined for handling
the failures.
-
Performance
-
-
Performance requirements are reasonable and reflect real constraints in the problem domain; their
specification is not arbitrary.
-
Estimates of system performance exist (modeled as necessary using a Workload Analysis Model), and
these indicate that the performance requirements are not significant risks.
-
System performance estimates have been validated using architectural prototypes, especially for
performance-critical requirements.
-
Memory Utilization
-
-
Memory budgets for the application have been defined.
-
Actions have been taken to detect and prevent memory leaks.
-
There is a consistently applied policy defining how the virtual memory system is used, monitored
and tuned.
-
Portability
-
-
Portability requirements have been met.
-
Programming Guidelines provide specific guidance on creating portable code.
-
Design Guidelines provide specific guidance on designing portable applications.
-
A 'test port' has been done to verify portability claims.
-
Reliability
-
-
Measures of quality (MTBF, number of outstanding defects, etc.) have been met.
-
The architecture provides for recovery in the event of disaster or system failure
-
Security
-
-
Security requirements have been met.
|
Architecture Description
The Use-Case View
For the Use-Case View section of the Software Architecture Document:
-
Is each use case architecturally significant, identified as such because it:
-
Is vitally important to the stakeholders;
-
Motivates key elements in the other views;
-
Is a driver for mitigating one or more major risks, including any challenging non-functional requirements?
-
Are there any use cases whose architectural concerns are already covered by another use case?
-
Are the architecturally significant aspects of the use case clear, and not lost in details?
-
Are the use cases sufficiently clear and unlikely to change in a way that affects the architecture, or is there a
plan in place for how to achieve such clarity and stability?
-
Have any architecturally significant use cases been missed (Note: this may require some analysis of the use cases
not selected for this view)?
-
Can all use-case realizations defined for the current iteration be executed by the architecture?
The Logical View
For the Logical View section of the Software Architecture Document:
-
Does it accurately and completely present an overview of the architecturally significant elements of the design?
-
Does it present the complete set of architectural mechanisms used in the design along with the rationale used in
their selection?
-
Does it present the layering of the design, along with the rationale used to partition the layers?
-
Does it present any frameworks or patterns used in the design, along with the rationale used to select the patterns
or frameworks?
The Process View
For the Process View section of the Software Architecture Document:
-
Are potential race conditions (process competition for critical resources) identified and avoidance and resolution
strategies defined?
-
Are the nominal and maximal performance requirements for important operations specified?
-
Is there is a set of performance tests capable of measuring whether performance requirements have been met?
-
Have any architectural weaknesses with the potential for performance bottlenecks been identified?
-
Is there consistent policy for handling errors exceptions in the system?
-
Is the system tolerant of errors and exceptions, such that when an error or exception occurs, the system can revert
to a consistent state?
The Deployment View
For the Deployment View section of the Software Architecture Document:
-
Does the deployment conform to any stakeholder’s deployment requirements?
-
Have the system’s availability requirements been addressed?
-
Have the system’s capacity requirements been addressed?
|
Models
Overall
-
Subsystem and package partitioning and layering is logically consistent.
-
All analysis mechanisms have been identified and described.
Subsystems
-
The services (interfaces) of subsystems in upper-level layers have been defined.
-
The dependencies between subsystems and packages correspond to dependency relationships between the contained
classes.
-
The classes in a subsystem support the services identified for the subsystem.
Classes
-
The key entity classes and their relationships have been identified.
-
Relationships between key entity classes have been defined.
-
The name and description of each class clearly reflects the role it plays.
-
The description of each class accurately captures the responsibilities of the class.
-
The entity classes have been mapped to analysis mechanisms where appropriate.
-
The role names of aggregations and associations accurately describe the relationship between the related classes.
-
The multiplicities of the relationships are correct.
-
The key entity classes and their relationships are consistent with the business model (if it exists), domain model
(if it exists), requirements, and glossary entries.
General Model Considerations
-
The model is at an appropriate level of detail given the model objectives.
-
For the business model, requirements model or the design model during the elaboration phase, there is not an
over-emphasis on implementation issues.
-
For the design model in the construction phase, there is a good balance of functionality across the model elements,
using composition of relatively simple elements to build a more complex design.
-
The model demonstrates familiarity and competence with the full breadth of modeling concepts applicable to the
problem domain; modeling techniques are used appropriately for the problem at hand.
-
Concepts are modeled in the simplest way possible.
-
The model is easily evolved; expected changes can be easily accommodated.
-
At the same time, the model has not been overly structured to handle unlikely change, at the expense of simplicity
and comprehensibility.
-
The key assumptions behind the model are documented and visible to reviewers of the model. If the assumptions are
applicable to a given iteration, then the model should be able to be evolved within those assumptions, but not
necessarily outside of those assumptions. Documenting assumptions is a way of indemnifying designers from not
looking at "all" possible requirements. In an iterative process, it is impossible to analyze all possible
requirements, and to define a model which will handle every future requirement.
|
Transition and Installation
-
The process for upgrading an existing system without loss of data or operational capability is defined and has been
tested.
-
The process for converting data used by previous releases is defined and has been tested.
-
The amount of time and resources required to upgrade or install the product is well-understood and documented.
-
The functionality of the system can be activated one use case at a time.
|
Administration
-
Disk space can be reorganized or recovered while the system is running.
-
The responsibilities and procedures for system configuration have been identified and documented.
-
Access to the operating system or administration functions is restricted.
-
Licensing requirements are satisfied.
-
Diagnostics routines can be run while the system is running.
-
The system monitors operational performance itself (e.g. capacity threshold, critical performance threshold,
resource exhaustion).
-
The actions taken when thresholds are reached are defined.
-
The alarm handling policy is defined.
-
The alarm handling mechanism is defined and has been prototyped and tested.
-
The alarm handling mechanism can be 'tuned' to prevent false or redundant alarms.
-
The policies and procedures for network (LAN, WAN) monitoring and administration are defined.
-
Faults on the network can be isolated.
-
There is an event tracing facility that can enabled to aid in troubleshooting.
-
The overhead of the facility is understood.
-
The administration staff possesses the knowledge to use the facility effectively.
-
It is not possible for a malicious user to:
-
-
enter the system.
-
destroy critical data.
-
consume all resources.
|
Organizational Issues
By the completion of the Elaboration phase the architecture should be sufficiently well defined to allow the team
structure to be decided.
-
Does the component architecture provide a suitable basis for organising the development teams?
-
Does each team have the skills required to implement their allocated components?
-
Are responsibilities well partitioned between teams?
-
Do all team members share the same view of the architecture as the one presented by the architect?
|
Cost and Schedule
-
The actual number of lines of code developed thus far agrees with the estimated lines of code at the current
milestone.
-
The estimation assumptions have been reviewed and remain valid.
-
Cost and schedule estimates have been re-computed using the most recent actual project experience and productivity
performance.
|
|