MELJUN_CORTES_JEDI Slides-1.3 Software Quality Assurance and Techniques

8/3/2019 MELJUN_CORTES_JEDI Slides-1.3 Software Quality Assurance and Techniques

1/25

Software Engineering 1

Introduction to Software

Engineering

Software QualityAssurance

Topic Three


2/25


Software Quality Assurance

It is a subset of software engineering.

It is ensuring that deliverables are meet and that theycomply with user requirements and standards.

It is considered an umbrella activity that is appliedthroughout the software development process.


3/25


4/25


Software Quality Assurance

It encompasses:

control of software documentation and the changesmade to it

a procedure to assure compliance with softwaredevelopment standards

measurement and reporting mechanism


5/25


Goal of Software Quality

Assurance To detect defects before the software is delivered as a final

product to the end-users who will directly use it.


6/25


Software Quality

It is a software that is fit to use, ie, it is working properly.

It meets users requirements. Requirements must bemeasurable in order to gauge compliance.

It is conformance to explicitly stated functional andperformance requirements, explicitly documenteddevelopment standards, and implicit characteristics that areexpected of all professionally developed software.


7/25


Three Important Points

Software Requirements are the foundation from whichquality is measured. It is necessary to explicitly specify andprioritize them.

Standards define a set of development criteria that guide themanner by which software is engineered.

Implicit requirements must be identified and documented;they influence the way software is developed such asmaintainability.


8/25


Well-engineered Software

Characteristics Usability It is the characteristic of the software that exhibits ease with which

the user communicates with the system.

Portability It is the capability of the software to execute in different platforms

and architecture.

Reusability

It is the ability of the software to transfer from one system to another.

Maintainability

It is the ability of the software to evolve and adapt to changes overtime. It is characterized by the ease of upgrading and maintaining.


9/25


Well-engineered Software

Characteristics Dependability It is the characteristic of the software to be reliable, secure and safe.

Efficiency

It is the capability of the software to use resource efficiently.


10/25


SQA Activities

Prepare the SQA Plan for a Project. This is done duringproject planning. It identifies the following:

evaluations to be performed

audits and reviews to be performed standards that are applicable

procedures for error reporting and tracking

documents to be produced

amount of feedback required


11/25


SQA Activities

The SQA Team prepares the SQA Plan.

The SQA Team participates in the development of theproject's software process description.

The SQA Team reviews software engineering activitiesemployed by the development team to check for compliancewith the software development process.

The SQA Team reviews work products to check forcompliance with defined standards.


12/25


SQA Activities

The SQA Team ensures that deviations in the softwareactivities and work products are handled based on definedstandard operating procedures.

The SQA Team reports deviations and non-compliance tostandards to the senior management or stakeholders.


13/25


Formal Technical Reviews It is a software quality assurance activity that is

performed by software engineers.

The objectives of FTR are:

To uncover errors in function, logic orimplementation for any representation of thesoftware

To verify that the software meets user requirements

To ensure that the software complies with definedstandards

To achieve software that is developed in a uniformmanner

To make projects manageable


14/25


Formal Technical Review

Methods Fagan's Inspection Method Walkthroughs


15/25


Fagan's Inspection Method

Inspection Procedural Rules

Inspections are carried out at a number of points in theprocess of project planning and systems development.

All classes of defects in documentation are inspected;not merely logic, specifications or function errors.

Inspection is carried out by colleagues at all levels ofseniority except the big boss.

Inspections are carried out in a prescribed list ofactivities.

Inspection meetings are limited to two hours.


16/25


Fagan's Inspection Method

Inspection Procedural Rules

Inspections are led by trained moderator.

Inspectors are assigned specific roles to increase

effectiveness. Checklists of questionnaires to be asked by the

inspectors are used to define the task to stimulateincreased defect finding.

Materials are inspected at a particular rate which hasbeen found to give maximum error-finding ability.

Statistics on types of errors are key, and used for reportswhich are analyzed in a manner similar to financialanalysis.


17/25


Fagan's Inspection Activities

Planning

A moderator is tasked to prepare a plan for theinspection. He decides:

Who are the inspectors and the roles they play When and where the inspection will take place

When to distribute the inspection materials

Overview

A 30 minute presentation for the inspectors. It can beomitted when the overall project is familiar.


18/25


Fagan's Inspection Activities Preparing

Inspectors work alone for about 1-2 hours. They willconcentrate on the roles given by the moderator anddiscover presumed defects in the documentation.

Meeting

The meeting is attended by all inspectors including themoderator.

The developer of the work product in question are

normally present to explain and defend it. No discussion as whether a purported defect is real is

allowed.

A defect list is produced.


19/25


Fagan's Inspection Activities

Rework

The defect list is assigned to one person for repair.

Follow-up

The moderator is personally responsible for ensuring thatdefects in documentation have really been reworked.

The correctness of the rework process is judged by laterinspections and tests.

Casual Analysis Meeting It can be held at which inspectors may express their

more personal views on error and improvements.


20/25


Walkthrough

It is technical review which is less formal that an inspection.

The work product is reviewed by a review team consisting of3 to 5 people.

A scribe is present to document the action list.


21/25


Walkthrough Guidelines

No manager should be present.

Emphasize that the walkthrough is for error detection onlyand not error correction.

Keep vested interest group apart. No counting or sandbagging.

Criticize the product; not the developer of the work product.

Always document the action list.


22/25


Pre-walkthrough Activities

Schedule walkthrough a day or two in advance.

Distribute appropriate materials to reviewers.

Ask each reviewer to bring to the walkthrough two positive

comments and one negative comments.


23/25


Walkthrough Activities

Presenter makes a brief presentation of the product.

Solicit comments from the reviewers.

Issues are presented but not resolved during the

walkthrough. Keep walkthrough to no more than one hour.

An action list is the final product of the walkthrough.


24/25


Post-walkthrough Activities

Chairperson gives the action list to the producer of the work.

The producer is then asked to submit a status report on theaction taken to resolve the errors or discrepancies listed inthe action list.

Another walkthrough may be scheduled.


25/25


Summary

Software Quality Assurance and Software Quality aredefined.

Software Quality Activities

Formal Technical Reviews Fagan's Inspection Method

Walkthrough

MELJUN_CORTES_JEDI Slides-1.3 Software Quality Assurance and Techniques

Documents

Transcript of MELJUN_CORTES_JEDI Slides-1.3 Software Quality Assurance and Techniques