%0 Book %1 ClemEval2005 %A Clements, Paul %A Kazman, Rick %A Klein, Mark %C Boston u.a. %D 2005 %I Addison-Wesley %K ARID ATAM SAAM analysis architecture evaluation %T Evaluating software architectures %@ 0-201-70482-X

@book{ClemEval2005, added-at = {2012-02-19T16:17:04.000+0100}, address = {Boston [u.a.]}, author = {Clements, Paul and Kazman, Rick and Klein, Mark}, biburl = {https://www.bibsonomy.org/bibtex/28f85af293a05101969dd0a07887f24ce/stammel}, description = {Summary of Evaluating Software Architectures Chapter 1: Introduces Software Architecture in general and explains why it is important: 1) It is a vehicle for communication amongst stakeholders 2) It is the manifestation of the earliest design decisions 3) It is a reusable, transferable abstraction of a system But most importantly, it is a key to achieving system understanding. Also, it introduces the term architectural approaches to represent all the architectural decisions made by the architect. Chapter 2: Explains why an evaluation of a Software Architecture is needed and useful. One quote (from page 20) Architectures allow or preclude nearly all of the system's quality attributes Also, it gives a hint on what is architectural. In a nutshell: To be architectural is to be the most abstract depiction of a system that enables reasoning about critical requirements and constraints all subsequent refinements. The product of an architecture design is the answer to two kinds of questions: 1) is the architecture suitable for the system for which it was designed? 2) which of two or more competing architectures is the most suitable one for the system at hand? In this case, suitable for the system means that the resulting system will meet its quality goals and that it can be build with the resources at hand. Small note, according to page 27 an architecture is always good if a sponsor cannot tell you what the quality goals of the project are. Chapter 3: Introduction to the ATAM method. Lists the 9 steps and explains who does what in each step. Steps in ATAM are: Introduction: 1) Present the ATAM (By evaluation to others) 2) Present Business drivers (by project lead to evaluation team) 3) Present the Architecture (by architect to evaluation team) Investigate and Analysis 4) Identify the Architectural approaches (From presentation + architect) 5) Generate the Quality Attribute Utility Tree (Evaluation team + architect and main stakeholders) 6) Analyze the architectural approaches (Evaluation team) Testing 7) Brainstorm and prioritize scenarios (Evaluation team + many more stakeholders) 8) Analyze the architectural approaches (Evaluation team) Reporting 9) Test the results (Evaluation team to others) So first the introduction of ATAM and the system is given by the people that know the most. After this, the main goals and quality requirements of the system are identified by the architect and main stakeholders. Each quality requirements is mapped to the architectural approach that makes sure that the requirement is met. Lastly, the approaches are evaluated to make sure that they actually meet the desired goals. In order to test whether all quality requirements are present more stakeholders are grouped together to define scenario's that generate quality requirements important for them. These are then ranked by all stakeholders present. Ideally, the list of requirements of the architect should be the same as the ones gathered by the other stakeholders. Again the list of requirements is evaluated against the architectural approaches present. The overall result of the evaluation is then presented to the client. One of the deliverables is the list of risks/non-risk and sensitive points. A sensitive points is a property of one more more components that is critical for achieving a particular quality attribute response. Each sensitive points can be either a risk or a non-risk, depending upon whether the desired response is achieved (page 69). Note the contrast in which the architect and the stakeholders come to the list of quality attributes. The architect goes from general to specific, begin with quality attributes and refine until scenario's. In contrast, the stakeholders go from specific to general, begin with scenario's and then identify quality attributes. Chapter 4: Small case-study Chapter 5: Explanation of how the quality attributes (such as portability and modifiability) are characterized using Stimuli, Architectural Decisions and responses. Using this schema, three quality attributes are discussed. For each attribute a list of modifiability questions are given. After this, a concrete example is given. Lastly, the Attribute based Architectural styles are explained. Chapter 6: Large case study Chapter 7: SAAM Introduction of the SAAM evaluation model. This model consists of 6 steps: 1) Develop scenario's 2) Describe Architectures 3) Classify/prioritize Scenario's 4) Individually Evaluate indirect scenario's 5) Asses Scenario Interaction 6) Create overall evaluation The basis of the model are the scenario's. These are described by the stakeholders and the architect. After a set of scenario's are made the architectures of the system are described and the scenario's are mapped onto these architecture. There are two types of scenario's: direct and indirect. Direct scenario's can directly be mapped onto architectures and do not require any changes. On the other hand, indirect scenario's require changes in the architecture in order to support the scenario. This process is iterated because the description of the architectures can lead to more scenario's. When the scenario's are available they are prioritized by the stakeholders. After this, each indirect scenario is evaluated on a case by case basis. For each scenario a description is given of the scenario itself, the required changes and the estimated effort for the change. In the fifth step the interaction between scenario's is examined. Interaction occurs when multiple scenario's require changes to a single component. When this is the case the architecture needs to be revisited in order to make sure that there is still a correct amount of separation of concerns. In the final step the overall evaluation is given in respect to how well all the scenario's can be mapped onto the architecture under review. Relative weight can be given to each scenario to enable the ranking of architectures. Chapter 8: ARID Active Reviews for Intermediate Designs are aimed at answering the question whether a designer is on the right track given the current status of the architecture. It is based on both ATAM and Active Design Reviews (ADR). The last method is based on the idea that reviewers should be engaged into the review process by asking open questions. The ARID consists of 9 steps which are divided into 2 phases. The first phase is carried out by the lead designer and the review facilitator, the second phase is attended by about a dozen stakeholders. The steps include: 1) Identify the reviewers 2) Prepare the design briefing (practice the presentation which introduces the design) 3) Prepare the seed scenario's (scenario's that show how a scenario looks) 4) Prepare the material (copying etc) Phase 2 starts, all reviewers are present 5) Present ARID 6) Present the design (as practices in 2) 7) Brainstorm and prioritize scenario's 8) Apply the scenario's 9) Summarize During step 6 the main designer explains the design which can be used by the reviewers to solve their scenario's. During this presentation some items might be missing and these items should be written down by the scribe. Furthermore, during the application of the scenario's to the design some things might be missing or teams might get stuck. When this happens the scribe should note this and write down the reason for not getting the scenario in the design. This list of action points is the main output of ARID. Chapter 9: Comparison of all three software evaluation methods Describes Questioning techniques, Measuring techniques and hybrid techniques. Which quality attributes they cover, which approaches are used and when each of them can be applied. In particular, page 271 gives an overview of all of this in table 9.3. Chapter 10: Growing architecture evaluation in your organization. Chapter 11: Conclusions and reasoning about why the ATAM works.}, interhash = {e7635b4959d547321b96ce978d6443f3}, intrahash = {8f85af293a05101969dd0a07887f24ce}, isbn = {0-201-70482-X}, keywords = {ARID ATAM SAAM analysis architecture evaluation}, publisher = {Addison-Wesley}, timestamp = {2012-02-19T16:17:04.000+0100}, title = {Evaluating software architectures}, year = 2005 }