Evaluating a Software Architecture By Desalegn Bekele.

Slides:



Advertisements
Similar presentations
ATAM Architecture Tradeoff Analysis Method
Advertisements

Project Management Shuffle Directions: take the definitions from the following cards and write a song using the tune from “Cupid Shuffle”
Lecture # 2 : Process Models
CHAPTER 1 SOFTWARE DEVELOPMENT. 2 Goals of software development Aspects of software quality Development life cycle models Basic concepts of algorithm.
Modeling the Process and Life Cycle CSCI 411 Advanced Database and Project Management Monday, February 2, 2015.
Software Process Models
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Degree and Graduation Seminar Scope Management
Architecture is More Than Just Meeting Requirements Ron Olaski SE510 Fall 2003.
The Architecture Design Process
Active Review for Intermediate Designs [Clements, 2000]
Requirements - Why What and How? Sriram Mohan. Outline Why ? What ? How ?
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
Administrivia Lifecycle Architecture (LCA) group assignment will go out later today. Informal feedback meetings with LCO groups EasyShare: Mon, 2:45pm-3:15pm,
Quality is about testing early and testing often Joe Apuzzo, Ngozi Nwana, Sweety Varghese Student/Faculty Research Day CSIS Pace University May 6th, 2005.
Software Architecture Quality. Outline Importance of assessing software architecture Better predict the quality of the system to be built How to improve.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Chapter 2- Software Process Lecture 4. Software Engineering We have specified the problem domain – industrial strength software – Besides delivering the.
Software architecture evaluation
CHAPTER 19 Building Software.
Software Life Cycle Model
Architecture Tradeoff Analysis Method Based on presentations by Kim and Kazman
Enterprise Architecture
Chapter 9 – Software Evolution and Maintenance
Software Project Management Lecture # 8. Outline Chapter 25 – Risk Management  What is Risk Management  Risk Management Strategies  Software Risks.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Evaluating Architectures: ATAM
CPSC 871 John D. McGregor Module 4 Session 3 Architecture Evaluation.
CLEANROOM SOFTWARE ENGINEERING.
Software evolution. Objectives l To explain why change is inevitable if software systems are to remain useful l To discuss software maintenance and maintenance.
Architecture Evaluation Evaluation Factors Evaluation by the designer Every time the designer makes a key design decision or completes a design milestone,
Analyze Opportunity Part 1
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
 CS 5380 Software Engineering Chapter 2 – Software Processes Chapter 2 Software Processes1.
Software Engineering Management Lecture 1 The Software Process.
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Evaluating Architectural Options Simon Field Chief Technology Officer.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
1 Software Development Software Engineering is the study of the techniques and theory that support the development of high-quality software The focus is.
Requirement Handling
1-1 Software Development Objectives: Discuss the goals of software development Identify various aspects of software quality Examine two development life.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
Chapter 1: Fundamental of Testing Systems Testing & Evaluation (MNN1063)
CSE 303 – Software Design and Architecture
Smart Home Technologies
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
John D. McGregor Architecture Evaluation
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Lecture 17 Enterprise Systems Development ( CSC447 ) COMSATS Islamabad Muhammad Usman, Assistant Professor.
The ATAM method. The ATAM method (1/2) Architecture Tradeoff Analysis Method Requirements for complex software systems Modifiability Performance Security.
1 Chapter 2 SW Process Models. 2 Objectives  Understand various process models  Understand the pros and cons of each model  Evaluate the applicability.
Analyzing an Architecture. Why analyze an architecture? Decide whether it solves the problem Compare to other architectures Assess what needs to change,
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
CpSc 875 John D. McGregor C 12 – Security/ATAM. Attack surface of a product face_Analysis_Cheat_Sheet
 System Requirement Specification and System Planning.
Slide 3.1 © The McGraw-Hill Companies, 2002 SOFTWARE LIFE-CYCLE MODELS.
An Iterative Method For System Integration
Software Engineering Management
Lecture 3 Prescriptive Process Models
The Development Process of Web Applications
The Systems Engineering Context
Chapter 2 SW Process Models
Applied Software Implementation & Testing
Software Process Models
Chapter 8 Software Evolution.
Software Architecture
Presentation transcript:

Evaluating a Software Architecture By Desalegn Bekele

Evaluating a Software Architecture How can you be sure whether the architecture chosen for your software is the right one? How can you be sure that it won't lead to calamity? “Marry your architecture in haste and you can repent in leisure.” —Barry Boehm

Outline What is an Architecture? How to validate a software architecture? Why Evaluate an Architecture? When Can an Architecture Be Evaluated? Who's Involved? What Are the Outputs of an Architecture Evaluation? What Are the Benefits and Costs? Conclusion

What is an Architecture? Is the foundation for any software system. will allow or preclude just about all of a system's quality attributes: Modifiability, performance, security, availability, reliability.

How to validate a software architecture? A suite of three methods, all developed at the Software Engineering Institute. ATAM: Architecture Tradeoff Analysis Method SAAM: Software Architecture Analysis Method ARID: Active Reviews for Intermediate Designs

Architecture Tradeoff Analysis Method (ATAM) a structured technique for understanding the tradeoffs inherent in the architectures of software-intensive systems. provides a principled way to evaluate a software architecture's fitness with respect to multiple competing quality attributes. is a spiral model of design: one of postulating candidate architectures followed by analysis and risk mitigation, leading to refined architectures.

Software Architecture Analysis Method (SAAM) aims to predict the quality of a system before it has been developed. the quality of the architecture is validated by analyzing the impact of predefined scenarios on architectural components. addresses concerns at the architecture design level which inherently crosscut multiple architectural components.

Active Reviews for Intermediate Designs (ARID) method for reviewing preliminary software designs (such as for a component or a subsystem) for suitability in its intended usage context and environment. result in a high-fidelity design review coupled with high-quality familiarization with the design.

Why Evaluate an Architecture? The cost to fix an error found during requirements or early design phases is orders of magnitudes less to correct than error found in testing. Architecture determines the structure of the project: schedules and budgets, performance goals, team structure, documentation organization, and testing and maintenance activities.

When Can an Architecture Be Evaluated? The classical application of architecture evaluation occurs when the architecture has been specified but before implementation has begun.

When Can an Architecture Be Evaluated? Two useful variations from : early and late. Early - at any stage in the architecture creation process to examine those architectural decisions already made and choose among architectural options. Late - takes place when the architecture is nailed down and the implementation is complete. Mainly used when architecture is inherited from legacy system.

Who's Involved? Evaluation team - these are the people who will conduct the evaluation and perform the analysis. Stakeholders - stakeholders are people who have a vested interest in the architecture and the system.

What Are the Outputs of an Architecture Evaluation? Prioritized Statement of Quality Attribute Requirements. Having a prioritized statement of the quality attributes serves as an excellent documentation record to accompany any architecture and guide it through its evolution.

What Are the Outputs of an Architecture Evaluation? Mapping of Approaches to Quality Attributes. produces a mapping that shows how the architectural approaches achieve (or fail to achieve) the desired quality attributes.

What Are the Outputs of an Architecture Evaluation? Risks and Non-risks. Risks are potentially problematic architectural decisions. Non-risks are good decisions that rely on assumptions that are frequently implicit in the architecture.

What Are the Benefits and Costs? Forces an Articulation of Specific Quality Goals. Results in the Prioritization of Conflicting Goals. Puts Stakeholders in the Same Room. Improves the Quality of Architectural Documentation. Uncovers Opportunities for Cross-Project Reuse.

Conclusion The average architecture evaluation adds no more than a few days to the project schedule. Architecture created in haste will precipitate disaster: performance goals not met, Security goals falling, customer dissatisfaction, system that is too hard to change, and schedules and budgets through the roof.