SEN 460 Software Quality Assurance SEN 460 Software

  • Slides: 26
Download presentation
SEN 460 Software Quality Assurance

SEN 460 Software Quality Assurance

SEN 460 Software Quality Assurance Bahria University Karachi Campus Waseem Akhtar Mufti B. E(UIT),

SEN 460 Software Quality Assurance Bahria University Karachi Campus Waseem Akhtar Mufti B. E(UIT), M. S(S. E) AAU Denmark Assistant Professor Department of Computer Science Contact: wmufti@gmail. com Waseem. akhter@bimcs. edu. pk Mobile: 03332122825 03032233347 File access: tinyurl. com/sqa 8 cs

SEN 460 Software Quality Assurance Text book Software Quality Assurance From theory to implementation

SEN 460 Software Quality Assurance Text book Software Quality Assurance From theory to implementation By DANIEL GALIN

SEN 460 Software Quality Assurance Chapter 7 Integrating quality activities in the project life

SEN 460 Software Quality Assurance Chapter 7 Integrating quality activities in the project life cycle

Introduction • Why software quality assurance professionals should know software engineering models? • SQA

Introduction • Why software quality assurance professionals should know software engineering models? • SQA assurance activities take place along with software development milestones. • SQA professionals should be acquainted with the various software engineering models.

Software development methodology • The Software Development Life Cycle (SDLC) model. • The prototyping

Software development methodology • The Software Development Life Cycle (SDLC) model. • The prototyping model. • The spiral model. • The Object-Oriented Model.

Software Development Life Cycle

Software Development Life Cycle

Software Development Life Cycle • At the end of each phase outputs are examined

Software Development Life Cycle • At the end of each phase outputs are examined and evaluated by developer and customer. • Approval of the phase outputs. • Approval to progress for the next phase. • Demands to correct, redo, or change parts of the last phase. • Return to earlier phase is also possible.

Prototyping Model

Prototyping Model

Spiral Model

Spiral Model

Object-Oriented Model

Object-Oriented Model

Factors affecting the intensity of quality assurance activities in the development process Magnitude of

Factors affecting the intensity of quality assurance activities in the development process Magnitude of the project. Technical complexity and difficulty. Extent of reusable software components. Severity of failure outcomes if the project fails. Professional qualification of the team members. • Availability of professional team members. • Familiarity of new members in team. • • •

Factors affecting the intensity of quality assurance activities in the development process • •

Factors affecting the intensity of quality assurance activities in the development process • • • Example project: Client: Furniture company. Team experience: 11 the project # of team members: 2 Estimated duration: 4 months. Reusability 90% Quality assurance activity Duration of QA activities Duration of corrections and changes Design review of requirements definitions 0. 5 1 Inspection of the design 1 1 System test of completed software 4 2

Factors affecting the intensity of quality assurance activities in the development process • Factors

Factors affecting the intensity of quality assurance activities in the development process • Factors affecting: – Degree of team acquaintance with the project. – High percentage of software reuse. – Size of the project. – Severity of failures if the project fails. • Developer’s advantages: – Less project complexity. – High degree of project acquaintance. – High percentage of reuse. – Possibility of XP programming.

Verification, validation and qualification • Verification, validation and qualification of products (report, code, design

Verification, validation and qualification • Verification, validation and qualification of products (report, code, design documents, testing strategies, specifications) • Verification: IEEE standards – “The process of evaluating a system or component to determine weather the products of a given development phase satisfy the conditions imposed at the start of that phase” – Verification is: • Evaluation of products at given phase. • Consistency of products with those of previous phase.

Verification, validation and qualification • Validation (IEEE standards) – “The process of evaluating a

Verification, validation and qualification • Validation (IEEE standards) – “The process of evaluating a system or component during or at the end of development to determine weather it satisfies specified requirements. ” • • Represents customer’s interests. Compliance to user’s original requirements. Inputs, outputs and correctness of programs. Customer is more concerned to the working of software components.

Verification, validation and qualification • qualification (IEEE standards) – “The process used to determine

Verification, validation and qualification • qualification (IEEE standards) – “The process used to determine weather a system is suitable for operational use. ” • Standards of maintenance requirements. • A system meeting the standards is flexible for maintenance.

A model for SQA defect removal effectiveness and cost • Defect detection activities: –

A model for SQA defect removal effectiveness and cost • Defect detection activities: – Defect removal plan’s effectiveness. – Cost of removal of defects. • Data and Model – to eliminate defects • Data: (according organizational survey of 20 years) – Defect origin distribution: – Defects are distributed across project phases. Software development phase Avg %age of defects Requirements specification 15% Design 35% Coding 40% Documentation 10%

Verification, validation and qualification • Defect removal effectiveness: – Not all defects are detected.

Verification, validation and qualification • Defect removal effectiveness: – Not all defects are detected. – Some of the detected defects (ineffective) are not removed. – Some of undetected defects are found in next phases. – Overall only 40% of defects are removed (according to survey) – How about the unknown defects? ?

Computer disasters • The Mars Climate Orbiter crashed in September 1999 because of a

Computer disasters • The Mars Climate Orbiter crashed in September 1999 because of a "silly mistake“. • Cause: Software. • Ref: http: //www. cs. tau. ac. il/~nachumd/horror. h tml

Computer disasters • On June 4, 1996 an unmanned Ariane 5 rocket launched by

Computer disasters • On June 4, 1996 an unmanned Ariane 5 rocket launched by the European Space Agency exploded. • Cause: Bugs in processor • Ref: http: //www. cs. tau. ac. il/~nachumd/horror. h tml

Computer disasters • Iraqi Scud missile hit Dhahran barracks, leaving 28 dead. • The

Computer disasters • Iraqi Scud missile hit Dhahran barracks, leaving 28 dead. • The incoming missile was not detected by the Patriot defenses. • Cause: Missile Software • Ref: http: //www. cs. tau. ac. il/~nachumd/horror. html

Computer disasters • Bugs in the Intel Microprocessors. – Pre-pentium bugs. – Pentium FDIV

Computer disasters • Bugs in the Intel Microprocessors. – Pre-pentium bugs. – Pentium FDIV bugs. – Pentium II / Pentium Pro FPU bugs. – Pentium MMX bugs. – Ref: http: //www. cs. tau. ac. il/~nachumd/horror. html

Computer disasters • The Apollo 8 spacecraft erased part of the computer's memory. •

Computer disasters • The Apollo 8 spacecraft erased part of the computer's memory. • Cause: Software • Ref: http: //www. cs. tau. ac. il/~nachumd/horr or. html

Understanding computers deeply • DEVELOPING SOLUTIONS IS NOT ENOUGH • NEED FOR EFFICIENT AND

Understanding computers deeply • DEVELOPING SOLUTIONS IS NOT ENOUGH • NEED FOR EFFICIENT AND ERROR FREE SOFTWARE AND HARDWARE.

Verification, validation and qualification • Cost of defect removal: – Cost depends on phases.

Verification, validation and qualification • Cost of defect removal: – Cost depends on phases. – Cost during (Design phase) < Cost (acceptance tests). – Quality assurance activity Avg defect filtering effectiveness Requirement spec. review 50% Design inspection 60 % Design review 50% Code inspection 65% Unit test 50% Integration test 50% System test/Acceptance test 50% Documentation review 50% Unit test after code inspection 30%