14 Quality Management Activities

QUALITY MANAGEMENT ACTIVITIES

 

Software quality management is split into three main activities as given below

 

1. Quality assurance
The development of a framework of organizational procedures and standards that
lead to high quality software.

2. Quality planning
The selection of appropriate procedures and standards from this framework and
adapt for a specific software project.

3. Quality control
Definition of processes ensuring that software development follows the quality
procedures and standards.

 

QUALITY ASSURANCE

 

Quality assurance (QA) is a way of preventing mistakes or defects in manufactured products and avoiding problems when delivering solutions or services to customers; which ISO 9000 defines as “part of quality management focused on providing confidence that quality requirements will be fulfilled”. This defect prevention in quality assurance differs subtly from defect detection and rejection in quality control, and has been referred to as a shift left as it focuses on quality earlier in the process. It deals with establishing organizational quality standards and procedures.

 

Software quality assurance

 

Software quality assurance (SQA) is a process that ensures that developed software meets and complies with defined or standardized quality specifications. SQA is an ongoing process within the software development life cycle (SDLC) that routinely checks the developed software to ensure it meets desired quality measures.

QUALITY PLANNING

 

Quality Planning is the process for “identifying which quality standards are relevant to the project and determining how to satisfy them”: Quality planning means planning how to fulfill process and product (deliverable) quality requirements: “Quality is the degree to which a set of inherent characteristics fulfill the requirements”. It focuses on selecting and modifying applicable quality standards and procedures for a particular project.

 

Software Quality Planning

 

Software quality planning is the process of developing a quality plan for a project. The quality plan defines the quality requirements of software and describes how these are to be assessed. The quality plan selects those organizational standards that are appropriate to a particular product and development process. Quality plan has the following parts:

 

1.      Introduction of product.

2.      Product plans.

3.      Process descriptions.

4.      Quality goals.

5.      Risks and risk management.

 

QUALITY CONTROL

 

Quality control provides monitoring the software development process to ensure that quality assurance procedures and standards are being followed. The deliverables from the software development process are checked against the defined project standards in the quality control process. The quality of software project deliverables can be checked by regular quality reviews and/or automated software assessment. Moreover, ensuring quality standards and procedures are followed by development team. Therefore, quality management should be separated from project management to ensure independence.

 

QUALITY STANDARDS

 

The main activity of the quality assurance process is the selection and definition of standards that are applied to the software development process or software product. There are two main types of standards. The product standards are applied to the software product, i.e. output of the software process. The process standards define the processes that should be followed during software development. The software standards are based on best practices and they provide a framework for implementing the quality assurance process.

The development of software engineering project standards is a difficult and time consuming process. National and international bodies such as ISO, Software engineering institute, ANSI and the IEEE developed standards that can be applied to software development projects. Organizational standards have developed by quality assurance teams and they are based on these national and international standards.

 

ISO

 

ISO 9000 is an international set of standards that can be used in the development of a quality management system in all industries. ISO 9000 standards can be applied to a range of organizations from manufacturing to service industries. ISO 9001 is the most general of these standards. It can be applied to organizations that design, develop and maintain products and develop their own quality processes. A supporting document (ISO 9000-3) interprets ISO 9001 for software development.

 

ISO 9000-3

 

The need for a special interpretation of ISO 9001 for software was noted quite early, and in 1998 ISO published a guide for this purpose. The guide is numbered ISO 9000-3, and its title is “Quality management and quality assurance standards – Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software (ISO 9000-3:1997”.

 

Even though ISO 9000-3 is a guideline and uses “should”, it has a special status. It is not any guideline; it is ISO’s own authorized guideline to the use of ISO 9001 with software. Thus, ISO 9000-3 is occasionally used as a requirement standard in the same manner as ISO 9001. In those cases, “should” is taken to mean “shall”. ISO 9000-3 is only one of many possible interpretations of ISO 9001 for software. It is possible to fulfill ISO 9001 without fulfilling every “should” in ISO 9000-3. However, if there is a “should” in ISO 9000-3, which the software developers do not fulfill, they should be prepared to explain to an auditor how you handle that issue instead, and why they still believe that they fulfill ISO 9001. ISO 9000-3 is organized in the same quality elements as ISO 9001.

Sometimes software engineers are frustrated with ISO 9001 and 9000-3. According to such software engineers, “ISO 9003 does not tell how to develop quality software”, they complain, quite rightly. It is important to notice, though, that ISO 9001 (and thus ISO 9000-3) was never intended as a help for the developers. The standard is solely aimed at being a tool for the customer. Basically, ISO 9001 makes the supplier implement basic management of software development, and the standard then enforces visibility, so that the customer can see what the developers are doing and judge it. In practice, ISO 9001 and 9000-3 can also be used as guides for the supplier’s management, helping them control development and gain insight into what is really going on.

The ISO 9001 standard isn’t specific to software development but includes general principles that can be applied to software development projects. The ISO 9001 standard describes various aspects of the quality process and defines the organizational standards and procedures that a company should define and follow during product development. These standards and procedures are documented in an organizational quality manual. The ISO 9001 standard does not define the quality processes that should be used in the development process. Organizations can develop own quality processes and they can still be ISO 9000 compliant companies. The ISO 9000 standard only requires the definition of processes to be used in a company and it is not concerned with ensuring that these processes provide best practices and high quality of products. Therefore, the ISO 9000 certification doesn’t means exactly that the quality of the software produced by an ISO 9000 certified companies will be better than that software from an uncertified company.

Documentation standards

 

Documentation standards in a software project are important because documents can represent the software and the software process. Standardized documents have a consistent appearance, structure and quality, and should therefore be easier to read and understand. There are three types of documentation standards:

     1.      Documentation process standards. These standards define the process that should be followed for document production.

2.      Document standards. These standards describe the structure and presentation of documents.

3.      Documents interchange standards. These standards ensure that all electronic copies of documents are compatible.

4.      They are the key to effective software quality management

5.      Product standards define the characteristics exhibited by all components (e.g. programming style issues)

6.      Process standards describe how a software process is to be implemented

7.      Should encapsulate best practices – this helps avoid repeating past mistakes

8.     They provide continuity by giving new team members a means to understand the organizational                 priorities

   Issues in documentation standards

 

It consists of issues on document identification standards, document structure standards, document presentation standards, document update standards and document Interchange Standards.

 

Document identification standards

 

How documents are labeled is the main concern.

 

Document structure standards

 

Organization of project documents are focused.

 

Document presentation standards

 

Fonts, styles, logos, etc. are considered.

 

Document update standards

 

Change control and version definitions are taken care of.

 

Document Interchange Standards

 

Allow documents produced on different computers, using different tools to be exchanged among team members.

 

The lifetime of many word processing systems is often less than the lifetime of the software being documented, document archival can be tricky.

 

Document interchange standards like XML are beginning to emerge as partial solutions to these problems.

PRODUCT STANDARDS

 

The product standards include the following:

  • Design review form
    • Document naming standards
    • Function prototype format
    • Programming style standards
    • Project plan format
  • Change request form

PROCESS STANDARDS

 

Process standards include the following items:

  • Design review guidelines
    • Document submission procedures
    • Version release process
    • Project plan approval procedure
    • Change control process
  • Test data recording procedures

PROBLEMS WITH STANDARDS

 

The standards are sometimes viewed by software engineers as neither up-to-date or relevant to the current project. They can involve lots of bureaucratic form completion and submission. Often they are not supported directly by software tools and this can mean lots of manual work to maintain standards.

 

Quality Standards Development

 

Quality Standards Development should involve practitioners in their development. Moreover, the engineers must understand the rationale behind each standard. Standards must be reviewed and revised regularly to avoid obsolescence and credibility problems with practitioners. Detailed standards need tool support to eliminate the “too much clerical work” excuse for not following the standards.

 

Process-Based Quality

 

Product quality is influenced by the quality of its production process. This relationship is easy to see in the manufacture of goods, it is more complex for software production because: The application of individual skills and experience is particularly important in software development external factors (e.g. application novelty or need to accelerate schedule) are more likely to impair quality.

 

Process Quality Overview

 

Determines the process standards to be used (e.g. review procedures, configuration management, etc.). Monitor the development process to ensure standards are being followed. Report process findings to project manager and customer.

 

Quality Plan

 

It identifies the most significant quality attributes appropriate for the product. Defines the assessment process in detail for each quality attribute. Indicates which organization standards should be applied and defines new standards as necessary.

 

Quality Plan Components

 

The following are the quality plan components:

  • Product introduction
  • Product plans
  • Process descriptions
  • Quality goals
  • Risks and risk management

Software Quality Attributes

 

The software quality attributes are safety, security, reliability, resilience, robustness, understandability, testability, adaptability, modularity, complexity, portability, usability, accessibility, reusability, efficiency and learn ability.

 

Data Collection

 

A good metrics program is based on a set of identifiable product and process data. Data should be collected immediately (not retrospectively). The analyst must use automatic data collection if possible. The analysis methods include: static product analysis, dynamic product analysis and process data collection.

Automated Data Collection

 

The Automated Data Collection system consists of Instrumented software system, Usage data and Fault data.

  •    Instrumented software system

Monitors added to software to record necessary data unobtrusively.

  •   Usage data

Capture user inputs and transactions.

  •   Fault data

Make use of electronic media to record faults as they are uncovered.

 

1.      Data Accuracy

 

The data collection should follow the following points:

  1. Don’t collect unnecessary data

Decide the questions to be answered in advance and only collect relevant data

  1. Tell people why data is being collected

Make sure people understand that the product and process are being evaluated (not the employees)

  1. Don’t rely on people’s memory

Collect data as it is being generated, not after a project is completed

 

SUMMARY

 

In order to maintain quality, reduce product defect injection rates during development. Moreover, improve support, usability, documentation, communication, or training. Finally, increase the sales of installed licenses (spreads same number of problems over more user months).