Page 208 -

DOMAIN-SPECIFIC & IMPLEMENTATION-INDEPENDENT SOFTWARE ARCHITECTURES 193
data as well as properties on that functionality and data. These may be challenging to acquire from
stakeholders within allocated project time and budget or difficult to estimate.

Is the organization concerned with how an analysis, design, development, or
deployment decision was made?

Software engineering, and modeling in particular, is an evolutionary process. RARE captures a
history of DRA revisions as derivation proceeds and the combination of selected goals, heuristics,
metrics, and strategies collectively represent rationale for derivation decisions. As mentioned in
the related work section, most software architecture research has emphasized architecture repre-
sentation and evaluation techniques over a methodical derivation process.
One option for tracking the evolution of design models and other software development artifacts
is through document-level versioning (e.g., a version control system); however, this approach alone
does not record the decisions that resulted from each evolutionary step. In the absence of such ver-
sioning, analysts and architects may tend to incorporate new content and make structural revisions
in a single “master” version, thereby losing all traceability for later consumers of the artifact.

RARE benefits/limitations to consider. By design, RARE logs chosen goals, heuristics, metrics,
and strategies; derivation activity (i.e., strategies applied); and evaluation results. However, given
that each revision can be quite granular, the RARE derivation log can be voluminous. Understand-
ing the architect’s overall intentions requires mining this log for general trends in the context of
chosen goals.

Is it possible to map stakeholder objectives to RARE-style goals and metrics? Can
heuristics be identified that help achieve those goals?

The RARE approach depends on being able to map stakeholder objectives to quality goals and
to associate those goals with lower-level metrics through heuristics. The default goals, heuristics,
metrics, and strategies provided in RARE represent a compilation from project experiences, com-
monly accepted software engineering principles, and software architecture concepts. However,
this compilation is by no means exhaustive; furthermore, goals, heuristics, and metrics may be
defined uniquely for a given project or influenced by organizational standards. Regardless, since
all software systems are developed to address stakeholder needs, “evaluation” is conducted in
some form on every project, even if the first feedback is from client acceptance testing after sys-
tem delivery and the resulting “architecture refinement” comes in the form of post-deployment
system rework. Thus, there is always a mapping between stakeholder objectives and the system
under development, whether implicit or explicit.

RARE benefits/limitations to consider. If selected goals, heuristics, and metrics accurately reflect
stakeholder objectives, RARE provides quantitative insight as to how well an architecture meets
quality objectives. However, issues in the context of identifying RARE-style goals, heuristics,
metrics, and strategies include the following: (1) Is it possible to identify goals and metrics that
map to stakeholder objectives that can be evaluated in a high-level DRA? (2) Is ample project
time allotted up front for this activity? (3) Will evaluation results be used to influence subsequent
design decisions? (4) How do the structural evaluations available in RARE relate to the various
analyses available in other tools (e.g., UML class model analysis) as well as comments garnered
from architecture reviews?