Software Quality Assurance Introduction

Software Quality Assurance By Eng. Hany Kadry

What Is a Software ?  IEEE Definition : Software is : computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system

   

Almost identical to ISO definition Computer programs ……… (“the code”) Procedures define the order and schedule Data necessary for operating the software system …… (“parameters, codes, …..”)  Documentations are needed for developers, users, maintenance personnel

The Nine Causes of Software errors      

Faulty requirements definition Client-developer communication failures Deliberate deviation from software requirements Logical design errors Coding errors Non-compliance with documentation and coding instructions  Shortcomings of the testing process  Procedure error  Documentation errors

Software Quality  Software quality is defined as : conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software

 Good software engineering practices (GSEP),

reflecting state-of-the-art professional practices, to be met by the developer even though not explicitly mentioned in the contract

Difference Between Quality Control and Quality Assurance  Quality control is defined as “a set of activities designed to evaluate

the quality of a developed or manufactured product” (IEEE), in other words activities whose main objective is the withholding of any product that does not qualify

 The main objective of quality assurance is to minimize the cost of

guaranteeing quality by a variety of activities performed throughout the development and manufacturing. These activities prevent the cause of errors, and detect and correct them early in the development process

 As a result, QA activities substantially reduce the rate of products that do not qualify for shipment, and at the same time, reduce the cost of guaranteeing quality in most cases

 QC activities are only a part of the total range of QA activities

SQA  Software quality assurance is :a systematic , planned set of actions necessary to provide adequate confidence that the software development process or the maintenance process of a software system product conforms to established functional technical requirements as well as with the managerial requirement of keeping the schedule and operating costs with the budgetary confines (ISO, CMM)

SQA System Overview

SQA System Architecture  An SQA system combines a wide range of SQA components

 The components are employed to challenge the

multitude of sources of SW errors and to achieve an acceptable level of SW quality

 Two considerations : Task of SQA is unique due to the specific characteristics of sw  The environment in which sw development and maintenance is undertaken directly influence of the SQA components

SQA System Components Classes  Components can be classified into six classes : Pre-project quality components  Project lifecycle quality components  Infrastructure error preventive and improvement components  Software quality management components  Standardization, Certification and SQA assessment components  Organizing for SQA – the human components

1- Pre-Project Components

1- Pre-Project Components  Objective is to assure that : (a) the project commitments have been adequately defined considering : The resources required  The schedule  The budget  (b) the development and quality plans have been correctly determined

…. Cont  These SQA components are meant to improve the preparatory steps prior to initiating work on the project itself : Contract review  Development and quality plans

Contract review  SW may be developed within a framework of :-

 A contract negotiated with a customer  Internal order originating in another department : Order of software product to be sold as a package  An internal software application to be used by the company

Contract review …. cont  In all instances, the development unit is committed to an agreed-upon :  

Functional specifications Budget schedule

….. cont  Accordingly, contract review activities must include a detailed examination of : (a)- The project proposal draft  (b)- the contract draft

…. cont  Contract review activities specifically include : Clarification of the customer’s requirements  Review of the project’s schedule and resource requirement estimates  Evaluation of the professional staff’s capacity to carry out the proposed project  Evaluation of the customer’s capacity to fulfill his obligations  Evaluation of development risks

Development and Quality Plans  Overview  Once the contract has been signed or a commitment has been made to undertake an internal project, a plan is prepared of the project (“development plan”) and its integrated quality assurance activities (“quality plan”)  These plans include additional details and needed revisions based on prior plans that provided the basis for the current proposal and contract Note : it is quite common for several months to pass between the tender submission and the signing of the contract

…. cont  The main issues treated in the development plan are :Schedules Required manpower and hardware resources Risk evaluations Organizational issues: team members, subcontractors and partnership  Project methodology , development tools, ..etc  Software reuse plans    

…. cont  The main issues treated in the project’s quality plan are : Quality goals, expressed in the appropriate measurable terms  Criteria for starting , and ending each project stage  List of reviews , tests, and other scheduled verification and validation activities

2- Software Project Lifecycle Components

2- Software Project Lifecycle Components  Project lifecycle is composed of two stages : The development lifecycle stage  The operation-maintenance stage

…. cont  Several SQA components enter the lifecycle at different points  They should be planned prior to project’s initiation. They are :    

Reviews Expert opinion Software testing Software maintenance Assurance of the quality of the subcontractor’s work and the customer-supplied parts

Reviews  The design phase produces a variety of documents :    

Design reports Software test documents Software installation plans Software manuals Others

 Reviews can be categorized into : Formal design reviews (DRs)  Peer reviews

Formal Design Reviews (DRs)  The committee:- senior professionals including :    

The project leader The department manager The chief software engineer Heads of other related departments

 The majority of participants hold

professional and administrative ranks higher than the project leader

The DRs  The DR report includes a list of required corrections (“action items”)  The committee has several options :-

 Immediate approval to continue to the next development phase  Approval to proceed after all action items have been completed and inspected by the committee representative  An additional DR is required and scheduled after all action items have been completed and inspected by the committee representative

Peer Reviews  Are directed at reviewing short, parts of a report, a coded printout of a software module

 The main objective is to detect as many design and programming faults as possible

Expert Opinions  Outside experts  Useful in the following situations : Insufficient in-house capabilities in a given area  In small organization, the expert can join the DR  Extreme work pressure  In case of major disagreement

Software Testing  Test cases that represent a variety of expected scenarios  All tests should be designed and planned and approved  Highly recommended to test by independent test unit rather than the project team  Tests can be manual or automated

Software Maintenance Components  Maintenance services fall into :  

Corrective maintenance Adaptive maintenance (ex: HW change) Functionality improvement maintenance (functionality, performance)

 Pre-maintenance components  Maintenance contract review  Maintenance plan

 Software development lifecycle components

3- Infrastructure Components

3- Infrastructure components For Error Prevention and Improvement

 The goals of SQA infrastructure are the

prevention or lowering the software faults rates  This class of components include :    

Procedures and work instructions Templates and checklists Staff training, retraining and certification Configuration management Documentation control

Procedures and Work Instructions

 QA procedures usually provide detailed

definitions for the performance of specific types of development activities in a way that assures effective achieving quality results

 The collection of all SQA procedures is

usually referred as the SQA procedures manual

Work Instructions  Work instructions deal with the application of procedures adapted to the requirements of a specific project team, customer, or other relevant party

 While general methodology is defined in a procedure, the specific details that allow its application to a specific project or unit are often laid out in a work procedure

Templates & Checklists  One way to combine higher quality with higher efficiency is to use supporting quality devices , such as templates and checklists

checklists  Checklist refers to the list of items specially constructed for each type of document, or menu of preparations to be completed prior to perform an activity

Staff Training, Instruction and Certification  Trained and well-instructed professional staff is the key to efficient , quality performance

 Within the frame of SQA , keeping an organization’s

human resources knowledgeable and updated at the level required is achieved by : Training new employees and retraining those who have changed assignments  Continuously updating staff with respect to professional developments  Certifying employees after their knowledge and ability have been demonstrated

Prevention & Corrective Actions  Systematic study of the data collected regarding instances of failure and success contribute to the QA :-

 Implementation of changes that prevent similar failures in the future  Correction of similar faults founds in other projects  Implementing proven successful methodologies to enhance the probability of repeat successes

 The source of data are design review reports, software test reports, and customer complaints…

Configuration Management  The regular software development and maintenance operations involve intensive activities that modify software to create new versions and releases  Different team members carry out these activities simultaneously  As a result serious dangers arise …!!  CM deals with these hazards by introducing procedures to control the change process

….. cont  CM procedures relate to :The approval of change The recording of the changes The issuing of new SW versions and releases The recording of the versions and releases specifications of SW installed in each site  The prevention of any changes in approved versions and releases once they are issued    

 Most CM systems implement computerized tools

Documentation Control  SQA requires the application of measures to ensure the efficient long-term availability of major documents related to software development (“controlled documents”)

 Controlled documents contain information

important to the long-term development and maintenance of the software system such as :  

SW test results Design review (DR) reports Problem reports

4- Management SQA Components

4-Management SQA Components  Supports the managerial control of software development projects and maintenance services. They include : Project progress control  SW quality metrics  SW quality costs

Project Progress Control  The main objective of project progress control is to detect the appearance of any situation that may induce deviations from the project’s plan and maintenance service performance. Project progress control activities focus on :   

Resource usage Schedules Risk management activities The budget

Software Quality Metrics  The measurements apply to the functional quality, productivity, and organizational aspects of the project  SW quality metrics are :   

Quality of SW development & maintenance activities Development team’s productivity Helpdesk and maintenance team’s productivity SW faults density

5- SQA Standards, System Certification, and Assessment Components

5- SQA Standards, System Certification, Assessment Components

 External tools offer another avenue to achieving the goal of SQA  The main objectives of this class of components are :-

 Utilization of international professional knowledge  Improvement of coordination with other organizations’ quality systems  Objective professional evaluation and measurement of the achievements of the organization’s quality systems

Standards available  The standards available may be classified into two main sub-classes :-

 Quality management standards :- focus on the “what” is required and leave the “how” to achieve it to the organization : SEI CMM assessment standard  ISO 9001 and ISO 9000-3 standards  Project process Standards :- methodological guidelines (dealing with the “how”) for the development team : IEEE 1012 standard  ISO/IEC 12207 standard

6- Organizing for SQA The Human Components

6- Organizing For SQA The Human Components  SQA cannot be applied in an organizational vacuum: they require an organizational base  The base (organizational SW quality framework) includes : Organization’s management  SQA Unit and SW testing personnel

Mission of The Organizational Base  Develop and support implementation of SQA components

 Detect deviations from SQA procedures and methodology

 Suggest improvements to the SQA components Note : although the entire organizational base shares these objectives, each segment of the organizational base concentrates on specific tasks

Management’s Role in SQA  The responsibilities of top management (through the executive in charge of SW quality), departmental management and project management include the following: Definition of the quality policy Effective follow-up of quality policy implementation Allocation of sufficient resources to the implementation of the quality policy  Assignment of adequate staff  Follow-up compliance   

The SQA Unit  This unit and SW testers devote their full time to SQA matters : Preparation of annual quality programs  Consultation with in-house staff and outside experts on SW quality issues  Conduct of internal QA audits  Support of existing quality assurance infrastructure components and their updates, and development of new components

Software Quality Metrics

Metrics Classifications  First classification distinguishes between the development lifecycle and other phases of a software system : Process metrics ……….. Development  Product metrics ……….. Maintenance

…. cont  The second classification category refers to the subject of the measurement :   

Quality Timetable Effectiveness (of error removal) productivity

Estimating the Software Size  KLOC (thousands of code lines)  Depends on the programming language

 FP (function points)  Does not depend on the programming language

Sizing … cont

Process Metrics  Process metrics categories :   

SW process quality metrics SW process timetable metrics Error removal effectiveness metrics SW process productivity metrics

The Function Point Method  It measures the project/program size by functionality not by KLOC (the number of code lines can only be counted after programming completion which occurs at a very late stage of the project)

Function Point Calculation



FP = CFP X (0.65 + 0.01 X RCAF)

 CFP = Crude Function Point  RCAF = Relative Complexity Adjustment Factor

Thank You