DAIMIHenrik Bærbak Christensen1 What is Software Quality?

Slides:



Advertisements
Similar presentations
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development.
Advertisements

Software Testing and Quality Attributes Software Testing Module ( ) Dr. Samer Hanna.
DAIMIHenrik Bærbak Christensen1 Testing Terminology.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
What is software engineering?
Testing - an Overview September 10, What is it, Why do it? Testing is a set of activities aimed at validating that an attribute or capability.
Systems Design. Analysis involves understanding and documenting user requirements in a clear and unambiguous way. It focuses on the business side and.
 QUALITY ASSURANCE:  QA is defined as a procedure or set of procedures intended to ensure that a product or service under development (before work is.
Software Process and Product Metrics
Software Dependability CIS 376 Bruce R. Maxim UM-Dearborn.
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 17 Software Quality
OHT 3.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
Managing Software Quality
COURSE TITLE: 1 Software Quality Assurance. Course Aims Introduction to software quality assurance. Software testing terminology. Role and responsibility.
What is Software Engineering? the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software”
 The software systems must do what they are supposed to do. “do the right things”  They must perform these specific tasks correctly or satisfactorily.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
March 13, 2001CSci Clark University1 CSci 250 Software Design & Development Lecture #15 Tuesday, March 13, 2001.
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
Software Inspection A basic tool for defect removal A basic tool for defect removal Urgent need for QA and removal can be supported by inspection Urgent.
SOFTWARE ENGINEERING1 Introduction. Software Software (IEEE): collection of programs, procedures, rules, and associated documentation and data SOFTWARE.
Software Software is omnipresent in the lives of billions of human beings. Software is an important component of the emerging knowledge based service.
Software Quality Assurance SE Software Quality Assurance What is “quality”?
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 3 Slide 1 Critical Systems 1.
Dr. Tom WayCSC Testing and Test-Driven Development CSC 4700 Software Engineering Based on Sommerville slides.
Software Project Management Lecture # 3. Outline Chapter 22- “Metrics for Process & Projects”  Measurement  Measures  Metrics  Software Metrics Process.
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Software Testing and Quality Assurance Software Quality Assurance 1.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development 3.
1 Chapter 3 1.Quality Management, 2.Software Cost Estimation 3.Process Improvement.
CS551 - Lecture 5 1 CS551 Lecture 5: Quality Attributes Yugi Lee FH #555 (816)
1 EE29B Feisal Mohammed EE29B: Introduction to Software Engineering Feisal Mohammed Ph: x3156.
1 Software Architecture in Practice Quality attributes (The amputated version)
CSE 303 – Software Design and Architecture
Software Engineering. Acknowledgement Charles Moen Sharon White Bun Yue.
CS, AUHenrik Bærbak Christensen1 Critical Systems Sommerville 7th Ed Chapter 3.
Cloud Computing and Architecture Architectural Tactics (Tonight’s guest star: Availability)
Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Lecture Videos will no longer be posted. Assignment 3 is due Sunday, the 8 th, 7pm. Today: –System Design,
Chapter 5 – Software Testing & Maintenance (Evolution) 1.
©Ian Sommerville 2000Dependability Slide 1 Chapter 16 Dependability.
Software Architecture Quality Attributes. Good or Bad? Measurable criterions required...
Testing Overview Software Reliability Techniques Testing Concepts CEN 4010 Class 24 – 11/17.
CSHenrik Bærbak Christensen1 Flexibility and Maintainability And their metrics: coupling and cohesion.
Chapter 10 Software quality. This chapter discusses n Some important properties we want our system to have, specifically correctness and maintainability.
by: Er. Manu Bansal Deptt of IT Software Quality Assurance.
CPSC 372 John D. McGregor Module 8 Session 1 Testing.
Software Architecture in Practice
Regression Testing with its types
Introduction Edited by Enas Naffar using the following textbooks: - A concise introduction to Software Engineering - Software Engineering for students-
Software Verification and Validation
Chapter 18 Maintaining Information Systems
Software Architecture in Practice
Software Architecture Quality Attributes
BASICS OF SOFTWARE TESTING Chapter 1. Topics to be covered 1. Humans and errors, 2. Testing and Debugging, 3. Software Quality- Correctness Reliability.
Software engineering.
Definitions.
Introduction Edited by Enas Naffar using the following textbooks: - A concise introduction to Software Engineering - Software Engineering for students-
مقدمه اي بر مهندسي نيازمنديها
John D. McGregor Session 9 Testing Vocabulary
CSSSPEC6 SOFTWARE DEVELOPMENT WITH QUALITY ASSURANCE
Software Quality Assurance Lecture 3
Software Engineering and Architecture
Presentation transcript:

DAIMIHenrik Bærbak Christensen1 What is Software Quality?

DAIMIHenrik Bærbak Christensen2 Reflection What is software quality to you ? Name a program/application/system of high quality? Low quality? What aspects of it make it ‘high quality’ or ‘low quality’?

DAIMIHenrik Bærbak Christensen3 Definition of quality Criteria for a good definition of quality: allow us to measure quality in a meaningful way Why? –avoid dogmas –measure if techniques really improve quality –what investment gives most ‘return on investment’?

DAIMIHenrik Bærbak Christensen4 Quality views Kitchenham & Pleeger Transcendental view –quality can be recognized but not defined User view –quality is fitness for purpose Manufacturing view –quality is conformance to specification Product view –quality is inherent characteristics of the product Value-based view –quality is the amount costumer will pay for product

DAIMIHenrik Bærbak Christensen5 View clashing Stakeholders have different view on same product Morale: Trade-offs between cost and quality The product Researchers and Teachers Product view Customers User view Developers Manufacturing view Management Value-based view

DAIMIHenrik Bærbak Christensen6 Reflection What views did we use in our discussion of good/bad systems before? dPaSS / dSoftArk course preaches: –Low coupling / high cohesion –Favor object composition over class inheritance What is the view here ???

DAIMIHenrik Bærbak Christensen7 Quality frameworks Quality has many faces...

DAIMIHenrik Bærbak Christensen8 Quality Attributes... measure quality in a meaningful way. This requires –that we define the aspects/qualities we measure –that we agree on some kind of scale: a metric

DAIMIHenrik Bærbak Christensen9 Measuring quality Performance Maintainability Usability Quality Attribute Metric Measurement Choose alternatives Quality Framework

DAIMIHenrik Bærbak Christensen10 Quality Frameworks Of course – a lot of different quality frameworks have been proposed. –Bass, Clements and Kazman: Architecture Quality Attributes –Sommerville: Software Engineering books –IEEE Standard

DAIMIHenrik Bærbak Christensen11 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

DAIMIHenrik Bærbak Christensen12 Bass’ System Qualities Availability –probability that the system will be operational when needed Modifiability –ease with which the system supports change Performance –response time Security –ability to withstand attacks/threats Usability –how easy it is for the user to accomplish a desired task Testability –ease with which the software can be made to demonstrate its faults

DAIMIHenrik Bærbak Christensen13 Discussion Which of these qualities can be judged by a testing process? Which can be measured? –quantitatively (hard numbers: “4.3”) –qualitatively (judgment: “low/high”)

DAIMIHenrik Bærbak Christensen14 Dependability Sommerville Name systems where one is very important? What is the relation to ‘usefulness’? equates to its trustworthiness.

DAIMIHenrik Bærbak Christensen15 IEEE (Burnstein) IEEE Standard Glossary of SE terminology: 1. Quality relates to the degree to which a system, system component, or process meets specified requirements. 2. Quality relates to the degree to which a system, system component, or process meets customer or user needs, or expectations. Exercise: Relate to Kitchenham’s quality views...

DAIMIHenrik Bærbak Christensen16 War Story Major Danish company, highly active in services on the WWW. Requirement specification: Make something that is smarter than the competitors’ product...

DAIMIHenrik Bærbak Christensen17 Reliability and failure Reliability: Probability that a software system will not cause the failure of the system for a specified time under specified conditions. Failure is then defined by either –the specification (IEEE definition 1) –the user/customer (IEEE definition 2)

DAIMIHenrik Bærbak Christensen18 Reliability is in the eyes of the beholder Note that conditions are part of the definition. But conditions may change ! –Fault causing crash in Word’s fax service ? –Developer may be able to use his own prototype tool, but others may make it crash every time… –Our car’s engine would cut out during heavy rain 

DAIMIHenrik Bærbak Christensen19 Reliability and Failures Thus fixing any defect and removing a failure will not give same increase in reliability... Example: two defects –Word cannot save documents due to defect –Word cannot reconfigure button panel due to defect Which defect removal will increase reliability most?

DAIMIHenrik Bærbak Christensen20 Quality View Cem Kaner: The measure of a product’s or service’s quality is the satisfaction of their customers, not the match to a specification. A program’s quality is: –the features that make the customer want to use the program –the flaws that make the customer wish he’d bought something else

DAIMIHenrik Bærbak Christensen21 Yet another view Beizer There can never be an absolute definition for bugs, nor an absolute determination of the existence. The extent to which a program has bugs is measured by the extent to which it fails to be useful. This is a fundamentally human measure. Interesting… It makes many programs into defects instead

DAIMIHenrik Bærbak Christensen22 Ensuring reliability Reliability is compromised by failures. Failures happen when the system is in an error state, which may be caused by a defect. So – reliability can be enhanced by several measures. –Fault avoidance: simply avoid introducing defects! –Fault detection and removal: Find and remove the defects before they cause failures. –Fault tolerance: Ensure that faults does not lead to failures.

DAIMIHenrik Bærbak Christensen23 Fault avoidance Use methods, tools, languages, techniques that are known to minimize the probability of introducing defects. –Corollary: Avoid using m,t,l,t that are notoriously known for introducing defects That is: Never, ever, use C or C++ Use safe languages (Java, C#) Use proven design techniques –encapsulation, no goto’s, type-checking, etc.

DAIMIHenrik Bærbak Christensen24 Fault detection and removal The primary focus of this course: Hunt down the defects by what-ever means (execution, review) and remove them.

DAIMIHenrik Bærbak Christensen25 Fault tolerance If we know that cannot remove all defects then at least ensure that they do not lead to failures –Exception handling: handle IO errors gracefully null pointer exceptions? –N-version programming let n teams develop the same software unit vote on the n results Space shuttle maintains five parallel systems –one running base flight software –four running mission and flight software

DAIMIHenrik Bærbak Christensen26 Run-time cycle Faults cause failures when faulty code is executed with inputs that expose the fault. –I_e: input that will lead the system into error state Program execution state I_e error states Input space

DAIMIHenrik Bærbak Christensen27 Economic consequences Not all input have the same probability –Which function to you use most in Word? save document reconfigure button panel –If a defect is present which unit would you rather have it in? save document algorithm reconfigure button panel algorithm Thus with a given testing budget not all test cases are born equal!

DAIMIHenrik Bærbak Christensen28 Summary Quality is many things... There are several frameworks defining quality All, however, must deal with reliability –Reliability: Probability that a software system will not cause the failure of the system for a specified time under specified conditions Reliability techniques –fault avoidance; fault removal; fault tolerance Not all faults are equally important for reliability Testing budget should be used wisely