Checklist: Architecture Notebook |  |
Relationships
Related Elements | Architecture Notebook
Check Items
Is the architecture understandable?
Is the description of the architecture complete, meaningful, and clear? Is the architecture at an appropriate level of detail, given the objectives? Are concepts handled in the simplest way possible? Does the architecture clearly convey not only the solution but also the motivation and objectives related to the decisions that have been made in shaping the architecture? Are the key assumptions and decisions that the architecture is based on documented and visible to reviewers and those who will use the architecture? Is the architecture description current? Have the design guidelines been followed?
Have the architectural goals, constraints and requirements been adequately described and handled?
Have the Architectural Goals been clearly described? Have any Architectural Constraints been identified and documented? Have the Architecturally Significant Requirements been identified and are they clearly described. Is the architecture is consistent with the architectural goals, constraints and requirements?
Have necessary architectural mechanisms been identified and described?
Is it clear when each Architectural Mechanism should be applied? Is there a clearly defined design pattern in place to support each mechanism? Does each mechanism adequately address the requirements it is intended to meet?
Have the system partitions been adequately defined?
Is partitioning approach clearly described and applied consistently? Does the partitioning approach reduce complexity and improve understanding? Have the partitions been defined to be highly cohesive within the partition, while the partitions themselves are loosely coupled?
Have the key elements been adequately defined?
Have the Key Abstractions adequately defined? Have the the key design elements (i.e., Components) adequately defined? Do the components have well-defined interfaces? Have the system's responsibilities been allocated to the components? Are the number and types of components reasonable?
Have interfaces to external systems been adequately represented?
See Guideline: Representing Interfaces to External Systems
Has all reuse been identified?
Have all reusable assets been identified -- either those reused by the system, or those elements within the system that have been built to be reused. For more information, see Guideline: Software Reuse.
Has the architecture been built to evolve?
Can the architecture easily evolve, so that expected changes can be easily accommodated? Are all technical risks either mitigated or addressed in a contingency plan? Has the architecture been overly structured to handle unlikely change at the expense of simplicity and comprehensibility? (Hint: "Yes" to this question is not good.)
Can the architecture be delivered by the team?
Does the architecture provide a suitable basis for organizing the development teams? Does each team have the skills required to implement their allocated components? Are responsibilities divided well between teams? Do all team members share the same understanding of the architecture as the one presented by the architect? Can team members understand enough from the architecture to successfully design and code their allocated components?
Has the software been adequately mapped to the hardware?
Have the deployable software components been mapped to physical nodes?
More Information
Concepts | Architectural Constraints Architectural Goals Architecturally Significant Requirements Architectural Mechanism Component Key Abstractions
Guidelines | Representing Interfaces to External Systems Software Reuse
This program and the accompanying materials are made available under the Eclipse Public License V1.0, which accompanies this distribution. EPF Copyright.