1 Software Architecture in Practice Quality attributes (The amputated version)

Slides:



Advertisements
Similar presentations
Computer Systems & Architecture Lesson 2 4. Achieving Qualities.
Advertisements

ATAM Architecture Tradeoff Analysis Method
Testing Coverage Test case
DAIMI(c) Henrik Bærbak Christensen1 Software Architecture Quality Attributes.
Quality Attributes Or, what’s wrong with this: Exterminator kit – place bug on block, strike with mallet.
Lecture 13 Enterprise Systems Development ( CSC447 ) COMSATS Islamabad Muhammad Usman, Assistant Professor.
Copyright 2003 National ICT Australia Limited 1 Mining Patterns to Support Software Architecture Evaluation 4 th Working IEEE/IFIP Conference on Software.
Instructor: Tasneem Darwish
Understanding Quality Attributes. Functionality and Quality Attributes  Functionality and quality attributes are orthogonal.  Functionality can be achieved.
1 Software Testing and Quality Assurance Lecture 33 – Software Quality Assurance.
1 Steve Chenoweth Tuesday, 10/04/11 Week 5, Day 2 Right – Typical tool for reading out error codes logged by your car’s computer, to help analyze its problems.
1 Steve Chenoweth Tuesday, 10/25/11 Week 8, Day 2 Right – Desktop computer usability metaphor, from
Software project management (intro) Quality assurance.
The Architecture Design Process
1 Steve Chenoweth Tuesday, 10/18/11 Week 7, Day 2 Right – One view of the layers of ingredients to an enterprise security program. From
Evaluating Software Architectures RiSE’s Seminars Clement’s book :: Chapters 05 Eduardo Cruz.
DAIMIHenrik Bærbak Christensen1 What is Software Quality?
Lecture 7 Quality Attributes = Nonfunctional Req. Topics Quality AttributesReadings: January 29, 2008 CSCE 492 Software Engineering.
Principles of Software Architecture Evaluation and Design
Lecture Nine Database Planning, Design, and Administration
Evaluating Architectures Quality control: rarely fun, but always necessary
Software Process and Product Metrics
Non-functional requirements
Oracle High Availability Doug Smith CIS 764 Fall Semester 2007.
Picture 1 model: ICT lifecycle in a company 1. business needs & business strategy 2. ICT strategy - ICT assessment - ICT strategic plan - ICT implementation/tactical.
Requirements Engineering
Software Project Management Fifth Edition
Database System Development Lifecycle © Pearson Education Limited 1995, 2005.
COURSE TITLE: 1 Software Quality Assurance. Course Aims Introduction to software quality assurance. Software testing terminology. Role and responsibility.
Supplementary Specifications (Chapters 20,22 - Requirements Text) Question 1 by Steve & Chandan (Along with others in the past! - See notes, below)
1 Computer Systems & Architecture Lesson 2 3. Understanding Quality Attributes.
Quality Models and Quality Attributes. Outline  Process and product quality Improving the quality of the process can improve the quality of the product.
Quality Attributes Often know as “–ilities” …
Supplementary Specifications (Chapters 20,22 - Requirements Text) 1.
Module 7: Fundamentals of Administering Windows Server 2008.
1 Software Testing and Quality Assurance Lecture 33 – Software Quality Assurance.
SOFTWARE SYSTEMS DEVELOPMENT 4: System Design. Simplified view on software product development process 2 Product Planning System Design Project Planning.
Quality Attribute -continued. What is Availability? Availability refers to a property of software that it is there and ready to carry out its task when.
Other Quality Attributes Other Important Quality attributes Variability: a special form of modifiability. The ability of a system and its supporting artifacts.
Rapid software development 1. Topics covered Agile methods Extreme programming Rapid application development Software prototyping 2.
Software Project Management Lecture # 3. Outline Chapter 22- “Metrics for Process & Projects”  Measurement  Measures  Metrics  Software Metrics Process.
OHTO -99 SOFTWARE ENGINEERING “SOFTWARE PRODUCT QUALITY” Today: - Software quality - Quality Components - ”Good” software properties.
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem.
12.1 Introduction Checklists are used as a technique to give status information in a formalized manner about all aspects of the test process. This chapter.
1 Software Architecture in Practice Quality attributes.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5.
CS551 - Lecture 5 1 CS551 Lecture 5: Quality Attributes Yugi Lee FH #555 (816)
Fault Tolerance Benchmarking. 2 Owerview What is Benchmarking? What is Dependability? What is Dependability Benchmarking? What is the relation between.
Evaluating Architectures. Quality Control Rarely fun, but always necessary 1.
# 1 AMI Enterprise Task Force of the Utility AMI Working Group SRS Team Plan Discussion For further information, contact Joe Zhou Team Lead
Cloud Computing and Architecture Architectural Tactics (Tonight’s guest star: Availability)
Process Asad Ur Rehman Chief Technology Officer Feditec Enterprise.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Software Architecture Quality Attributes. Good or Bad? Measurable criterions required...
Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Quality Attributes & Tactics (1)
Chapter 12: Other Quality Attributes
Software Architecture in Practice
Rekayasa Perangkat Lunak Part-10
Rekayasa Perangkat Lunak
Security SIG in MTS 05th November 2013 DEG/MTS RISK-BASED SECURITY TESTING Fraunhofer FOKUS.
Chapter 11: Usability © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License.
Software Architecture Quality Attributes
Rekayasa Perangkat Lunak
Quality Attributes Or, what’s wrong with this:
Software Architecture in Practice
Quality Attributes Or, what’s wrong with this:
Software Engineering and Architecture
Quality Attributes Or, what’s wrong with this:
Presentation transcript:

1 Software Architecture in Practice Quality attributes (The amputated version)

2 Quality Attributes Is a design good or bad? The problem about ”good” or ”bad” is that they are subjective measures... We need to measure our software. This requires –that we define the aspects/qualities we measure –that we agree on some kind of scale: a metric

3 Measuring quality Performance Reliability Usability Quality Attribute Metric Measurement Choose alternatives Quality Framework

4 SAiP’s contribution Aim: –Characterization of architectural quality attributes and how this can be used to express quality requirements for a system Evaluation basis: –Scenario-based – Quality attribute scenarios define yardsticks of quality. before the fact – applicable at the “back-of-a-napkin” phase

5 Quality framework (Bass et al.) System quality attributes –Availability –Modifiability –Performance –Security –Testability –Usability Business qualities –Time to market –Cost –Projected lifetime –Targeted market –Roll-out schedule –Integration with legacy sys. Architectural qualities –Conceptual integrity –Correctness and completeness –Buildability

6 Qualities in context What is the context for a given quality? –is performance globally important? Modifiability? –a QA (usually) only makes sense in a given context: e.g. response-time is important during normal operation but slow initialization may be OK. modifiability is important in components/subsystems that are estimated to be changed often. Quality Attribute Scenarios –ground quality in specific “use situation”

7 Quality attribute scenarios (QAS) Source of stimulus. This is some entity (a human, a computer system, or any other actuator) that generated the stimulus. Stimulus. The stimulus is a condition that needs to be considered when it arrives at a system. Environment. The stimulus occurs within certain conditions. The system may be in an overload condition or may be running when the stimulus occurs, or some other condition may be true. Artifact. Some artifact is stimulated. This may be the whole system or some pieces of it. Response. The response is the activity undertaken after the arrival of the stimulus. Response measure. When the response occurs, it should be measurable in some fashion so that the requirement can be tested.

8 Example: Performance

9 Benefits Operational definition –Given architecture and wanted quality – we can say “yes” or “no” !!! Scenario aspect –avoid those “global statements” we want high performance” –yes – but which part should perform??? Common vocabulary –stimulus cover ‘event’, ‘attack’,...

10 Examples Using the Next-POS system

11 NextGen POS Again

12 Availability Concerned with the probability that the system will be operational when needed –The MySQL server crashes during normal operation, the application server detects this and notifies user and maintainer, continues in degraded mode. A backup server is made available in one hour

13 Modifiability Concerned with the ease with which the system supports change –System administrator wants to add a new product category to system while system is operational. The administrator makes the modification with no downtime of the system and in less than 30 minutes

14 Performance Concerned with how long it takes the system to respond when an event occurs –Users are initiating 1000 inventory transactions stochastically each minute, all of which are processed with an average latency of two seconds

15 Security Concerned with the systems ability to withstand attacks/threats –Nonrepudiation, confidentiality, integrity, assurance, availability, auditing

16 Testability Concerned with the ease with which the software can be made to demonstrate its faults –At POS component completion time an increment integrator performs integration test of the component with more then 90% coverage in less than a week

17 Usability Concerned with how easy it is for the user to accomplish a desired task and the kind of user support the system provides –An administrator wants to adapt the POS system at configure time in order to change localization; system changes in less than one minute

18 Other System Quality Attributes? For instance: –Where is reliability? –Safety? Some may be modeled by the six quality attributes Others may need to be developed as general scenarios

19 Business Quality Attributes Business goals which shape the architecture –Qualities related to the business environment in which the system is being developed Examples –Time to market –Cost/benefit –Projected lifetime of system –Targeted market –Rollout schedule –Integration with legacy systems Also described with scenarios…

20 Architecture Quality Attributes Quality directly related to the software architecture itself Examples –Conceptual integrity Do similar things in similar ways –Correctness and completeness Does things right and does the right things –Buildability Ease of constructing a desired system Scenarios again… –Most suited to system qualities?

21 Discussion

22 Discussion ”It is the mapping of a system’s functionality onto software structures that determines the architecture’s support for quality attributes”. That is, the same functionality can be made available for the end user using any of a number of different architectures ! Functionality and architecture are orthogonal (independent)

Example I can develop a chemical plant control system that is dependable – but much cheaper one that is not... 23