Untitled

MODULE 2: Software Quality Assurance

Objectives

• At the end of this chapter, the students should be able to:
  • Differentiate quality control from quality assurance.
  • Explain the different Software Quality Assurance (SQA) activities.
  • Estimate the quality of the software based on software quality metrics.

Software Quality Assurance (SQA)

• Definition: An umbrella activity that is applied throughout the software engineering process. It serves as an error-prevention technique focusing on the process of systems and software development.
• Characteristics:
  • Planned and systematic actions to ensure software quality.
  • Encompasses various methods: analysis, design, coding, testing, and tools.
  • Involves formal technical reviews applied during each software engineering step.
  • Employs a multi-tiered testing strategy.
  • Controls software documentation and changes made to it.
  • Ensures compliance with software development standards.
  • Features a measurement and reporting mechanism.
• Misconceptions:
  • SQA is not merely a software testing activity. Quality must be ingrained in the product before testing; if quality is absent prior, it will not be present post-testing.

Goals of SQA

1. To improve software quality by monitoring both the process and the product.
2. To ensure compliance with local standards for Software Engineering.
3. To ensure defects, process variance, or standards non-compliance are noted and rectified.

Scenario

A hired management role involves:

• Context: Managing a new product estimated at 25,000 lines of code with three to four team members over 18 months.
• Queries:
  1. What must be in place before the project starts?
  2. What quality checkpoints should be established?
  3. What measures to collect to determine the level of work quality?

Realities of SQA

1. SQA cannot incorporate quality into a product.
2. An existing SQA function does not guarantee quality.
3. Management's active involvement in SQA is necessary; otherwise, it becomes ineffective.
4. Close collaboration between SQA and development staff is essential for tangible benefits.

Quality Control vs. Quality Assurance

• Quality Control:
  • Focuses on work products.
  • Measures the product, identifies deficiencies, suggests improvements; results in product changes (e.g., code alterations).
  • Considered an error-removal technique.
• Quality Assurance:
  • Focuses on work processes.
  • Measures the processes, identifies deficiencies, suggests improvements; results in process changes (e.g., improved compliance).
  • The output from quality control often serves as input for quality assurance activities.

Software Quality Defined

• Conformance to:
  • Explicitly stated functional and performance requirements.
  • Explicitly documented development standards.
  • Implicit characteristics expected of professionally developed software.
• Alternative definition (W. Edwards Deming): Striving for excellence in reliability and functions through continuous process improvement, supported by statistical analysis of failure causes.

Three Important Points on Software Quality

1. Software requirements form the foundation from which quality is measured; lack of conformance to requirements indicates a lack of quality.
2. Specified standards guide software engineering practices; failure to follow these can lead to a lack of quality.
3. Implicit requirements may go unmentioned but are crucial (e.g., the need for maintainability).

Quality Characteristics

• Definition: Any property or element that can define a product's nature, including both physical or chemical properties such as size, weight, volume, color, or composition.

Characteristics of Software Quality

1. Achieved through a disciplined approach - called software engineering (SE).
2. Can be defined, described, and measured.
3. Can be assessed before any code is written.
4. Cannot be tested into a product.

Challenges in Software Quality

1. Defining quality.
2. Describing quality qualitatively.
3. Measuring quality quantitatively.
4. Achieving quality technically.

Design Analogy

• Design quality is similar to music; following rules enhances the outcome. Philip Crosby draws an analogy between quality and sex, emphasizing subjective perceptions of quality (e.g., Beethoven’s music vs. another's).

General Notions about Quality

1. Universal support for quality exists, except in certain situations.
2. Many believe they understand quality but resist explaining it.
3. Many think execution relies on natural inclinations.
4. Issues of quality are often deflected as someone else's fault.

Realizing Quality Through Abstract Quality Factors

• A set of quality factors defined as "the ilities":
  • Product Revision (Changing Software):
  1. Flexibility: Effort required to modify an operational program.
  2. Maintainability: Effort required to locate and fix an error in a program.
  3. Testability: Effort required to test a program to ensure it performs intended functions.
  • Product Transition (Modifying Software for Different Environments):
  1. Interoperability: Effort required to couple one system to another.
  2. Portability: Effort required to transfer a program across different environments.
  3. Reusability: Extent to which a program can be reused in different applications.
  • Product Operations (Using Software):
  1. Correctness: Degree to which a program meets specifications and mission objectives.
  2. Reliability: Consistency in performing intended functions under specified conditions.
  3. Efficiency: Resource consumption during function performance.
  4. Integrity: Security against unauthorized access.
  5. Usability: Ease of learning, operating, and interpreting software output.

Quality Metrics

• Auditability: Ease of verifying conformance to standards.
• Accuracy: Precision of computations and control; qualitative and quantitative assessment of error.
• Communication Commonality: Use of standard interfaces and protocols.
• Completeness: Full implementation of required functions; proper identification of data items.
• Conciseness: Compactness of code.
• Consistency: Uniform design and documentation techniques throughout the project.
• Data Commonality: Use of standard data structures.
• Error Tolerance: Damage when encountering an error; preventive and detection procedures in place.
• Execution Efficiency: Run-time performance assessments.
• Expandability: Extent to which designs can be extended.
• Generality: Applicability breadth of program components.
• Hardware Independence: Software decoupling from operating hardware.
• Instrumentality: Self-monitoring capability of the program.
• Modularity: Functional independence of program components.
• Operability: Ease of program operation.
• Robustness: Continuation of operation despite invalid inputs.
• Security: Protection mechanisms for programs and data.
• Self-documentation: Code providing meaningful documentation.
• Simplicity: Understandability of the program.
• Software System Independence: Independence from nonstandard programming features.
• Traceability: Ability to track components back to requirements.
• Training: Capabilities that enable new users to utilize the software.

Laws of Software Evolution Dynamics (by Belady and Lehman)

1. Law of Continuing Change: A usable program undergoes continuous change until more cost-effective to rewrite it.
2. Law of Increasing Entropy: System disarray increases over time unless maintained or reduced.
3. Law of Statistically-Smooth Change: Global system attributes may appear irregular, but are self-regulating with identifiable trends.

SQA Activities

1. Application of Technical Methods: Employing technical tools and methods enables better specification and design quality.
2. Conduct of Formal Technical Reviews (FTR): Reviews find defects in work products; outcomes potentially induce process changes.
   • Types of Reviews:
   1. Walk-through: Interactive process engaging participants to discuss unclear items.
   2. Inspection: Detailed review of each logical piece.
      • Requirements: Overview, participant preparation, inspection, rework and follow-up.
3. Software Testing: Activity aimed at error discovery in software.
4. Enforcement of Standards: Ensuring standards compliance.
5. Control of Change: Formalizing requests to manage change impacts.
6. Measurement: Tracking software quality impacts.
7. Record Keeping and Reporting: Procedures for collecting and disseminating SQA information.

Software Quality and Productivity: Role of Top Management

1. Create Constancy of Purpose: Aim for increased software quality and productivity for competitiveness.
2. Adopt New Philosophy: Embrace quality-focused methods over traditional, error-prone practices.
3. Cease Dependence on Conventional Methods: Require statistical evidence of quality to mitigate inspection needs.
4. End Lowest Cost Basis Awards: Demand quality along with price; eliminate non-compliant developers.
5. Find Problems: Continuous improvement in practices; fostering ongoing training and methodology advancement.
6. Institute Modern Training Methods: Employ rigorous training programs in software engineering and quality assurance.
7. Change Supervision: Shift focus from numbers to quality alongside metrics.
8. Drive Out Fear: Ensure an effective, fear-free working environment.
9. Break Down Barriers: Encourage interdepartmental collaboration among all project areas.
10. Create Management Structures: Direct control aligning with the above nine points to guide improvements effectively.