A Rationale-based Model for Architecture Design Reasoning

5.4. Discussion of findings
of design rationale in various aspects of impact analysis.
5.4.6 Risk assessment in architecture design reasoning
Two major differences exist between architecture design and detailed software design.
Firstly, architecture design has a global impact, in terms of modifiability and correctness,
to the system whilst the software design of a local module has a lower impact. Secondly,
there are more certainty and testability in designing a software module than an architecture.
The survey showed that architects often carry out risk assessments in architecture
design. Over half of the respondents explicitly quantify risks. However, when they were
asked what risk level would be acceptable, there was no consensus. This implies that
there is no common understanding on how to measure risks. Is an 80% uncertainly in the
architecture design acceptable? 13.6% of architects seemed to think so. Since architecture
cannot be fully tested at the early stage of the development cycle, it is probably better
to have a lower risk architecture design which is more likely to succeed. However, the
risk assessment process in architecture design is not well understood and so there is much
room for further investigations in this area.
5.4.7 Methodology support for design rationale
Some of the reasons for not documenting design rationale are budget constraints and lack of
methodology. Given that most respondents consider design rationale important and their
documentation useful, there needs to be guidelines under which the use and documentation
of design rationale will provide greater benefits than the costs involved. This means that
the need for design rationale documentation should be context dependent. For instance,
a non-complex system may require little design rationale documentation since it can be
reconstructed easily [27]. Our literature review shows that there is no comprehensive
methodology to guide how we should use rationale-based techniques to design systems.
Therefore, further studies of the use and documentation of design rationale to provide a
methodology would be most beneficial.
5.4.8 Tool support for design rationale
At present, tool support for design rationale capture and retrieval is inadequate. The
various tools that respondents reported using, including word processors and UML-based
tools, do not have traceability features to support systematic design rationale description
and retrieval. Therefore, it is important to understand how best to capture, represent
77