Corrective and Preventive Actions

on Thursday, June 14, 2012
Systematic activities that implement organization-wide improvements of effectiveness and operational efficiency fall under the heading of corrective and preventive actions (CAPA). These are activities that are not intended to deal with immediate correction of detected defects but to eliminate the causes of those defects throughout software development departments.


ð  Corrective actions: A regularly applied feedback process that includes collection of information on quality non-conformities, identification and analysis of sources of irregularities as well as development and assimilation of improved practices and procedures, together with control of their implementation and measurement of their outcomes.
ð  Preventive actions: A regularly applied feedback process that includes collection of information on potential quality problems, identification and analysis of departures from quality standards, development and assimilation of improved practices and procedures, together with control of their implementation and measurement of their outcomes.

The Corrective And Preventive Actions Process

The process is regularly fed by the flow of information from a variety of sources. In order to estimate the success of the process, a closed feedback loop is applied to control the flow of information, implementation of the resulting changes in practices and procedures together with measurement of the outcomes.
The Corrective and Preventive Action Process

Information Collection

Internal Information Sources

Software development process
§  Software risk management reports
§  Design review reports
§  Inspection reports
§  Walkthrough reports
§  Experts’ opinion reports
§  Test reviews
§  Special reports on development failures and successes
§  Proposals suggested by staff members.
Software maintenance
§  Customer applications statistics
§  Software change requests initiated by customer applications
§  Software change requests initiated by maintenance staff
§  Special reports on maintenance failures and successes
§  Proposals suggested by staff members.
SQA infrastructure class of sources
§  Internal quality audit reports
§  External quality audit reports
§  Performance follow-up of trained and certified staff
§  Proposals suggested by staff members.
Software quality management procedures class of sources
§  Project progress reports
§  Software quality metrics reports
§  Software quality cost reports
§  Proposals of staff members.

External Information Sources

§  Customer complaints
§  Customer service statistics
§  Customer-suggested proposals.

Analysis Of Collected Information

Regular operation of the CAPA process is expected to create a massive flow of documents related to a wide range of information. Analysis involves:
·         Screening the information and identifying potential improvements.
·         Analysis of potential improvements :
a)       Expected types and levels of damage resulting from the identified fault.
b)       Causes for faults. Typical causes are non-compliance with work instructions and procedures, insufficient technical knowledge, extreme time and/or budget pressures due to unrealistic estimates, and lack of experience with new development tools.
c)       Estimates of the extent of organization-wide potential faults of each type. This information is needed to estimate the total damage expected and to determine the priority of each fault case.
·         Generating feedback on the content and regularity of information received from the designated information sources.

Development Of Solutions And Their Implementation

Development Of Solutions

Solutions to identified causes of recurrent software systems faults are required to:
ü  Eliminate recurrence of the types of faults detected
ü  Contribute to improved efficiency by enabling higher productivity and shorter schedules.
Several directions for solutions are commonly taken:
ü  Updating relevant procedures. Changes may refer to a spectrum of procedures, from those related to specific stages of software development or maintenance (e.g., changes in style of software comments, changes of contract review procedure in clauses dealing with proposals for small projects) to procedures of a general nature (e.g. changes of employee recruitment procedures, changes of the maximum and minimum number of participants in a formal design review).
ü  Changes in practices, including updating of relevant work instructions (if any exist).
ü  Shifting to a development tool that is more effective and less prone to the detected faults.
ü  Improvement of reporting methods, including changes in report content, frequency of reporting and reporting tasks.
ü  Initiatives for training, retraining or updating staff.

Implementation Of A Capa Process

Implementation of CAPA solutions relies on proper instructions and often training but most of all on the cooperation of the relevant units and individuals. Therefore, successful implementation requires that targeted staff members be convinced of the appropriateness of the proposed solution. Without cooperation, the contribution of a CAPA can be undermined.

Follow-Up Of Activities

Three main follow-up tasks are necessary for the proper functioning of a corrective and preventive action process in any organization:
a)       Follow-up of the flow of development and maintenance CAPA records from the various sources of information.
b)       Follow-up of implementation.
c)       Follow-up of outcomes.

Organizing For Preventive And Corrective Actions

Proper performance of these CAPA activities depends on the existence of a permanent core organizational unit as well as many ad hoc team participants, promotes the CAPA cause within the organization. Its tasks include:
ü  Collecting CAPA records from the various sources
ü  Screening the collected information
ü  Nominating entire ad hoc CAPA teams to attend to given subjects, or heading some of the teams
ü  Promoting implementation of CAPA in units, projects, etc.
ü  Following up information collection, data analysis, progress made by ad hoc teams and implementation as well as outcomes of improved CAPA methods.
A complementary group of potential participants, taken from regular staff, join CAPA efforts as members of ad hoc CAPA teams. They regularly focus on:
ü  Analysis of the information related to the team’s topic
ü  Initiation of additional observations and inquiries
ü  Identification of the causes for the faults
ü  Development of solutions and the relevant corrective and preventive actions
ü  Preparation of proposed implementation revisions
ü  Analysis of the CAPA implementation outcomes and CAPA revision if necessary.

Reference : CHAPTER 17 - Software Quality Assurance From Theory to Implementation's book by DANIEL GALIN.

Staff Training and Certification

on Wednesday, June 13, 2012

The Objectives Of Training And Certification

These objectives conform with the general goals of software quality assurance by inspiring management to persistently nurture the level of knowledge and skills displayed by staff and to improve their efficiency and effectiveness.
ü  To develop the knowledge and skills new staff need.
ü  To assure conformity to the organization’s standards for software products (documents and code).
ü  To update the knowledge and skills of veteran staff.
ü  To transmit knowledge of SQA procedures
ü  To assure that candidates for key positions are adequately qualified

The Training And Certification Process

All these activities converge into an integrated process in which feedback from past activities and information about professional developments stimulate a cycle of continuous training, certification and adaptation to changing quality requirements.
Training and certification activities are meant to fill the needs of veteran staff and new employees. Comprehensive follow-up of the outcomes of current programs as well as keeping track of developments in the profession are required to make sure that programs are adequately up-to-date.
The Training and Certification Process

Determining Professional Knowledge Requirements

The most common positions in a software development and maintenance organization are those of systems analyst, programmer, software development team leader, programming team leader, software maintenance technician, software tester, and software testing team leader.
This specialized knowledge can be grouped into two categories:
ð  Knowledge and skills of software engineering topics, such as software development tools, programming language versions, and CASE tool versions applied by the specific organization or unit.
ð  Knowledge of SQA topics, such as the procedures pertaining to the various development and maintenance activities, assigned to be performed by the individual occupying a specific position.

Determining Training And Updating Needs

The type of training is adapted to the needs of three distinct groups of staff:
         Training: for new employees, according to their designated assignment
         Retraining: for employees assigned to new positions or receiving new assignments
         Updating: for staff members as demanded by their position.

Planning Training And Updating Programs

ü  Planning training and updating programs for software engineering topics
Updating activities can be scheduled well ahead (the audience is known), with contents finalized close to the date of their implementation. Irrespective of whether the programs are carried out in-house or by an outsourcing organization, high-level staff, such as the chief software engineer, usually participate in their preparation.
ü  Planning training and updating programs for SQA topics
Training programs for SQA topics include training for new employees as well as updating for veteran staff members. The general characteristics of SQA training programs allow them to be organized periodically, every one or two months, and delivered to all new staff recruited in the interim.

Defining Positions Requiring Certification

Commonly accepted that assignment of personnel to key positions in software development and maintenance organizations requires extreme care. Examples of positions frequently requiring certification of their occupants are software development team leader, programming team leader, software testing team leader, software maintenance technician and internal quality auditor.
A certification committee (or a designated senior staff member) defines the list of positions that require certification and whether the certification will be effective permanently or for a limited period. Considering the volatility of the profession, this list should be revised periodically. Renewal of limited period certification demands that staff members demonstrate up-to-date knowledge and skills according to the current certification requirements.

Planning The Certification Processes

Certification is intended to provide a framework for the thorough investigation of a candidate’s qualifications and a demonstration of his or her professional knowledge and skills.  The certification process, in every detail and for every position, requires approval as defined in the certification procedure.

Typical Certification Requirements

§  Professional education: academic or technical degrees and in some cases certification by a professional organization or by a leading commercial software producer
§  Internal training courses
§  Professional experience in the organization (may be partially or completely replaced by experience in other organizations)
§  Assessment of achievements and ability as noted in periodic performance appraisals
§  Evaluation by the candidate’s direct superior (often by completion of a special questionnaire)
§  Demonstration of knowledge and skills by means of a test or a project
§  Mentor’s supervision for a specified period of time.

Functions Of The Certification Committee

§  To perform the certification process on the basis of requests made by individual applicants or units and grant certification to those who qualify
§  To follow up certification activities (such as mentoring) carried out by others
§  To update certification requirements in response to developments in the organization as well as the profession
§  To revise the list of positions requiring certification.

Delivery Of Training And Certification Programs

Training and updating can cover topics such as software engineering, software quality assurance and management skills (within the framework of certification or for general information), all of which are coordinated with the organization’s or firm’s needs.

Follow-Up Subsequent To Training And Certification

Systematic follow-up is necessary to provide feedback to the professional units. Such feedback indicates whether the training efforts were justified at the same time that it assures continuous improvement of training and certification activities. The information provided by follow-up relates to:
ü  All training activities and certification procedures conducted – records of the performance of the participants in the program.
ü  Information about special cases of training activities that proved to be either highly successful or clearly unsuccessful in improving staff performance.
ü  Information about proven cases of failures of certified staff in the performance that point to clearly inadequate certification requirements.

Reference : CHAPTER 16 - Software Quality Assurance From Theory to Implementation's book by DANIEL GALIN.

Software Testing

Software testing was the first software quality assurance tool applied to control the software product’s quality before its shipment or installation at the customer’s premises. Testing is certainly not the only type of SQA tool applied to software code. Additional tools are code inspections and code walkthroughs, methods implemented on code printout without actually running the program. These procedures, which are similar to those applied in design inspection and walkthroughs, yield good results in identifying code defects. Nevertheless, these tools, because they are based solely on the review of documents, can never replace testing, which examines the software product’s functionality in the form actually used by the customer.

Definition And Objectives

Definition :
Software testing is a formal process carried out by a specialized testing team in which a software unit, several integrated software units or an entire software package are examined by running the programs on a computer. All the associated tests are performed according to approved test procedures on approved test cases.

Objectives :
Direct objectives
·         To identify and reveal as many errors as possible in the tested software.
·         To bring the tested software, after correction of the identified errors and retesting, to an acceptable level of quality.
·         To perform the required tests efficiently and effectively, within budgetary and scheduling limitations.
Indirect objective
ü  To compile a record of software errors for use in error prevention (by corrective and preventive actions).

Software Testing Strategies

From the picture above, illustrates top-down and bottom-up testing of an identical software development project composed of 11 modules.
For bottom-up testing, in four stages, as follows:
ð  Stage 1: Unit tests of modules 1 to 7.
ð  Stage 2: Integration test A of modules 1 and 2, developed and tested in stage 1, and integrated with module 8, developed in the current stage.
ð  Stage 3: Two separate integration tests, B, on modules 3, 4, 5 and 8, integrated with module 9, and C, for modules 6 and 7, integrated with module 10.
ð  Stage 4: System test is performed after B and C have been integrated with module 11, developed in the current stage.
For top-down testing, in six stages, as follows:
ð  Stage 1: Unit tests of module 11.
ð  Stage 2: Integration test A of module 11 integrated with modules 9 and 10, developed in the current stage.
ð  Stage 3: Integration test B of A integrated with module 8, developed in the current stage.
ð  Stage 4: Integration test C of B integrated with modules 6 and 7, developed in the current stage.
ð  Stage 5: Integration test D of C integrated with modules 1 and 2, developed in the current stage.
ð  Stage 6: System test of D integrated with modules 3, 4 and 5, developed in the current stage.

Bottom-Up Versus Top-Down Strategies

The main advantage of the bottom-up strategy is the relative ease of its performance, whereas the main disadvantage is the lateness at which the program as a whole can be observed (that is, at the stage following testing of the last module).
The main advantage of the top-down strategy is the possibilities it offers to demonstrate the entire program functions shortly after activation of the upper-level modules has been completed. In many cases, this characteristic allows for early identification of analysis and design errors related to algorithms, functional requirements, and the like.
 The main disadvantage of this strategy is the relative difficulty of preparing the required stubs, which often require very complicated programming. Another disadvantage is the relative difficulty of analyzing the results of the tests.

Software Test Classifications

Software tests may be classified according to the testing concept or to the requirements classification in effect :
ü  Classification according to testing concept :
Black box (functionality) testing.
(1)     Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions.
(2)     Testing conducted to evaluate the compliance of a system or component with specified functional requirements.
White box (structural) testing.
Testing that takes into account the internal mechanism of a system or component.

ü  Classification according to requirements
McCall’s classic model has been extended here to the classification of the tests carried out to ensure full coverage of the respective requirements.

Reference : CHAPTER 9 - Software Quality Assurance From Theory to Implementation's book by DANIEL GALIN.

Supporting Quality Devices

on Sunday, June 10, 2012

Supporting Quality Devices

One way to combine higher quality with higher efficiency is to use supporting quality devices, such as template and checklists as common reporting tasks. These devices based as they are accumulated knowledge and experience of the organization’s development and maintenance professionals. With supporting quality devices, contribute the SQA goals :
ð  Saving the time required to define the structure of the various documents or prepare lists of subjects to be reviewed.
ð  Contributing to the completeness of the documents and reviews.
ð  Improving communication between development team and review committee members by standardizing documents and agendas.


Definition :
·         Template is “a gauge, pattern or mold (as a thin plate or board) used as a guide to the form of a piece being made” (Webster’s New College Dictionary).
Template refers to a format (especially tables of contents) created by units or organizations, to be applied when compiling a report or some other type of document.
A comprehensive collection of templates was developed by the US Department of Defense for use with documents to be completed by software development contractors according to the military standard. The standart use DID (Data Item Description) that provide the very detailed tables of contents suitable for the documentation required in the large-scale software development contracts typical of military projects.
Example of templates :
Example of Template - The Software Test Plan

The contribution of templates to software quality

For development teams:
ü  Facilitates the process of preparing documents.
ü  Documents prepared by developer are more complete.
ü  Provides for easier integration of new team members.
ü  Facilitates review of documents.
For software maintenance teams:
ü  Enables easier location of the information.

Sources for Updating Templates

Organizations tend to save their internal resources, which often means employing successful reports prepared for one department or purpose as models for the entire organization.
The decision to update an existing template may be considered a reactive measure, these are the sources for updating templates :
ð  User proposals and suggestions.
ð  Changes in the organization's areas of activity.
ð  Proposals initiated by design review and inspection teams.
ð  Analysis of failures as well as successes.
ð  Other organizations' experience.
ð  SQA team initiatives


The checklist used by software developers refers to the list of items specially constructed for each type of document, or a menu of preparations to be completed prior to performing an activity (e.g., installing a software package at the customer site).
Some checklists have dual purposes: while providing a complete list of items to be verified, they also provide space for documenting findings of the checks performed.
Example :
Proposal draft reviews – Subjects checklist

The contribution of checklists to software quality

Checklists provide many benefits to development teams, software maintenance teams and document quality.
For development teams :
ü  Helps developers carrying out self-checks of documents or software code
ü  Assists developers in their preparations for tasks
For review teams :
ü  Assures completeness of document reviews by review team members
ü  Facilitates improves efficiency of review sessions

Reference : CHAPTER 15 - Software Quality Assurance From Theory to Implementation's book by DANIEL GALIN.