Saam
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Saam

on

  • 664 views

 

Statistics

Views

Total Views
664
Views on SlideShare
664
Embed Views
0

Actions

Likes
0
Downloads
10
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Saam Presentation 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