The Software
Architecture Document provides a comprehensive architectural overview of the
system, using a number of different architectural views to depict different
aspects of the system.
The Word template can be bought through a template package. Case studies and reports are freely available in the table below.
Word Template
Case Study
Report
---
Purpose
The software architecture document provides a comprehensive overview of the
architecture of the software system. It serves as a communication medium between
the software architect and other project team members regarding architecturally
significant decisions which have been made on the project.
Timing
The representation and objectives of the software architecture is usually
something that must be defined before the very first iterations, and then be
maintained throughout the project. These architectural representation guidelines
are documented in initial versions of the Software Architecture Document.
The Software Architecture Document is primarily developed
during the elaboration phase, because one of the purposes of this phase is to
establish a sound architectural foundation.
The use-case view within the document is likely to be considered before the
other views, because the use cases drive the development and are an essential
input to iteration planning. For systems with a large degree of concurrency and
distribution, the process and deployment views are also likely to be considered
early, because they then might have substantial impact on the entire system.
Responsibility
A Designer is responsible for producing the Software
ArchitectureDocument, which captures the most
important design decisions in multiple architectural views.
The Designer establishes the overall structure for
each architectural view: the decomposition of the view, the grouping of
elements, and the interfaces between these major groupings. Therefore, in
contrast with the other roles, the designer's
view is one of breadth, as opposed to depth.
The designer is also responsible for maintaining
the architectural integrity of the system through the development process by:
Approving all changes to architecturally significant elements, such as
major interfaces, described in the Software Architecture Document.
Being part of the "change-control board" decisions to resolve
problems that impact the software architecture.
Tailoring
You should adjust the outline of the Software Architecture Document
to suit the nature of your software:
Some specific aspects of the software may require their own section; for
example, aspects related to data management or usability issues.
You may need additional appendices to explain certain aspects, such as the
rationale of certain critical choices together with the solutions that have
been eliminated, or to define acronyms or abbreviations, or present general
design principles.
The order of the various sections may vary, depending on the system's
stakeholders and their focus or interest.
The advantages and disadvantages of each architectural view follow:
Use-Case View
This view is mandatory.
Logical View
This view is mandatory.
Process View
This view is optional. Use this view only if the system
has more than one thread of control, and the separate threads interact or are
dependent upon one another.
Implementation View
This view is optional. Use this view only in cases where
the implementation is not strictly driven from the design, i.e. where there is
a different distribution of responsibilities between corresponding packages in
the Design and Implementation models. If the packaging of the design and
implementation models are identical, this view can be omitted.
Data View
This view is optional. Use this view only if persistence
is a significant aspect of the system. and the translation from the Design
Model to the Data Model is not done automatically by the persistence
mechanism.
Artifacts >
Analysis & Design Artifact Set >
{More A&D Artifacts} >
Software Architecture Document
