Evaluating software architectures - Paul Clements , Rick Kazman ,... - Librairie Eyrolles

Déjà client ? Identifiez-vous

Mot de passe oublié ?

Nouveau client ?

CRÉER VOTRE COMPTE
Evaluating software architectures
Ajouter à une liste

Librairie Eyrolles - Paris 5e
Indisponible

Evaluating software architectures

Evaluating software architectures

Methods and case studies

Paul Clements, Rick Kazman, Mark Klein

324 pages, parution le 13/11/2001

Résumé

Drawing on clearly identified connections between architecture design decisions and resulting software properties, this book describes systematic methods for evaluating software architectures and applies them to real-life cases. It shows you how such evaluation can substantially reduce risk while adding remarkably little expense and time to the development effort (in most cases, no more than a few days). Evaluating Software Architectures introduces the conceptual background for architecture evaluation and provides a step-by-step guide to the process based on numerous evaluations performed in government and industry.

In particular, the book presents three important evaluation methods:

  • Architecture Tradeoff Analysis Method (ATAM)
  • Software Architecture Analysis Method (SAAM)
  • Active Reviews for Intermediate Designs (ARID)
Detailed case studies demonstrate the value and practical application of these methods to real-world systems, and sidebars throughout the book provide interesting background and hands-on tips from the trenches.

All software engineers should know how to carry out software architecture evaluations. Evaluating Software Architectures is the chance to get up to speed quickly by learning from the experience of others.

Table of Contents

Legal
Preface
Reader's Guide
Acknowledgments
1: What is Software Architecture
Architecture as Vehicle for Communication among Stakeholders
Architecture as the Manifestation of the Earliest Design Decisions
Architecture as a Reusable, Transferable Abstraction of a System
Summary
For Further Reading
Discussion questions
2: Evaluating a Software Architecture
Why Evaluate an Architecture?
When can an Architecture be Evaluated?
Who's Involved?
What Result does an Architecture Evaluation Produce?
For what Qualities can we Evaluate an Architecture?
Why are Quality Attributes too Vague for Analysis?
What are the Outputs of an Architecture Evaluation?
What are the Benefits and Costs of Performing an Architecture Evaluation?
For Further Reading
Discussion Questions
Sidebar: What's Architectural?
Sidebar: "Why Should I Believe You?"
3: The ATAM: A Method for Architecture Evaluation
Summary of ATAM Steps
Detailed Description of the ATAM Steps
The Phases of the ATAM
For Further Reading
Discussion Questions
Sidebar: The Two Faces of the ATAM
Sidebar: Scenarios
Sidebar: Stakeholders
Sidebar: Sensitivities and Risks
4: The BCS--The First Case Study in Applying the ATAM
Preparation
Phase 1
Phase 2
Results of The BCS Evaluation
Summary
Discussion Questions
Sidebar: "Issues"
Sidebar: Leading an Evaluation
Sidebar: Making the Most of Evaluators' Efforts
Sidebar: My Experiences with the ATAM
5: Understanding Quality Attributes
Quality Attribute Characterizations
Using Quality Attribute Characterizations in the ATAM
Attribute-Based Architectural Styles (ABASs)
Putting It All Together
For Further Reading
Discussion Questions
6: A Case Study in Applying the ATAM
Background
Phase 0: Partnership and Preparation
Phase 0 - Step 1: Present the ATAM
Phase 0 - Step 2: Describe Candidate System
Phase 0 - Step 3: Make a Go/No-Go Decision
Phase 0 - Step 4: Negotiate the Statement of Work
Phase 0 - Step 5: Form the Core Evaluation Team
Phase 0 - Step 6: Hold evaluation team kick-off meeting
Phase 0 - Step 7: Prepare for Phase 1
Phase 0 - Step 8: Review the architecture
Phase 1: Initial Evaluation
Phase 1 - Step 1: Present the ATAM
Phase 1 - Step 2: Present Business Drivers
Phase 1 - Step 3: Present Architecture
Phase 1 - Step 4: Identify Architectural Approaches
Phase 1 - Step 5: Generate Quality Attribute Utility Tree
Phase 1 - Step 6: Analyze Architectural Approaches
Hiatus between Phase 1 and Phase 2
Phase 2: Complete Evaluation
Step 0: Prepare for Phase 2
Phase 2 - Steps 1-6
Phase 2 - Step 7: Brainstorm and Prioritize Scenarios
Phase 2 - Step 8: Analyze Architectural Approaches
Phase 2 - Step 9: Present Results
Phase 3: Follow Up
Phase 3 - Step 1: Produce the Final Report
Phase 3 - Step 2: Hold the Post-Mortem Meeting
Phase 3 - Step 3: Build Portfolio and Update Artifact Repositories
For Further Reading
Discussion Questions
7: Introducing the SAAM and Using It to Evaluate an Example Architecture
Steps of a SAAM Evaluation
A SAAM Case Study
Summary
For Further Reading
Discussion Questions
Sidebar: "Their own Worst Critics"
8: Active Reviews for Intermediate Designs (ARID)
An Evaluation Method for Partial Architectures
A Case Study in Applying ARID
Summary
For Further Reading
Discussion Questions
Sidebar: "Active Design Reviews".
9: Comparing Software Architecture Evaluation Methods
Questioning Techniques
Measuring Techniques
Automated Tools and Architecture Description Languages
Hybrid Techniques
ATAM
Summary
For Further Reading
Discussion Questions
Sidebar: Danger Signals to Look For
Sidebar: Quality Attribute Workshops
10: Growing an Architecture Evaluation Capability in Your Organization
Building Organizational Buy-in
Growing a Pool of Evaluators
Establishing a Corporate Memory
Summary
Discussion Questions
Sidebar: "Don't Scare Me Off"
11: Conclusions
You are now Ready!
What Methods have you Seen?
Why Evaluate Architectures?
Why does the ATAM Work?
A Parting Message
Good Luck!
Sidebar: "...but it was OK."
Further Reading
References
Index

L'auteur - Paul Clements

Paul Clements is a senior member of the technical staff at the SEI, where he works on software architecture and product line engineering. He is the author of five books and more than three dozen papers on these and other topics.

L'auteur - Rick Kazman

Rick Kazman is a senior member of the technical staff at the SEI. He is also an Associate Professor at the University of Hawaii. He is the author of two books, editor of two more, and has written more than seventy papers on software engineering and related topics.

Caractéristiques techniques

  PAPIER
Éditeur(s) Addison Wesley
Auteur(s) Paul Clements, Rick Kazman, Mark Klein
Parution 13/11/2001
Nb. de pages 324
Format 16,3 x 24
Couverture Relié
Poids 651g
Intérieur Noir et Blanc
EAN13 9780201704822

Avantages Eyrolles.com

Livraison à partir de 0,01 en France métropolitaine
Paiement en ligne SÉCURISÉ
Livraison dans le monde
Retour sous 15 jours
+ d'un million et demi de livres disponibles
satisfait ou remboursé
Satisfait ou remboursé
Paiement sécurisé
modes de paiement
Paiement à l'expédition
partout dans le monde
Livraison partout dans le monde
Service clients sav@commande.eyrolles.com
librairie française
Librairie française depuis 1925
Recevez nos newsletters
Vous serez régulièrement informé(e) de toutes nos actualités.
Inscription