2. What is SQA?
Software Quality Assurance is simply a way to assure to quality in
the software.
3. Where to use SQA??
Software quality assurance is a process which works parallel to
development of software.
4. Why organizations ignore it?
• They think it is time consuming process.
• They think it increase the cost of system
5. How SQA is beneficial?
• SQA produce high quality projects those are beneficial.
• High quality applications means short time development.
• High quality applications saves time and cost.
• Better reliability and no maintenance for long time.
• High quality commercial software increase market share of
company.
6. Introduction to Software Quality:
• Reasonably bug or defect free.
• Is delivered in time.
• Within the specified budget.
• Meets the requirements.
• Is maintainable.
7. Software quality reflects
both Functional quality as well
as Structural quality.
• Software Functional Quality − It reflects how well it satisfies a
given design, based on the functional requirements or
specifications.
• Software Structural Quality − It deals with the handling of
non-functional requirements that support the delivery of the
functional requirements, such as robustness or
maintainability, and the degree to which the software was
produced correctly.
8. ISO 9000 in Software
ISO stand for the international standardization organization.it is
an organization which standardize the things on international
level so thing becomes easy to judge.
9. IS0 9000
• ISO 9000 is a family of quality based standards by ISO.
• This ISO 9000 family consists of a 5 family members of ISO
9000 to 9004.
• All these five members are targeting the quality from different
perspective and they are applicable to diff things and diff
fields of life.
• No one family member of ISO 9000 is specific to any particular
product.
10. ISO 9000 Family Members
ISO Standards Description of Standards
ISO-9000 Tells detail about 9000,1,2,3 which one is best for you.
ISO-9001 Deals with quality assurance in design, development, installation
and maintenance.
ISO-9002 Assesses the production and installation process.
ISO-9003 Evaluation of inspection and test phase.
ISO-9004 It defines about 20 concepts about the quality which are used in
the above three standards 9001,9002,9003.
11. ISO 9001
• It deals with the quality assurance in design, development,
production, installation and servicing.
• The all above mentioned things of ISO 9001 are related to
software industry so we choose it the most in software
Industry.
• From the family of ISO 9000 the family member ISO-9001
relates the most to Software Industry.
12. When to use ISO 9000
• When an organization want to regulate the quality system in
the organization so they choose one of the family member of
ISO 9000 which relates most with their organization.
Example:In our example if we are software industry then to regulate the quality
system in our industry we will choose the ISO 9001as it relates the most to our
software industry.
13. Examples:
• ISO 13485 – Medical devices.
ISO 17582 – Electoral organizations at all
levels of government.
ISO 18091 – Local government.
ISO/TS 22163 – Business management system
requirements for rail organizations.
ISO/TS 29001 – Petroleum, petrochemical and
natural gas industries.
ISO/IEC 90003 – Software engineering.
14. CMMI
Capability Maturity Model Integration (CMMI) is a process
improvement model which helps organization improve their
performance.
There are five different maturity levels defined by CMMI.
Level1:Initial
Level 2:Managed
Level 3:Defined
Level 4:Quantitaively Managed
Level 5:Optimizing
15. Inspection
• Inspections are critical examinations of software artifacts by
human inspectors.
• The purpose behind this inspection is to discovering and fixing
the faults in software.
• Inspection is non –testing way to eliminate the faults from
software.
• Requirement Inspection
• Design Inspection
• Code Inspection
• Test Case Reviews
• User Documentation Reviews
16. Inspection Process
• Planning: The inspection is planned by the moderator.
• Overview meeting: The author describes the background of
the work product.
• Preparation: Each inspector examines the work product to
identify possible defects.
• Inspection meeting: During this meeting the reader reads
through the work product, part by part and the inspectors
point out the defects for every part.
• Rework: The author makes changes to the work product
according to the action plans from the inspection meeting.
• Follow-up: The changes by the author are checked to make
sure everything is correct.
17. Inspection Roles
During an inspection the following roles are used.
• Author: The person who created the work product being
inspected.
• Moderator: This is the leader of the inspection. The
moderator plans the inspection and coordinates it.
• Reader: The person reading through the documents, one item
at a time. The other inspectors then point out defects.
• Recorder/Scribe: The person that documents the defects that
are found during the inspection.
• Inspector: The person that examines the work product to
identify possible defects.
18. Formal Technical Review
• Formal technical review (FTR) is a software quality control
activity performed by software engineers (and others).
• The objectives of an FTR are:
– (1) To uncover errors in function, logic, or implementation for
any representation of the software;
– (2) To verify that the software under review meets its
requirements;
– (3) To ensure that the software has been represented according
to predefined standards
– (4) To achieve software that is developed in a uniform manner;
– (5) To make projects more manageable. In addition, the FTR
serves as a training ground, enabling junior engineers to
observe different approaches to software analysis, design, and
implementation
• The FTR is actually a class of reviews that includes
walkthroughs and inspections
19. The Review Meeting
• Every review meeting should abide by the following
constraints:
– Between three and five people (typically) should be
involved in the review.
– Advance preparation should occur but should require no
more than two hours of work for each person.
– The duration of the review meeting should be less than
two hours. Given these constraints, it should be obvious
that an FTR focuses on a specific (and small) part of the
overall software.
– For example, rather than attempting to review an entire
design, walkthroughs are conducted for each component
or small group of components.
20. Review Summary Report
• What was reviewed?
• Who reviewed it?
• What were the findings and conclusions?
21. FTR Process
• Developer: The individual who has developed the work
product
– Informs the project leader that the work product is
complete and that a review is required.
• Review leader: Evaluates the product for readiness,
generates copies of product materials, and distributes
them to two or three reviewers for advance preparation.
• Reviewer(s): Expected to spend between one and two
hours reviewing the product, making notes, and
otherwise becoming familiar with the work.
• Recorder: A reviewer who records (in writing) all
important issues raised during the review.
