Saam
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
700
On Slideshare
700
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
10
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. DR. HIMANSHU HORA SRMS College of Engg. & Tech., Bareilly (UP) INDIA
  • 2. CONTENTS  What is SAAM  How to perform SAAM  What is a scenario  SAAM Activities
  • 3. SOFTWARE ARCHITECTURE ANALYSIS METHOD  SAAM  Develop scenarios  Describe architectures  Classify scenarios  Direct, indirect  Evaluate indirect scenarios changes  Scenario interaction  Overall evaluation
  • 4. STEPS TO PERFORM SAAM  Structured process for evaluating software architectures.  Before an architecture is finalized  How can this be done  Prepare description of candidate architectures  Evaluate impact of various scenarios  Identify issues with one architecture under study
  • 5. SCENARIO  Definition  Brief description  Of a single interaction  Of a stakeholder  With the system  Stakeholder examples  User performing a desired operation  Maintainer making a system change
  • 6. SAAM ACTIVITIES Scenario Development Architecture Description Scenario Classification Scenario Evaluation Interaction Assessment Overall Evaluation
  • 7. SCENARIO DEVELOPMENT  Illustrate kinds of activities needed  During system usage and modification  Tasks relevant to all stakeholders  Process  Prepare agenda, record all discussion  Brainstorm “proto scenarios”  Remove unimportant ones  Keep “revealing” scenarios, merge others
  • 8. ARCHITECTURE DESCRIPTION  Document candidate architectures  Use well understood notation, etc.  Cover all important aspects  Identify architectural styles  What level of presentation  Suitable for audience  Sufficient to address scenarios
  • 9. SCENARIO CLASSIFICATION  Direct  Scenarios that the candidate architecture can handle without change  Indirect  Scenarios that are not directly supported  Require change to system  Change in component function  Addition of components  Addition of connections between components
  • 10. SCENARIO EVALUATION  Identify needed changes for each scenario  Specific list of changes  Cost estimate  Weight difficulty of changes  Not just the number of changes  Create a table of evaluation results  Scenario  Anticipated changes to support requirements
  • 11. INTERACTION ASSESSMENT  When multiple scenarios require changes to a single component  Scenarios are said to interact  May expose poor allocation of responsibility  If unrelated scenarios affect same component  Ok if related scenarios interact
  • 12. OVERALL EVALUATION  To compare architectures  Assign weights to scenarios  Tabulate with cost estimates  Evaluation is subjective  Depends on all stakeholders
  • 13. THANK YOU DR. HIMANSHU HORA SRMS College of Engg. & Tech., Bareilly (UP) INDIA