Lect1 fault+quality

TQA 7011 SOFTWARE QUALITY ASSURANCE & TESTINGTQA 7011 SOFTWARE QUALITY ASSURANCE & TESTING
TEXT & REFERENCE BOOKSTEXT & REFERENCE BOOKS
1.1. Galin, D. (2004).Galin, D. (2004). Software quality assuranceSoftware quality assurance. Great. Great
Britain: Pearson.Britain: Pearson.
2.2. Sommerville (2004),Sommerville (2004), Software EngineeringSoftware Engineering, 7/e,, 7/e,
Addison-Wesley.Addison-Wesley.
3.3. Pressman,Pressman, R. S. (2005).R. S. (2005). Software Engineering: ASoftware Engineering: A
Practitioner’s ApproachPractitioner’s Approach.. 66th editionth edition.. McGraw-Hill.McGraw-Hill.
4.4. Jarvis, AlkaJarvis, Alka,, && CrandalCrandal, V. (1997)., V. (1997). Inroads to SoftwareInroads to Software
QualityQuality.. Prentice HallPrentice Hall..
5.5. O’Regan (2002).O’Regan (2002). A Practical approach to SoftwareA Practical approach to Software
QualityQuality, Springer., Springer.
6. CMMI Standards6. CMMI Standards
7. ISO9000-3 Standards7. ISO9000-3 Standards

CHAPTER 1 The Software QualityCHAPTER 1 The Software Quality
The objectives of this chapter are to:The objectives of this chapter are to:
1.1. Identify theIdentify the unique characteristics of softwareunique characteristics of software
2.2. Recognize theRecognize the characteristics of thecharacteristics of the
environmentenvironment
3.3. DefineDefine software quality assurance and itssoftware quality assurance and its
objectivesobjectives
4.4. The differences between OC & QAThe differences between OC & QA

• What is software?
• Software errors, faults and failures
• Classification of the causes of software errors
• Software quality – definition
• Software quality assurance – definition and
objectives
• Software quality assurance and software
engineering

Software is:
Computer programs, procedures,
and possibly associated
documentation and data related
to the operation of a computer
system.

The UniquenessThe Uniqueness between Software & Industrial Productbetween Software & Industrial Product
CharacteristicsCharacteristics SoftwareSoftware Industrial productIndustrial product
ComplexityComplexity High: Can be measured by the numberHigh: Can be measured by the number
of operational modesof operational modes
Low: Not allow for moreLow: Not allow for more
than a few thousandsthan a few thousands
modes of operationmodes of operation
VisibilityVisibility InvisibleInvisible VisibleVisible
ProductProduct
developmentdevelopment
Detecting inherent product defectsDetecting inherent product defects Check & test theCheck & test the
product prototype toproduct prototype to
detect its defectsdetect its defects
Product productionProduct production
planningplanning
This phase is not required for theThis phase is not required for the
software productsoftware product
Provides additionalProvides additional
opportunities to inspectopportunities to inspect
the productthe product
ManufacturingManufacturing Limited to copying the product & printingLimited to copying the product & printing
copies of the software manual;copies of the software manual;
expectations for detecting defects areexpectations for detecting defects are
quite limited during this phasequite limited during this phase
QA procedures areQA procedures are
applied to detectapplied to detect
failuresfailures

Software errors, faults & failure
• Software failure lies in a software errors
• Software errors are sections of the code that are partially or
totally incorrect
• Error can be grammatical error, logical error or caused by
other mistake
• Software error can cause improper functioning, i.e. software
fault
• Not all software faults lead to software failure.
• Failures occur when a user tries to apply the specific
software section that is faulty

The nine causes of software errors are:
1. Faulty requirements definition
2. Client-developer communication failures
3. Deliberate deviations from software requirements
4. Logical design errors
5. Coding errors
6. Non-compliance with documentation and coding
instructions
7. Shortcomings of the testing process
8. User interface and procedure errors
9. Documentation errors

Faulty definition of requirements:
Erroneous definition of requirements
Absence of vital requirements
Incomplete definition of requirements
Inclusion of unnecessary requirements
Client-developer communication failures:
Misunderstanding of the client’s instruction as stated in the requirement
document
Misunderstanding of the client’s requirements changes presented to the
developer in written form
Misunderstanding of the client’s requirements changes presented orally to the
developer
Misunderstanding of the client’s response to the design problems presented by
the developer
Lack of attention to client messages (requirement changes, client response on
the questions that raised by the developer)

Deliberate deviations from software requirements
Reuses software modules without sufficient analysis
Omit part of the required functions to cope with time and budget
constraint
Developer-initiated, unapproved improvements to the software
Logical design errors, for example:
Erroneous algorithm
Process definitions that contain sequencing errors
Erroneous definition of boundary conditions
Omission of required software systems states
Omission of definitions concerning reactions to illegal operation of the
software system
Coding error, for example:
Misunderstanding the design documentation
Linguistic(grammatically) errors in the programming languages
errors in the application of CASE and other development tools
errors in data selection etc.

Non-compliance with documentation and coding instructions
Cause difficulties to coordinate the code in the same team
Difficult to understand the coding when the team member resign, retire or
been promoted
Cause difficulties to design review team, test team and maintenance team
Shortcomings of the test process
Incomplete test plans
Failures to document and report detected errors and faults
Failure to promptly correct detected software faults
Incomplete correction of detected errors
Procedure errors
Documentation errors
Errors in the design documents and in the documentation integrated into
the body of the software.
Error in the user manuals and the help function

Software quality is:
(1) The degree to which a system, component, or
process meets specified requirements.
(2) The degree to which a system, component, or
process meets customer or user needs or
expectations.

Quality defines by various software quality specialists:Quality defines by various software quality specialists:
• Achieving high levels of user satisfaction, portability, maintainability,Achieving high levels of user satisfaction, portability, maintainability,
robustness, and fitness for use (Dr. Barry Boehm)robustness, and fitness for use (Dr. Barry Boehm)
• Conformance to user requirements (Phil Crosby)Conformance to user requirements (Phil Crosby)
• Striving for excellence in reliability & functions by continuousStriving for excellence in reliability & functions by continuous
improvement in the process of development, supported by statisticalimprovement in the process of development, supported by statistical
analysis of the causes of failure (Edwards Deming)analysis of the causes of failure (Edwards Deming)
• Achieving excellent levels of fitness for use, conformance toAchieving excellent levels of fitness for use, conformance to
requirements, reliability & maintainability (Watts Humphrey)requirements, reliability & maintainability (Watts Humphrey)
• Software quality means being on time, within budget and meeting userSoftware quality means being on time, within budget and meeting user
needs (James Martin)needs (James Martin)

• High levels of user satisfaction & low defect levels, often associatedHigh levels of user satisfaction & low defect levels, often associated
with low complexity (Tom McCabe)with low complexity (Tom McCabe)
• Quality means low defect levels, adherence of software functions toQuality means low defect levels, adherence of software functions to
users needs, & high reliability (John Musa)users needs, & high reliability (John Musa)
• High levels of user satisfaction & adherence requirements (Bill Perry)High levels of user satisfaction & adherence requirements (Bill Perry)
• Quality consists of freedom from deficiencies (Juran)Quality consists of freedom from deficiencies (Juran)
• Conformance to explicitly stated functional and performanceConformance to explicitly stated functional and performance
requirements, explicitly documented development standards, andrequirements, explicitly documented development standards, and
implicit characteristics that are expected of all professionallyimplicit characteristics that are expected of all professionally
developed software (Pressman)developed software (Pressman)
Quality defines by various software quality specialists:Quality defines by various software quality specialists:

Why is quality important?Why is quality important?
•A competitive issueA competitive issue
Differentiate your product from your competitorsDifferentiate your product from your competitors
Customer want to be assured of qualityCustomer want to be assured of quality
Businesses would give prime consideration toBusinesses would give prime consideration to
qualified developerqualified developer
•An issue for survivalAn issue for survival
•Quality is cost-effectiveQuality is cost-effective
Lead to increased productivityLead to increased productivity
Permanently reduced costsPermanently reduced costs
•Retaining customer & increasing profitsRetaining customer & increasing profits
•The sign of global businessThe sign of global business

Cost of
software
quality
Prevention
costs
(Evaluate)Appraisal
costs
Internal
failure costs
External
failure costs
Costs of
Control costs
Costs of
Failure of
control costs

a. Investments in development of SQA infrastructure components
* Procedures and work instructions
* Support devices: templates, checklists etc
* Software configuration management system
* Software quality metrics
b. Regular implementation of SQA preventive activities:
* Instruction of new employees in SQA subjects
* Certification of employees
* Consultations on SQA issues to team leaders and others
c. Control of the SQA system through performance of:
* Internal quality reviews
* External quality audits
* Management quality reviews

(a) Costs of reviews:
* Formal design reviews (DRs)
* Peer reviews (inspections and walkthroughs)
* Expert reviews
(b) Costs of software testing:
* Unit, integration and software system tests
* Acceptance tests (carried out by customers)
(c) Costs of assuring quality of external participants

* Costs of redesign or design corrections subsequent to
design review and test findings
* Costs of re-programming or correcting programs in
response to test findings
* Costs of repeated design review and re- testing
(regression tests)

Typical external failure costs cover:
* Resolution of customer complaints during the warranty period.
* Correction of software bugs detected during regular operation.
* Correction of software failures after the warranty period is over even if the
correction is not covered by the warranty.
* Damages paid to customers in case of a severe software failure.
* Reimbursement of customer's purchase costs.
* Insurance against customer's claims.
Typical examples of hidden external failure costs:
* Reduction of sales to customers that suffered from software failures.
* Severe reduction of sales motivated by the firm's damaged reputation.
* Increased investment in sales promotion to counter the effects of past software
failures.
* Reduced prospects to win a tender or, alternatively, the need to under-price to
prevent competitors from winning tenders.

Cost of
software
quality
Prevention costs
Appraisal costs
Internal failure
costs
External failure
costs
Costs of
Control costs
Costs of
Failure of
control costs
Managerial
preparations
and control costs
Managerial
failure costs

* Costs of carrying out contract reviews
* Costs of preparing project plans, including quality plans
* Costs of periodic updating of project and quality plans
* Costs of performing regular progress control
* Costs of performing regular progress control of external
participants’ contributions to projects

* Unplanned costs for professional and other resources,
resulting from underestimation of the resources in the
proposals stage.
* Damages paid to customers as compensation for late
project completion, a result of the unrealistic schedule in
the Company’s proposal.
* Damages paid to customers as compensation for late
completion of the project, a result of management’s
failure to recruit team members.
* Domino effect: Damages to other projects planned to be
performed by the same teams involved in the delayed
projects. The domino effect may induce considerable
hidden external failure costs.

Software quality assurance is:
1. A planned and systematic pattern of all actions
necessary to provide adequate confidence that an
item or product conforms to established technical
requirements.
2. A set of activities designed to evaluate the process
by which the products are developed or
manufactured. Contrast with: quality control.

Software Quality Control Vs. Software Quality AssuranceSoftware Quality Control Vs. Software Quality Assurance
Quality ControlQuality Control Quality AssuranceQuality Assurance
A set of activities to evaluate the quality of
a developed or manufactured product,
withholding(avoiding) of any product that
does not qualify
Minimize the cost of guaranteeing quality
by a variety of activities performed
throughout the development &
manufacturing processes
Corrective (Reactive) Prevention (Proactive)
Operational Strategic
Take place as the development or
manufacturing of the product is completed
Take place throughout the development &
manufacturing process
Confidence to producer Confidence to customer
Find defects (corrective) Prevent defects (preventive)
e.g.: walkthrough; inspection; checkpoint
review
e.g.: defining processes; quality audit;
selection of tools; training

(1) Assuring an acceptable level of confidence that the
software will conform to functional technical
requirements.
software will conform to managerial scheduling and
budgetary requirements.
(3) Initiation and management of activities for the
improvement and greater efficiency of software
development and SQA activities.

software maintenance activities will conform to the
functional technical requirements.
software maintenance activities will conform to
managerial scheduling and budgetary requirements.
(3) Initiate and manage activities to improve and increase
the efficiency of software maintenance and SQA
activities.

SQA & Software EngineeringSQA & Software Engineering
• Software engineering (by IEEE)
– The application of a systematic, disciplined,
quantifiable approach to the development, operation
& maintenance of software; that is, the application of
engineering to software
• SE, a good infrastructure for achieving SQA
activities
• Cooperation between SE & SQA allow the
achievement of efficient, economic development,
maintenance activities, & assure the quality of the
product

• Being contracted
• Subjection to customer-supplier relationship
• Requirement for teamwork
• Need for cooperation and coordination with other
development teams
• Need for interfaces with other software systems
• Need to continue carrying out a project while the team
changes
• Need to continue maintaining the software system for
years

1. Contractual Conditions: an agreement between software
developer and the customer, need to cope with customer’s
functional requirements; project budget & timetable
2. Subjection to Customer-supplier relationship: activities are
under the oversight of the customer, continuous cooperation
needed between software developer and customer
3. Required teamwork: Time table requirements, need for
variety of specializations, wish to benefit from professional
mutual support & review
4. Cooperation & coordination with other software teams:
cooperation with other teams especially for large-scale projects

5. Interfaces with other software systems: to allow data in
electronic form to flow between different software system
6. Need to continue carrying out a project despite team
member changes: the leader has to replace the leaving
members by another employee or new recruit even though
training needed for the new personnel
7. Need to continue carrying out software maintenance for an
extended period: maintenance needed for customer;
maintenance needed for software that has been developed in-
house as well

Reviews
1. Which SQA environment characteristic affect mainly the
professional (developers) side? Justify your answer(s).
2. Which SQA environment characteristic affect mainly the
managerial side? Justify your answer(s).

Case Studies
The interfaces of a salary processing system are shown in the next slide.
1. Suggest what are the main benefits of applying computerized interfaces
of transferring printouts.
2. Give another example (system) where input interface is applied.
3. Give another example (system) where output interface is applied.
4. Would you advise all information transfers from one organization to
another be performed by computerized interface? Justify your answers.

Salary
processing
system
Attendance
control
system
Bank
information
systems
Money transfers to employees’
bank account accounts
Monthly attendance report,
including overtime calculations
Input interface
Output interface

Lect1 fault+quality

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Lect1 fault+quality

Similar to Lect1 fault+quality (20)

Recently uploaded

Recently uploaded (20)

Lect1 fault+quality