0% found this document useful (0 votes)
7 views21 pages

Gouda

The report discusses the importance of software quality and quality assurance in the software development lifecycle, defining key concepts such as software errors, faults, and failures. It emphasizes the need for systematic approaches to ensure software meets specified requirements and user needs, while distinguishing between software quality assurance and quality control. The document outlines objectives for understanding and improving software quality, highlighting the relationship between software engineering and quality assurance.

Uploaded by

alaa saad
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views21 pages

Gouda

The report discusses the importance of software quality and quality assurance in the software development lifecycle, defining key concepts such as software errors, faults, and failures. It emphasizes the need for systematic approaches to ensure software meets specified requirements and user needs, while distinguishing between software quality assurance and quality control. The document outlines objectives for understanding and improving software quality, highlighting the relationship between software engineering and quality assurance.

Uploaded by

alaa saad
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 21

The Report

What is software quality?

Supervised By
ASS. Prof. Atef Galwash
Information Systems Department Faculty Of Computing and
Artificial Intelligence Helwan University

Submittied By
Amany Mohammed Gouda Osman
2025

pg. 1
Table Of Contants

Abstract ……………………………………………………...3

Introduction …………………………………………………4

Report Objective ……………………………………………5

What is Software?..………………………………. ………...6

Software Errors, Faults, and Failures…………………..…7

Classification of the Causes of Software Errors …………11

Software Quality ………………………………………...…12

Discussion …………………………………………………..16

Conclusion ………………………………………………….18

References ………………………………………………….19

Appendix …………………………………………………...19

pg. 2
Abstract
Before we proceed to study the components of the SQA system, the
basic concepts and objectives of software quality assurance should
be discussed. Later, it will be possible to examine how and to what
extent various methodologies and tools conform to these concepts
and objectives.

After completing this chapter, you will be able to:

 Define software, software quality and software quality


assurance.
 Distinguish between software errors, software faults and
software failures.
 Identify the various causes of software errors.
 Explain the objectives of software quality assurance activities.
 Distinguish and explain the difference between software
quality assurance and quality control.
 Explain the relationship between software quality assurance
and software engineering.

pg. 3
Introduction
In our increasingly digitally reliant world, software has become an
integral part of our daily lives, ranging from smartphone
applications we use for communication and entertainment to the
complex systems that manage vital industries. With this widespread
adoption, the importance of software quality emerges as a crucial
element for ensuring its effectiveness, reliability, and ability to
meet user needs and achieve desired goals.

The concept of software quality goes beyond merely the absence of


errors in a program. It encompasses a wide range of characteristics
that determine the suitability of the software for use, its
performance, security, ease of maintenance, and future
development. High-quality software not only provides the required
functionalities but does so efficiently, with minimal problems, and
in a way that ensures user satisfaction and business continuity.

In this report, we will delve into understanding what software


quality is, review the root causes of software errors and problems,
as well as classify these causes. We will also address the definition
of software quality and the importance of quality assurance in the
software development life cycle. Furthermore, we will clarify the
difference between software quality assurance and software quality
control, and explore the close relationship between software quality
assurance and software engineering as a whole. Understanding
these fundamental concepts is the first step towards building and
developing reliable and effective software that meets the
expectations of users in our rapidly evolving technological world.

pg. 4
Report Objective
This research aims to achieve the following objectives:

 Defining and Clarifying the Concept of Service Quality: To


identify the main dimensions of service quality and its importance
in achieving customer satisfaction and loyalty.
 Defining and Clarifying the Concept of Quality Control in the
Service Context: To review the processes and systems used to
ensure the achievement of quality standards in service delivery.
 Demonstrating the Integrative Relationship Between Service
Quality and its Control: To explain how effective control
contributes to achieving high levels of service quality.
 Identifying the Main Objectives that Organizations Seek to
Achieve by Focusing on Service Quality and its Control: To
explore the strategic and competitive benefits resulting from
adopting this approach.
 Reviewing Some of the Tools and Methodologies Used in
Measuring and Improving Service Quality and Applying its
Control: To provide practical examples of how to apply these
concepts in different work environments.

Through the achievement of these objectives, this research seeks to


provide a comprehensive understanding of the importance of service
quality and its control as two fundamental pillars for the success of
organizations in the modern era.

pg. 5
1.What is Software?
1.1 Definition:
Software is not simply a collection of code; it's a multi-faceted entity.
It comprises:

 Computer programs: These are the sets of instructions that


dictate the operations of a computer.
 Procedures: These are the operational steps and guidelines for
using the software effectively.
 Documentation: This includes user manuals, design
specifications, and other explanatory materials.
 Data: This is the information that the software manipulates and
processes.

To ensure software development and future maintenance quality,


four key components are essential:

 computer programs (code) to run applications, procedures to


organize execution and responsibilities, documentation (for
developers, users, and maintenance) to facilitate collaboration,
usage, and upkeep, and data (including customization and testing
data) for operation and integrity checks. Therefore, software
quality assurance encompasses the quality of code, procedures,
documentation, and necessary data.

1.2 Importance:
Software is now deeply ingrained in almost every aspect of our lives.
It powers communication, industry, healthcare, and countless other
sectors. Therefore , ensuring its quality is of paramount importance.

pg. 6
2. Software Errors, Faults, and Failures

Software development is a complex process, and errors are common.


 These errors can lead to:
 Faults: Defects or flaws within the software code itself.
 Failures: Instances where the software doesn't perform as
expected or produces incorrect results.
 The presence of these problems underscores the critical need for
software quality assurance.

Figure 1: Software errors, software faults and software failures

pg. 7
2.1 Software Error:
2.1.1 Definition: An error is a human action that results in an
incorrect software artifact. This incorrect action can occur at
any stage of the software development lifecycle (SDLC), from
requirements gathering and design to coding, testing,
documentation, and maintenance.

2.1.2 Causes: Errors typically stem from human factors such as:
Misunderstanding: Incorrect comprehension of client
requirements or system specifications.
Negligence: Lack of attention or haste during coding or design.
Lack of Knowledge or Experience: Insufficient familiarity
with a specific technology or the problem domain.
Communication Breakdown: Unclear instructions or
misinterpretations among development team members.
Time Pressure: Attempting to complete work quickly,
increasing the likelihood of mistakes.

2.1.3 Examples:
 Writing an incorrect mathematical formula in the code.
 Using a variable name inconsistently.
 Misinterpreting user requirements.
 Entering incorrect data during testing.

2.2 Faults (or Bugs):


2.2.1 Definition: A fault, also known as a bug, is a defect or
anomaly within the software itself that is a direct consequence
of a human error. In other words, the human error introduces a
flaw into the code, design, or any other deliverable of the
development process.
Location: Faults can reside in various parts of the software
system, including:
Source Code: Errors in logic, syntax, or the use of libraries.
Design: Flaws in the system architecture, user interfaces, or
databases.

pg. 8
Documentation: Inaccurate or misleading information in user
manuals or technical specifications.
Data: Incorrect or inconsistent initial data.

2.2.2 Examples:
 An infinite loop that never terminates.
 Attempting to access an array index that is out of bounds.
 An incorrect logical condition that leads to the execution of the
wrong code section.
 A database design that doesn't support the required relationships
between tables.

2.3 Failures:
2.3.1 Definition: A failure is the deviation of the software system
from its expected or specified behavior during execution. A
failure occurs when a fault present in the software is activated by
a specific set of inputs or environmental conditions.
2.3.2 Relationship to Faults:
Not every fault necessarily leads to a failure. A fault can remain
dormant in the software for an extended period without being
triggered. A failure only manifests when the part of the code
containing the fault is executed with inputs or in an environment
that exposes the problem.
2.3.3 Examples:
 The program crashing unexpectedly.
 Displaying incorrect information to the user.
 The system becoming unresponsive to user commands.
 Significant slowdown in system performance.
 Loss or corruption of data.
 A security breach allowing unauthorized access.

2.4 The Relationship: Error → Fault → Failure

pg. 9
The relationship between these concepts can be visualized as a chain of
events:

Human Error → Introduces a Software Fault (Bug) → Activated


under Specific Conditions → Results in a System Failure

Importance of Understanding These Concepts:

 Improving the Development Process: Understanding the sources


of errors helps in implementing preventative measures to reduce
their likelihood.
 Enhancing Testing Effectiveness: Focusing testing efforts on
areas where faults are more likely to exist increases the efficiency
of the testing process.
 Improving Software Quality: The ultimate goal is to minimize
the number of faults and failures to deliver reliable and high-
quality software.
 Reducing Costs: Detecting and fixing faults in the early stages of
the SDLC is significantly less expensive than addressing failures
after deployment.
 Increasing User Satisfaction: Software free from failures
provides a better user experience.

The problem of software errors, faults, and failures is a persistent


challenge in software engineering. By understanding the nature of
these issues, their causes, and their interrelationships, developers
and quality assurance professionals can adopt best practices and
techniques to minimize their occurrence and ensure the delivery of
more reliable and higher-quality software.

3. Classification of the Causes of Software Errors

pg. 10
3.1 Human Error:
 The primary source of software errors is human fallibility.
 Developers, analysts, and other stakeholders can make mistakes.
 This refers to unintentional mistakes or omissions made by individuals
involved in the software development process or in quality assurance
activities. These errors can occur at any stage of the software
development life cycle, starting from requirements definition and
design, through programming and testing, and up to documentation
and maintenance.

3.2 Categories of Causes:


 Incorrect Requirements:
 Errors can arise from poorly defined, ambiguous, or incomplete
software requirements.
 If the development team doesn't have a clear understanding of what
the software is supposed to do, they are likely to make mistakes.
 Design Errors:
 Flaws in the software's design or architecture can introduce errors.
 These errors occur during the planning phase and can be difficult
to correct later.
 Coding Errors:
 Mistakes made while writing the program code are a common
source of errors.
 These can range from simple typos to complex logic errors.
 Interface Errors:
 Errors can occur when different software components or systems
interact with each other.
 These errors often involve misunderstandings about how data
should be exchanged.
 Testing Errors:
 Inadequate or incorrect testing can fail to detect existing errors.
 If the testing process is flawed, errors may slip through to the final
product.
 Documentation Errors:

pg. 11
 Inaccuracies or omissions in software documentation can lead to
confusion and errors in use.
 If the documentation doesn't accurately reflect how the software
works, users may make mistakes.

4. Software Quality

Figure 2: McCall’s factor model tree Correctness Interoperability


Maintainability Source: Based on McCall et al., 1977

4.1 IEEE Definition:

pg. 12
 The Institute of Electrical and Electronics Engineers (IEEE) defines
software quality as the degree to which software meets specified
requirements.
 It also considers the degree to which software meets user needs or
expectations.

4.2 Expanded View:


 Software quality is a multi-dimensional concept.
 Key aspects include:
 Functionality: The ability of the software to perform its intended
functions.
 Reliability: The ability of the software to perform consistently
without failures.
 Usability: The ease with which users can learn and use the software.
 Efficiency: The software's use of resources (e.g., CPU, memory).
 Maintainability: The ease with which the software can be modified
or repaired.
 Portability: The ability of the software to run on different platforms
or environments.

4.3 Software Quality Assurance (SQA) - Definition and


Objectives
4.3.1 Software Quality Assurance Definitions
 IEEE Definition:
 SQA is a planned and systematic approach to ensuring software
quality.
 It involves all the actions taken to provide confidence that software
conforms to established technical requirements.
 Expanded Definition:
 SQA is a broader concept that encompasses the entire
software lifecycle.
 It includes:
 Software development processes
 Software maintenance processes

pg. 13
 Project schedules
 Budget constraints

 Elements of Software Quality Assurance


 Software Engineering Standards: SQA teams are critical to
ensure that we adhere to the above standards for software
engineering teams.
 Technical Reviews and Audits: Active and passive
verification/validation techniques at every SDLC stage.
 Software Testing for Quality Control: Testing the software to
identify bugs.
 Error Collection and Analysis: Defect reporting, managing, and
analysis to identify problem areas and failure trends.
 Metrics and Measurement: SQA employs a variety of checks and
measures to gather information about the effectiveness and quality
of the product and processes.
 Change Management: Actively advocate controlled change and
provide strong processes that limit unanticipated negative
outcomes.
 Vendor Management: Work with contractors and tool vendors to
ensure collective success.
 Safety/Security Management: SQA is often tasked with exposing
vulnerabilities and bringing attention to them proactively.
 Risk Management: Risk identification, analysis, and Risk
mitigation are spearheaded by the SQA teams to aid in informed
decision-making
 Education: Continuous education to stay current with tools,
standards, and industry trends

4.3.2 The Objectives of SQA Activities


The primary goals of SQA are to:
 Ensure Conformance: Verify that the software adheres to all
specified requirements.

pg. 14
 Improve Efficiency: Optimize the software development and
maintenance processes.
 Promote Quality: Foster a culture of quality throughout the
development lifecycle.

4.4 Software Quality Assurance vs. Software Quality


Control
 Software Quality Assurance (SQA):
 Focus:
 SQA is process-oriented.
 It emphasizes the establishment of good software development
processes.
 Goal:
 The primary goal is to prevent defects from occurring in the first
place.
 SQA aims to "build quality in."
 Software Quality Control (SQC):
 Focus:
 SQC is product-oriented.
 It concentrates on examining the software product itself.
 Goal:
 The primary goal is to identify defects that already exist.
 SQC involves activities like testing and inspection.

4.5 Software Quality Assurance and Software Engineering


 Software engineering is the discipline of designing, developing,
and maintaining software systems.
 SQA is an integral part of software engineering.
 Software engineering provides the methods, tools, and techniques
that enable effective SQA.
 SQA activities should be applied throughout the software
development lifecycle, from requirements gathering to deployment
and maintenance.
 Software Engineering: This is the discipline that deals with the
design, development, and maintenance of software systems. It is an

pg. 15
engineering approach to developing high-quality software
efficiently and in an organized manner. Software engineering
encompasses a range of processes, methods, and tools used in all
phases of the software development lifecycle.
 Software Quality Assurance (SQA): As we discussed previously,
this is the set of systematic activities and processes aimed at
ensuring that software development and maintenance processes
meet established requirements and standards.
 The Relationship Between Them:
The relationship between software engineering and
software quality assurance can be understood through the
following points:
 SQA is an integral part of Software Engineering: Quality
assurance is not a separate or additional activity, but rather
a fundamental and integrated component of the software
engineering process. SQA activities must be planned and
executed throughout all stages of the software development
lifecycle.
 Software Engineering provides the tools and techniques for
SQA: Software engineering methods, tools, and techniques
provide the foundation upon which quality assurance can be
effectively applied. For example, organized software development
methodologies (such as Agile or Waterfall) help in integrating
regular review and testing activities, which are essential parts of
quality assurance.
 Applying SQA throughout the Software Development
Lifecycle: Quality assurance activities should be applied in all
phases of software development, starting from requirements
gathering and system design, through programming and testing, to
deployment and maintenance. This ensures that quality is built into
the product from the beginning and not just verified at the end.

pg. 16
Discussion
 Impact of Software Quality:
o Discuss how software quality affects user satisfaction,
customer loyalty, and the costs associated with software
maintenance and support.
 Challenges of SQA Implementation:
o Explore the difficulties in implementing effective SQA
processes, especially in large and complex software projects.
 Automation in SQA:
o Analyze the role of automated tools and techniques in
software testing, code analysis, and other SQA activities.
 Continuous Improvement:
o Emphasize the importance of constantly evaluating and
refining software quality processes to adapt to new
technologies and development practices.

pg. 17
Conclusion
 Software is a complex entity that includes not only code but also
procedures, documentation, and data.
 Software quality is the degree to which software meets specified
requirements and user expectations.
 Software quality assurance (SQA) is a systematic approach to
ensuring software quality throughout the software lifecycle.
 Software errors are mistakes made by developers, faults are defects
in the code, and failures are instances where the software
malfunctions.
 SQA focuses on preventing defects and improving development
processes, while software quality control focuses on identifying
existing defects.
 Software engineering provides the foundation for SQA activities,
and SQA is an essential part of software engineering practice.

pg. 18
References
1) Galin, Daniel. Software Quality Assurance: From Theory to
Implementation. Addison-Wesley, 2004.
2) ScienceDirect. Elsevier, www.sciencedirect.com/. Accessed [Date
you accessed it]

Appendix
Supporting Materials for Software Quality Report

5.1 Detailed Examples of Software Issues

5.1.1 Pharm-Plus Software Failure:

o This section would elaborate on the example provided in the


document regarding the pharmacy software.
o It could include:
 A more detailed description of the faulty "super customer"
identification process.
 A step-by-step scenario illustrating how the failure occurred when
the new pharmacy implemented the feature.
 Discussion of the potential consequences of this failure (e.g.,
incorrect discounts, customer dissatisfaction).

5.1.2 Meteoro-X Firmware Failure:

o This section would provide a more in-depth look at the


meteorological equipment firmware example.
o It could include:
 Explanation of the potential damage that could result from the
temperature limit error.
 Discussion of why the error remained undetected for a period
(environmental conditions).
 Consideration of the implications if the equipment had been
deployed in a different climate.

pg. 19
5.2 Expanded Classification of Software Error Causes

 This section would provide more detailed explanations and


examples for each category of software error causes:

5.2.1 Faulty Definition of Requirements:

 Examples of different types of faulty requirements (e.g.,


ambiguous, conflicting, untestable).
 Explanation of the impact of faulty requirements on subsequent
development stages.

5.2.2 Client-Developer Communication Failures:

 Specific scenarios illustrating communication breakdowns (e.g.,


lack of documentation, ineffective meetings).
 Best practices for improving communication between clients and
developers.

5.2.3 Deliberate Deviations from Requirements:

 Case studies of projects where developers intentionally deviated


from requirements and the consequences.
 Discussion of ethical considerations and the importance of adhering
to requirements.

5.2.4 Logical Design Errors:

 More complex examples of logical design errors (e.g., incorrect


algorithms, flawed data flow diagrams).
 Techniques for detecting and preventing design errors.

5.2.5 Coding Errors:

 Categorization of different types of coding errors (e.g., syntax errors,


logic errors, data type errors).
 Examples of common coding errors and how to avoid them.

pg. 20
5.2.6 Interface Errors:

 Detailed explanations of interface errors between software


components and between software and hardware.
 Strategies for testing and ensuring interface compatibility.

5.2.7 Testing Errors:

 Discussion of different types of testing errors (e.g., inadequate test


coverage, incorrect test data).
 The importance of thorough and well-designed test cases.

5.2.8 Documentation Errors:

 Examples of how documentation errors can lead to user errors and


maintenance problems.
 Guidelines for creating clear, accurate, and comprehensive software
documentation.

5.3. Review Questions and Discussion Topics (From Source)

 This section would directly reproduce the review questions and


topics for discussion provided in the source document.
o This gives the reader an opportunity for self-assessment and further
exploration of the subject matter.

This appendix would significantly expand upon the core report,


providing readers with deeper insights, practical examples, and tools
for further learning

pg. 21

You might also like