SOFTWARE QUALITY ASSURANCE Maltepe University- Faculty of Engineering SE410.

SOFTWARE QUALITY ASSURANCE

Maltepe University- Faculty of EngineeringSE410

SE 410 - Software Quality Assurance

2

Chapter 1

INTRODUCTION TOSOFTWARE QUALITY and

ASSURANCE


3

• What is Software?

• Software error, fault and failure

• Classifying the reasons of software errors

• What is Software Quality?

• Properties that determines software quality

• Software Quality Assurance and Aims

• Problems in Software Quality

• Quality System and Management

• Cost of Quality

• Best Practices Approach

• SWEBOK (Software Engineering Body of Knowledge)

Outline


4

What is Software?

• Software is a computer program that manages computer hardware and also performs the instructions of the user of the computer.

• IEEE defines the software as: «It is a complement of codes, procedures, data and documents about operation of a computer systems.»

• Computer softwares can be viewed in two main groups;

• System Software

• Application Software


5

Software – Basic Concepts

• Error: : Mistake that a programmer makes

• Fault: Consequence of an error in the software

• Failure: It is the wrong output produced by a software.


6

Classifying Reasons of Software Errors

• We can classify the reasons of the software errors as follows:

Wrong definition of requirements, Failure of communication between customer and the developer, Deviating from requirements on purpose, Logical design failure, Coding errors, Not following the documentation and coding standards, Lack of test process, User interface and procedure faults, Documentation faults.


7

Problems in Software Development

Based on the questionnaires that have been done to review hundreds of software projects in late 1970s and in early 1980s in USA.

Rate of successful projects: % 4 - % 5 Rate of patially successful projects: % 40 - % 45 Rate of unsuccessful projects: % 50 - % 55


8

Problems in Software Development (cont..)

• Observed a little improvement during 1990’s

• In the early 2000’s, there is a progress than 20 years ago.

• 53% of the projects in USA deviated at the rate of 189% in 2001.


9


• According to the research of The Standish Group about software projects in 2000,

% 90 late delivery. % 50 over budget. % 50 not meet the client’s needs. % 20 canceled.


10



11

Real Project Failures

Yıl Şirket Sonuç (Maliyetler ($))

2005 Hudson Bay Co. (Canada) Problems with inventory system, caused 33.3 million $ loss.

2004-05 Inland Revenue (England) Software faults caused 3.45 billion $ more tax payment

2004 Avis Europe PLC (England) ERP system, canceled after paying 54.5 million $

2004 Ford Motor Co. Buying system, canceled because of a 400 million $ cost of delivery

2004 J Sainsbury PLC (England) Supply-chain management system, canceled because of a 527 million $ cost of delivery

2004 Hewlett-Packard Co. Problems about ERP system, caused 160 million $ loss.

2003-04 AT&T Wireless CRM updating problems, caused 100 million $ profit loss.

2002 McDonald’s Corp. Information buying system, canceled after paying 170 million $

2002 Sydney Water Co. Billing system, canceled after paying 33.2 million $


12

Fail Reasons of Software Projects

• Project aims that are not fully indicated,

• Wrong estimations about essential resources,

• Wrong identified system requirements,

• Bad reporting of the Project progress,

• Unmanaged risks,

• Lack of communication between client and developer,

• Bad Project management,

• Commericial pressures


13

Quality Concept

• Quality, “ability to meet the requirements” (Edwards Deming, 1968).

• Quality, “To meet the client’s needs without a single fault.” (Crosby, 1979).

• Quality, “To make the right thing at once” (Price, 1985).

• Quality, “fit for purpose” (Juran, 1988).

• Quality, “hard to define, easy to see, impossible to measure” (Kitchenham, 1996).


14

Quality Concept (cont)

• Quality, «The complement of features of a product or service that meets certain needs.» (IEEE).


15

Quality Concept (cont)

• Important product quality criteria; Meeting user’s needs, Minimizing faults, Immediately fixing faults, Post-delivery support,


16

"Quality" Myths

• “Quality is an abstract concept and can not be measured”• Quality can be measured by measuring fault cost.

• “Lower level staff cause quality problems”• Lower level staff cause less quality problems than upper

level staff.


17

"Quality" Myths

• “Quality Departments of organizations start Quality”• Quality starts with the upper magagement level and must

be taken up by all employees.


18

Quality Concepts

• Quality Control; Application techniques and operations to provide quality requirements,

• Quality Assurance; The complement of planned and systematic operations to provide enough assurance with the purpose of meeting the needs for the quality of the product or the service,

• Quality Management; The part of general management that determines and performs the quality policy,

• Quality System; The complement of organization structure, responsibilities, procedures, processes and resources that is essential for implementing the quality management


19

Quality Concepts (cont)

• Quality control; To examine activities and outcomes about quality whether they are stick to the planned arrangements and to examine whether those arrangements are applied effectively.


20

How to Provide Quality?

• Traditional Consideration: Debugging Errors• «Quality Control»• Techniques and activities that are used to determine whether the defined

requirements of a product or service are met.

• Improved Consideration: Avoiding Errors• «Quality Assurance»• Systematic and planned activities to assure meeting the requirements of a

product ot service adequately.


21

What is Software Quality?

• Acceptable error level,

• Meets the requirements,

• Suitable to use,

• In Time Delivery,

• Developed in budget,

• Compatible with standards,

• Maintainable software.


22

Features Determine Software Quality

Features related to running software ,

Features related to software improvement,

Features related to software compatibility


23

Features related to Running Software

• Correctness: Performing tasks as needed and accurate.

• Reliability: Keep running without malfunctioning.

• Efficiency: Using system resources properly.

• Immunity: Software must protect the system against intrusions and attacks from unauthorized users.

• Usability: Software must be usable as easy as possible. User interface must be user-friendly (easy to use).


24

Features related to software improvement

• Maintainability: Software must be coded deducible, well documented and easy to test to be maintained by another software developer.

• Flexibility: Software must be customizable/adaptable as possible to add new features.

• Testability: This feature is essential for software developer. The whole system or a part of it can be tested.


25

Features related to software compatibility

• Portability: Software must be adapted easily to another operating system or hardware.

• Reusability: It shows whether some parts of software can be used in other systems/projects or not.

• Compatibility: A software product must be compatible with previous versions or collaborator.


26

Software Quality Assurance

• All planned and systematic operations that need to be applied to all workflows in software life-cycle to provide enough assurance.


27

Goals of SQA

• To improve software quality by controlling software development process

• To assure complying with standards and methods which are developed for software process.

• To catch management’s attention in case of insufficiency about the product, process or standards.


28

Problems in Software Quality

• Prioritising quality features,

• Long term investment to provide quality,

• Keeping up with new techs,

• Staff motivation.


29

Why Need Quality in Software

• An experienced engineer produces an error in every 7-10 code lines.• It means thousands of lines in a mid scope Project.

• Most of errors are corrected in test stage.

• That means late delivey, expensive post delivery maintenance, low quality product.


30

Quality System

• There must be a quality guideline in quality system

• Quality guideline consists of following concepts:

standards,

procedures,

guidelines.


31

Quality Management

• Software Quality Assurance is related to process development, using standards, requirements management, testing, validation, verification, reliability, maintainability.

• To provide and maintain this relation we need a Quality Management in every level of the organization.


32

Cost of Quality

• Some controls must be done step by step to keep the quality cost of the software product low. The activities needed in those control steps are as follows:

Precaution : Planning, education, process enhancement activities, Validation/Verification : design and code control, tests, etc. Error correction: code fixing, re-test.


33

Cost of Quality (cont)

• Optimum balance is important between steps. But;

Cost of error increases progressively Thus preventing an error before it occurs is the cheapest way.


34

Cost of Quality (cont)

• Software products have a different quality consideration from other products. An incomplete/insufficient/faulty software can be released on purpose;

To release an earlier time, Other reasons (promised, market competition etc.)

• It is hard to measure software quality A virtual product, Complex.


35

Best Practices Approach

• Software Quality principles have been shaped by past best practice experiences.

• Best practices are guides.

• Best practices built up the basics of accepted quality models.


36

Best Practices Approach (cont)

• Early diagnosis, early solution reduces cost.

• Process is important, not the product. Process must be enhanced.

• Continuous enhancement,

• Standards and measures must be used.

• Investigate Client satisfaction.


37


• Use project estimation tools.

• Document the processes.

• Use methodology and documantation.

• Perform critical design review (CDR).

• Code walkthrough and inspection.


38


• Use configuration management tools.

• Measure and analyse errors and reliability,

• Use estimation models.

• Post Project evaluation.


39

SWEBOK (Software Engineering Body of Knowledge)

SWEBOK, A product of attempt of gathering and classifying software engineering concepts by an international expert group under IEEE Computer Society

First version in 2001, Second version in 2004, Third and latest version in 2010.


40

SWEBOK (cont)

• Software Engineering definition: It is a disciplined, quantitative and systematic engineering approach for software development, running and maintenance


41

SWEBOK (cont)

• 10 main knowledge area in Software ENGİNEERİNG:

1. Software Requirements

2. Software Design

3. Software Construction

4. Software Testing

5. Software Maintenance

6. Software Configuration Management

7. Software Enginering Management

8. Software Process

9. Software Tools and Methods

10. Software Quality


42

SWEBOK (cont)

• Related Areas: Computer Engineering Computer Sciences Mathematics Management Science

Quality Management Project Management

Human Computer Interaction System Engineering


43

KA 1: Software Requirements

Requirement: The operation that the software product must perform.

• Requirements Engineering Process,• Requirements Elicitation,• Analysis,• Specification,• Validation, • Requirements Management.


44

KA 2: Software Design

Design: Architectural structure, modules, interfaces and definition of other features;

• Software Design Basic Concepts,

• Key Issues,

• Software Structure and Architecture,


45

KA 3: Software Construction

• Reduction of Complexity,

• Anticipation of Diversity,

• Structuring for Validation,


46

KA 4: Software Test

The aim is to validate the software product dynamically with pre-defined data whether it is running as needed or not.

• Basics,

• Levels,

• Techniques,

• Measures.


47

KA 5: Software Maintenance

Yazılımın işletmede, çalışır durumda tutulması ve yeni durumlara uyarlanmasıdır. The aim is to kkep the software product running and up to date.

• Process,

• Maintenance Techniques.


48

KA 6: Configuration Management

The aim is to ensure software integrity, to control every single change in software configuration.

• Process Management,

• Change Control,

• Accounting,

• Auditing,

• Version Control.


49

KA 7: Engineering Management

Project management in terms of engineering. Measurements etc.

• Initiation & Scope,

• Project Planning,

• Project Execution,

• Revision and Evaluation,

• Closure,

• Measures,


50

KA 8: Engineering Process

Aim is to define, apply, measure, evaluate, management and enhancement of software processes.

• Process Definition,

• Process Evaluation,

• Process and Product Criteria.


51

KA 9: Tools and Methods

Yazılım mühendisliğinde kullanılan araçlar ve metotlar.

• Tools (for every KA),

• Methods; Heuristic, Formal, Prototyping.


52

KA 10: Quality

Project Management

• Basics,

• Management,

• Practical Points.


53

SWEBOK Homework…http://www.computer.org/portal/web/swebok

SOFTWARE QUALITY ASSURANCE Maltepe University- Faculty of Engineering SE410.

Documents

Transcript of SOFTWARE QUALITY ASSURANCE Maltepe University- Faculty of Engineering SE410.