Lecture 2: Software Quality Factors, Models and Standards. Software Quality Assurance (INSE 6260/4-UU) Winter 2016

Size: px

Start display at page:

Download "Lecture 2: Software Quality Factors, Models and Standards. Software Quality Assurance (INSE 6260/4-UU) Winter 2016"

Opal Leonard
5 years ago
Views:

1 Lecture 2: Software Quality Factors, Models and Standards Software Quality Assurance (INSE 6260/4-UU) Winter 2016

2 INSE 6260/4-UU Software Quality Assurance Software Quality Quality Assurance Factors and Models Metrics Inspection Testing Techniques Reachability Analysis 2

3 Overview Requirement Engineering Factor/Criteria/Metric Paradigm Software Quality Models Some Quality Standards 3

4 Some Software Development Life Cycles SDLC model (~waterfall) Prototyping Model Spiral Model Evolutionary Models 4

5 The Prototyping Model Req. determination By the costumer Prototype Design Prototype implementation Prototype Evaluation By customer Req. fulfilled? No Demands for Corrections, Changes and additions Yes System Tests & Acceptance tests System Conversion System Operation and maintenance 5

6 Spiral Model An iterative process, at each iteration, the following activities are performed: Planning Risk analysis and resolution Engineering activities according to the stage of the project: design, coding, testing, installation and release Customer evaluation, including comments, changes and additional requirements, etc. 6

Planning Spirale Cycle I. Risk analysis II. Determine objectives, alternatives, constraints review 1 2 3 1 2 3 Operational Prototype Evaluation by the customer IV.

7 Planning Spirale Cycle I. Risk analysis II. Determine objectives, alternatives, constraints review Operational Prototype Evaluation by the customer IV. Development plan Requirements Plan, life cycle plan etc. Concept of Operation Validation of requirements Simulation, models, benchmarks Coding Detailed design Engineering III. 7

8 Evolutionary Models Many variants available Product development evolves through increments evolutionary prototype Evolutionary process model (B. Boehm, 1988) "model whose stages consist of expanding increments of an operational software product, with the direction of evolution being determined by operational experience" 8

9 Requirement Engineering Goal: determine the client s desires Requirements Elicitation, Capture and Analysis Complex task because of What the client says What the clients doesn't say What the designer understands What the designer interprets 9

10 Requirement Engineering Requirement List should be Described and reviewed Approved by the client Identifiable and verifiable Requirements are the basis for the development process TRACEABILITY is important 10

11 Requirement Engineering: TRAPS Hidden Evidences Implicit Ambiguous Imprecise Incomplete 11

12 How to Avoid Traps Formalization - Formal or Semi-formal methods - Modeling - Communication between the client and designer Prototyping - Use tools for rapid prototyping - Simulations Audits and Reviews 12

13 Modeling: Engineer Act Why Modeling? High Level Abstraction Reasoning - Focus on important mechanisms only - Don't get into implementation details (you will be lost!) Design and requirements confrontation: Traceability Test production guidance 13

14 A Model Works Under Hypothesis Hypothesis include - System s environment - Limitations inherent to the language and tools you are obliged to use A model worth nothing if not accompanied by clearly stated hypothesis 14

15 Models and Properties Models are for: - Documentation - Verification - Reference to subsequent implementations - Reference to testing A model is meant to be checked against properties - Think of properties first! 15

16 Advantages of using Formalization Formal syntax and semantics V&V - Qualitative vs. quantitative analysis - Simulation - Reachability analysis Model checking Verification by abstraction Automatic code generation Test sequence generation 16

17 Overview Requirement Engineering Factor/Criteria/Metric Paradigm Software Quality Models Some Quality Standards 17

18 Factor/Criteria/Metric Paradigm Factor Management oriented view Criteria Criteria Criteria Quality attributes Metrics Metrics Metrics Quantitative measures of these attributes 18

19 Software Measurement and Metrics Software measurement is concerned with deriving a numeric value for an attribute of a software product or process This allows for objective comparisons between techniques and processes Although some companies have introduced measurement programmes, most organisations still do not make systematic use of software measurement 19

20 Software Metric Any type of measurement which relates to a software system, process or related documentation Lines of code in a program, number of person-days required to develop a component Used to quantify the software and the software process May be used to predict product attributes or to control the software process 20

21 Classification of Attributes or Software Qualities Internal vs. external External visible to users Internal concern developers Product vs. process Our goal is to develop software products The process is how we do it Internal qualities affect external qualities Process quality affects product quality 21

22 Internal and External Attributes Maintainability Number of procedure parameters Cyclomatic complexity Reliability Portability Usability Program size in lines of code Number of err or messages Length of user manual 22

23 Cyclomatic Complexity Cyclomatic complexity is a software metric in computational complexity theory It was developed by Thomas McCabe and is used to measure the complexity of a program It directly measures the number of linearly independent paths through a program's source code 23

24 Cyclomatic Complexity Cyclomatic complexity is computed using a graph that describes the control flow of the program. The nodes of the graph correspond to the commands of a program. A directed edge connects two nodes if the second command might be executed immediately after the first command C = E-N+2P 24

25 Overview Requirement Engineering Factor/Criteria/Metric Paradigm Software Quality Models Some Quality Standards 25

26 McCall s Quality Model Quality Software Product operation factors Product revision factors Correctness Reliability Efficiency Integrity Usability Maintainability Flexibility Testability Product transition factors Portability Reusability Interoperability 26

27 Quality Models Product operation Correctness-Does it do what I want? Reliability -Does it do it accurately all the time? Efficiency -Will it run on my machine as well as it can? Integrity -Is it secure? Usability-Can I run it? Product revision Maintainability-Can I fix it? Flexibility-Can I change it? Testability-Can I test it? Product transition Portability-Will I be able to use on another machine? Reusability-Will I be able to reuse some of the software? Interoperability -Will I be able to interface it with another machine? 27

28 Quality Models (cont.) Product revision includes Maintainability (the effort required to locate and fix a fault in the program within its operating environment) Flexibility (the ease of making changes required by changes in the operating environment) and Testability (the ease of testing the program, to ensure that it is error-free and meets its specification) 28

29 Quality Models (cont.) Product transition is all about Portability (the effort required to transfer a program from one environment to another) Reusability (the ease of reusing software in a different context) and Interoperability (the effort required to couple the system to another system) 29

30 Quality Models (cont.) Quality of product operations depends on Correctness (the extent to which a program fulfils its specification) Reliability (the systems ability not to fail) Efficiency (further categorized into execution efficiency and storage efficiency and generally meaning the use of resources, e.g. processor time, storage) Integrity (the protection of the program from unauthorized access) and Usability (the ease of the software) 30

31 McCall s Quality Model 11 Quality factors on the Right side 23 Quality criteria on the left side 31

32 11 Quality factors on the Right side 23 Quality criteria on the left side 32

33 Evans and Marciniak vs. Deutsch and Willis 33

34 Evans and Marciniak vs. Deutsch and Willis 34

35 Boehm's Software Quality Tree 35

36 36

37 ISO/IEC

38 38

39 Dromey's Quality Model 39

40 40

41 Overview Requirement Engineering Factor/Criteria/Metric Paradigm Software Quality Models Some Quality Standards 41

42 ISO 9000 A set of quality standards developed so that purchasers of goods can have confidence that suppliers of these goods have produced something of acceptable quality ISO 9000 certification has become a widely required international standard Any supplier who is not ISO 9000 certified will find it difficult to sell their goods The ISO standard describes how to apply the general ISO 9000 standard to the software industry The ISO standard addresses design, development, production, installation and maintenance issues The emphasis in the ISO standard is on documentation of the process and the managing of the process 42

43 ISO SQA Standard Control of inspection and test equipment Inspection and test status Control of nonconforming product Corrective action Handling, storage, packaging and delivery Control of quality records Internal quality audits Training Servicing Statistical techniques 43

44 Capability Maturity Model Integration (CMMI) 44

45 Capability Maturity Model Integration The Capability Maturity Model for Software (CMMI) is a five level model laying out a generic path to process improvement for a software organization 1. Initial ad hoc 2. Repeatable basic management processes 3. Defined management and engineering processes documented, standardized, integrated, and actually used 4. Managed measured and monitored and controlled using measurements 5. Optimizing Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies 45

46 CMMI Levels and Key Process Areas 1. Initial level No formalized procedures, project plans, cost estimates Tools not adequately integrated Many problems overlooked/ignored Maintenance very difficult Generally ad-hoc processes 2. Repeatable level Requirements management Software Project planning Software project tracking and oversight Software subcontract management Software quality assurance Software configuration management 46

47 CMMI Levels and Key Process Areas 3. Defined level Organization process focus Organization process definition Training Program Integration software management Software product engineering Inter-group coordination Peer reviews 4. Managed level Quantitative process management Software Quality management 5. Optimizing level Defect prevention Technology change management Process change management 47

48 48

49 References Chap 1, 2, 3 &4 of Software Quality Assurance Daniel Galin 49

Chapter 6. Software Quality Management & Estimation

Chapter 6. Software Quality Management & Estimation Chapter 6 Software Quality Management & Estimation What is Quality Management Also called software quality assurance (SQA) s/w quality:- It is defined as the degree to which a system, components, or process