Difference between revisions of "Architecture Evaluation"

From Suhrid.net Wiki
Jump to navigationJump to search
Line 57: Line 57:
 
* A set of risks and non-risks.
 
* A set of risks and non-risks.
 
* A set of risk themes.
 
* A set of risk themes.
 +
 +
= Phases of ATAM =
 +
 +
* Partnership and preparation phase - Eval team and project decision makers.
 +
* Evaluation phase 1 - Eval team and project decision makers.
 +
* Evaluation phase 2 - Eval team and project decision makers and stakeholders.
 +
* Follow up - Eval team and eval client.
 +
 +
= Evaluation phase steps =

Revision as of 08:43, 8 April 2012

Intro

  • Design decisions, patterns are used because of the effects they have on the system.
  • Hence, these choices are analysable.
  • Design must be evaluated continuously during the life cycle, especially early on.
  • There are many benefits to evaluation:
    • Financial.
    • Early detection of problems.
    • Captured rationale - Documented design rationale is important so that implications of modifications can be assessed.
    • Validation of requirements - opens up the requirements themselves for discussion. e.g. conflicting requirements.
    • Improved architectures.
  • Use scenarios as vehicles for asking probing questions about how the arch. responds to various situations.
  • Propose scenarios against a quality attribute.
  • For e.g. against performance - give usage profiles that stretch the system.

SAAM

  • Software Architecture Analysis Method.
  • Steps:
  1. Develop scenarios
  2. Describe candidate architecture
  3. Classify scenarios - direct (arch directly support) or indirect.
  4. Perform scenario evaluations - For each indirect scenario, changes to the architecture that are necessary for it to support the scenario.
  5. Reveal scenario interaction - When 2 or more indirect scenarios require change to a single component - they are said to interact in that component. Areas of high scenario interaction

can indicate poor separation of concerns in a system component.

  1. Overall evaluation : Tabulation, weighting of scenarios, rating architecture support. To compare candidate architectures.

ATAM

  • Architectural Tradeoff Analysis Method.
  • ATAM is a refinement of SAAM.
  • ATAM reveals how well an architecture satisfies particular quality goals.
  • Recognises that an arch. decision tends to affect more than one quality attribute and provides insight into how quality goals trade-off against each other.

Participants in ATAM

  • Evaluation team - Group is external to the project whose arch. is being evaluated. Should be competent, unbiased outsiders.
  • Project decision makers - Speak on behalf of the project or have authority to make changes to it. The architect must always be included.
  • Architecture stakeholders - Developers, Testers, Users, Maintainers. They are needed to articulate the specific quality attribute goals.

Goals of ATAM

  • Elicit and refine a precise statement of the architecture’s driving quality attribute requirements
  • Elicit and refine a precise statement of the architectural design decisions
  • Evaluate the architectural design decisions to determine if they satisfactorily address the quality requirements

Outputs of ATAM

  • A concise presentation of the architecture. Requirement is to be concise - so that it is understandable.
  • Articulation of business goals.
  • Quality requirements in terms of a collection of scenarios.
  • Mapping of architectural decisions to quality requirements.
  • A set of identified sensitivity and trade-off points.
    • Senstivity : Where small changes have big impact on QA's.
    • Tradeoff : Where more than 1 QA is affected.
  • A set of risks and non-risks.
  • A set of risk themes.

Phases of ATAM

  • Partnership and preparation phase - Eval team and project decision makers.
  • Evaluation phase 1 - Eval team and project decision makers.
  • Evaluation phase 2 - Eval team and project decision makers and stakeholders.
  • Follow up - Eval team and eval client.

Evaluation phase steps