SWE3

Software Engineering

  • Vinaya Sathyanarayana

Quality Concepts

What is Quality?

  • According to the American Heritage Dictionary, quality is defined as "a characteristic or attribute of something."

  • In software, three distinct types of quality can be recognized:

    • Quality of Design: This pertains to requirements, specifications, and the design of the system.

    • Quality of Conformance: This focuses primarily on the implementation aspect.

    • User Satisfaction: Achieved through a compliant product paired with good overall quality, ensuring delivery within budget and on schedule.

Quality – Pragmatic Views

Quality can be viewed through different perspectives:

  • Transcendental View: Quality is an aspect one recognizes intuitively but cannot define explicitly.

  • User View: Quality is measured by how well a product meets an end-user's needs and goals.

  • Manufacturer’s View: It revolves around ensuring that a product matches its original specifications.

  • Product View: Quality is linked to inherent product characteristics, such as functions and features.

  • Value-based View: Quality is assessed based on how much a customer is willing to pay.

  • Overall, quality encompasses all these views and potentially more.

Software Quality

  • Software quality is defined as an effective software process that ultimately creates a useful product, delivering measurable value to producers and users alike.

  • Advantages of Providing Useful Products:

    1. Greater revenue from software products.

    2. Enhanced profitability when applications support business processes.

    3. Improved information availability, crucial for business operations.

Software Quality – Effective Process

  • An effective software process includes establishing an infrastructure that supports the development of high-quality software.

  • Management aspects introduce necessary checks and balances to avoid project chaos, which could lead to poor quality.

  • Software engineering practices enable developers to analyze challenges and create solid designs as critical components of high-quality software.

  • Umbrella activities, such as change management and technical reviews, significantly influence quality.

Software Quality – Useful Product

  • A useful software product delivers the desired content, functions, and features reliably and with minimal errors.

  • It meets the requirements explicitly stated by stakeholders and satisfies certain implicit expectations of high-quality software.

Software Quality – Adding Value

  • High-quality software benefits both the producer and user, thereby adding value.

  • For the software organization: High-quality ensures lower maintenance, fewer bug fixes, and reduced customer support demands.

  • For users: It provides capabilities that enhance and expedite business processes.

McCall’s Quality Factors

  • [Details can be provided in the next sections.]

Quality in Use – ISO 25010:2017

The key quality characteristics include:

  • Effectiveness: Achieving goals with accuracy and completeness.

  • Efficiency: Resources utilized to achieve outcomes with optimal accuracy.

  • Satisfaction: Users’ feelings of usefulness, trust, pleasure, and comfort.

  • Freedom from Risk: Mitigation of economic, health, safety, and environmental risks.

  • Context Coverage: Completeness and flexibility.

Product Quality – ISO 25010:2017

Software product quality encompasses:

  • Functional Suitability: Completeness, correctness, and appropriateness.

  • Performance Efficiency: Timing, resource usage, and capacity.

  • Compatibility: Coexistence and interoperability with other systems.

  • Usability: Learnability, operability, error protection, aesthetics, and accessibility.

  • Reliability: Maturity, availability, and fault tolerance.

  • Security: Confidentiality, integrity, and authenticity.

  • Maintainability: Reusability, modifiability, and testability.

  • Portability: Adaptability, installability, and replaceability.

Qualitative Quality Assessment

  • This focuses on comprehensive application quality dimensions and can serve as a generic assessment tool.

  • Teams can create user questionnaires and structured tasks for users to assess quality factors.

  • Observational studies can be conducted during user task performance, complemented by post-task questionnaires.

  • Certain factors should be tested in actual production environments.

Quantitative Quality Assessment

  • The software engineering community aims to develop precise quality measures.

  • Internal code attributes can be quantified through software metrics.

  • Metrics are indirect measures that signal potential quality problems when out of acceptable ranges.

Software Quality Dilemma

  • Producing software of poor quality results in market rejection and revenue loss.

  • Conversely, overly perfect software leads to excessive costs and project delays, risking business viability.

  • The challenge lies in achieving a balance where the product is good enough for market acceptance without succumbing to perfectionism.

Good Enough Software

  • Arguments against "good enough" software:

    • While it may work in some contexts, delivering buggy products can notoriously harm small companies’ reputations and customer retention.

    • In critical domains like real-time embedded systems, "good enough" can be viewed as negligence, leading to potential litigation.

Cost of Quality

Quality-related costs categorize into:

  • Prevention Costs: Quality planning, training, and technical reviews.

  • Appraisal Costs: Testing, metrics collection, and evaluations.

  • Internal Failure Costs: Rework and repairs.

  • External Failure Costs: Customer support, returns, and warranty work.

Negligence and Liability

  • When a government or corporation enlists software services, expectations are typically high.

  • Delays, errors, or failures post-delivery can lead to significant customer dissatisfaction and potential litigation.

Quality, Risk, and Security

  • Low-quality software elevates risks for both developers and users, resulting in litigation if projects miss deadlines or fall short in functionality.

  • Additionally, low-quality software presents security vulnerabilities, necessitating a quality-first approach during design phases.

Impact of Management Decisions

  • Poor estimation of delivery timelines often leads to developers cutting corners, compromising quality.

  • Schedules that neglect task interdependencies can result in greater quality issues.

  • Risk management that only reacts to crises, rather than proactively addressing issues, may lessen quality outcomes.

Achieving Software Quality 1

  • Good project management and solid engineering practices contribute significantly to software quality.

  • High-quality software development begins with understanding the problem and creating a design that meets requirements.

  • Project planning includes quality and change management techniques, achievable estimations, and thorough risk planning.

Achieving Software Quality 2

  • Explicit quality management techniques should be integrated into the project plan.

  • It includes inspections and tests to ensure product specifications are met.

  • Quality assurance involves auditing processes to give management the data to make informed decisions.

  • Predictive defect modeling can aid in anticipating products that may face quality challenges.

Reviews

  • Reviews are technical assessments involving team members to enhance work products and assure quality.

  • They should not serve as mere project summaries but as constructive evaluations.

Formal Technical Reviews

Objectives include:

  1. Detecting errors in implementation and logic.

  2. Ensuring software aligns with requirements.

  3. Confirming representation according to standards.

  4. Achieving uniform software development practices.

  5. Enhancing project manageability.

Review Meeting

  • Optimal review groups involve three to five participants, with a maximum two-hour limit for meetings.

  • Focus is directed towards tangible work products.

Review Players

  • Producer: Author of the work product.

  • Review Leader: Facilitates review, prepares materials.

  • Reviewer(s): Engage in reviewing and take notes.

  • Recorder: Documents critical issues and responses during the review.

Review Outcome

Post-review, attendees should decide to:

  1. Accept the product as-is.

  2. Reject it due to critical errors needing further review.

  3. Provisionally accept with minor corrections required.

Review Reporting and Record Keeping

  • A review summary report should detail the reviewed product, participants, and findings.

  • An effective follow-up procedure ensures that all noted issues are resolved satisfactorily.

Review Guidelines

Key principles include:

  • Focus the review on the product, not the individual.

  • Maintain an agenda and manage time efficiently.

  • Record important observations and decisions made during review processes.

Postmortem Evaluations

Postmortem evaluations aim to analyze the entire project phase, extracting lessons learned from successes and challenges for future improvements.

Agile Reviews

In Agile methodologies, various meetings facilitate review processes like:

  • Sprint planning meetings for ordering user stories by priority.

  • Daily Scrum meetings encourage team alignment.

  • The sprint retrospective captures lessons across development phases.

Quality Management

Phil Crosby articulated common misunderstandings about quality:

  • Misconceptions about what is known contribute to ineffective quality management.

  • Individuals often think comprehending quality is straightforward.

Software Quality Assurance

  • Elements of SQA include standards, reviews, testing, error analysis, change management, education, and risk management.

Role of SQA Group 1

Responsibilities encompass creating SQA plans, evaluating standards, tracking processes, and providing feedback to project teams.

Role of SQA Group 2

Roles extend to compliance review of activities and ensuring documentation of noncompliance until resolved.

SQA Goals

Goals include:

  • Assessing requirements quality, ensuring design conformance, maintaining code quality, and facilitating effective quality control.

Formal SQA

Utilizes rigorous methods for requirement specifications and correctness demonstrations, though rarely applied by commercial software developers.

Statistical SQA

Focus on analyzing errors, tracing causes, and mitigating prevalent issues using the Pareto principle to isolate significant problems.

Six Sigma for Software Engineering 1

Six Sigma aims for near perfection in quality, emphasizing customer requirements, measurement of processes, and defect analysis.

Six Sigma for Software Engineering 2

Processes should be designed to prevent defects while ensuring future adherence to quality standards.

Software Reliability and Availability

  • Mean-Time-Between-Failure (MTBF): Defined as MTBF = MTTF + MTTR.

  • Software availability measures operational probabilities at any given time.

AI and Reliability Models

Utilizes Bayesian inference for updating reliability assessments and predictive analytics to estimate defect prone areas.

Software Safety

Focuses on identifying potential hazards to preemptively mitigate risks impacting software quality.

ISO 9001:2015 Standard

Specifications for achieving quality assurance in software engineering, encompassing various management and control processes.

SQA Plan Contents

Key components of an SQA plan include:

  1. Project scope.

  2. Work products overview.

  3. Applicable standards.

  4. Defined SQA tasks and their integration.

  5. Support tools for SQA actions.