Scribd
Upload
19 views

Lecture 03

this is a software verification and validation lecture note

Uploaded by

yasas bro
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
19 views

Lecture 03

this is a software verification and validation lecture note

Uploaded by

yasas bro
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 33

Chapter 3

Software Quality Factors


Software Quality Factors

After completing this chapter, you will be able to:

• Explain the need for comprehensive requirements documents


and characterize the contents of such documents.
• Explain the structure (categories and factors) of McCall's
classic factor model.
• List the factors, other than those included in McCall's model,
that are suggested by the alternative SQA models.
• Identify who is interested in the definition of quality
requirements.
Outline

1. The need for comprehensive software quality factors


2. Classification of software requirements into software quality factors
3. Product operation software quality factors
4. Product revision software quality factors
5. Product transition software quality factors
6. Alternative models of software quality factors
7. Who is interested in the definition of quality requirements?
8. Software compliance with quality factors
3.1 The need for comprehensive
software quality factors
• Many cases of low customer satisfaction
➢ Where software projects have fulfilled the basic requirements
of correctness(Correct inventory figures, correct loan
interest, etc.),
➢ but suffering from poor performance in other areas such as
maintenance, reliability, software reuse or training.
•Due to lack of defined requirements pertaining to these
important aspects of software functionality.
3.1 The need for comprehensive
software quality factors….
• Therefore the need for a comprehensive definition of requirements
that will cover
➢ all attributes of software and
➢aspects of the use of software, including usability aspects, reusability
aspects, maintainability aspects, and so forth
in order to assure the full satisfaction of the users.
• What is a “good” software requirements document?
➢What subjects and aspects of software use should be covered in the
document?
3.2 Classification of s/w
requirements into s/w quality factors

Some SQA models suggest that the wide spectrum of


requirements should be classified into 11 to 15 factors:
• McCall’s factor model (1977) - 11 factors
• The Evans and Marciniak factor model (1987)- 15 factors
• The Deutsch and Willis factor model (1988) - 12 factors
McCall’s Classic factor model (1977)

• McCall’s factor model classifies all software requirements


into 11 software quality factors (grouped into 3 categories).
➢Product operation factors : Correctness, Reliability,
Efficiency, Integrity, Usability.
➢Product revision factors : Maintainability, Flexibility,
Testability.
➢Product transition factors : Portability, Reusability,
Interoperability.
1.Product Operation Factors

Product operation category includes five software quality


factors, which deal with the requirements that directly affect
the daily operation of the software.
1.Correctness:
• Correctness requirements are defined in a list of the
software system’s required outputs.
• If a software system satisfies all the functional requirements,
the system is said to be correct.
1.Product Operation Factors…

1.Correctness:
• The output mission.
• The required accuracy of those outputs that can be adversely
affected by inaccurate data or inaccurate calculations.
• The availability of the information.
• The standards for coding and documenting the software
system.
1.Product Operation Factors…

2.Reliability
• Customers may still consider an incorrect
system to be reliable if the failure rate is
very small and it does not adversely affect
their mission objectives.
• Reliability is a customer perception, and an
incorrect software can still be considered to
be reliable.
1.Product Operation Factors…

3.Efficiency:
• Efficiency concerns to what extent a software
system utilizes resources, such as computing
power, memory, disk space, communication
bandwidth, and energy.
• A software system must utilize as little resources
as possible to perform its functionalities.
1.Product Operation Factors…

4.Integrity:
• A system’s integrity refers to its ability to withstand
attacks to its security.
• In other words, integrity refers to the extent to
which access to software or data by unauthorized
persons or programs can be controlled.
1.Product Operation Factors…

5.Usability:
• A software is considered to be usable if human
users find it easy to use.
• Without a good user interface a software system
may fizzle out even if it possesses many desired
qualities.
2.Product Revision Factors

These factors deal with those requirements that affect the


complete range of software maintenance activities:
• Corrective maintenance (correction of software faults and
failures),
• Adaptive maintenance (adapting the current software to
additional circumstances and customers without changing the
software)
• Perfective maintenance (enhancement and improvement of
existing software with respect to locally limited issues).
2.Product Revision Factors…

6.Maintainability:
• Maintenance refers to the upkeep of products in response to
deterioration of their components due to continuous use of
the products.
• Maintenance refers to how easily and inexpensively the
maintenance tasks can be performed.
• This factor’s requirements refer to the modular structure of
software, the internal program documentation, and the
programmer’s manual, among other items.
2.Product Revision Factors…

7.Testability:
• Testability means the ability to verify requirements. At
every stage of software development, it is necessary
to consider the testability aspect of a product.
• To make a product testable, designers may have to
instrument a design with functionalities not available
to the customer.
2.Product Revision Factors…

8.Flexibility:
• Flexibility is reflected in the cost of modifying an operational
system.
• In order to measure the flexibility of a system, one has to
find an answer to the question: How easily can one add a
new feature to a system.
3.Product Transition Factors

According to McCall, three quality factors are included


in the product transition category, a category that
pertains to the adaptation of software to other
environments and its interaction with other software
systems.
3.Product Transition Factors

9.Portability
• Portability of a software system refers to how easily it can
be adapted to run in a different execution environment.
• Portability gives customers an option to easily move from
one execution environment to another to best utilize
emerging technologies in furthering their business.
3.Product Transition Factors

10.Reusability
• Reusability means if a significant portion of one product
can be reused, maybe with minor modifications, in
another product.
• Reusability saves the cost and time to develop and test
the component being reused.
3.Product Transition Factors

11.Interoperability :
• Interoperability means whether or not the output of
one system is acceptable as input to another system,
it is likely that the two systems run on different
computers interconnected by a network.
• An example of interoperability is the ability to roam
from one cellular phone network in one country to
another cellular network in another country.
The Evans and Marciniak factor model
(1987)

• 12 factors, 3 categories
➢ Categories : Design, Performance, Adaptation
➢ Comparing the 12 factors with the classic model :
+ Verifiability
+ Expandability (~McCall’s Flexibility factor)
- Testability
The Deutsch and Willis factor model
(1988)
• 15 factors, 4 categories
➢ Categories : Functional, Performance, Change, Management

➢ Comparing the 15 factors with the classic model :


+ Verifiability
+ Expandability (~McCall’s Flexibility factor)
+ Safety
+Manageability
+ Survivability (~McCall’s Reliability factor)
- Testability
3.7 Who is interested in the definition
of quality requirements?

• The client is not the only party interested in thoroughly defining


the requirements.
• The developer : may add requirements that represent his own
interest. E.g.:
➢ Reusability requirements
➢ Verifiability requirements
➢ Portability requirements
3.8 Software compliance with
quality factors
•Throughout the software development process, the extent to which the
process complies with the requirements of the various quality factors is
examined by design reviews, software inspections, software tests, and so
forth..
•Furthermore, the software product’s compliance to the requirements
belonging to the various quality factors is measured by software quality
metrics, measures that quantify the degree of compliance.
➢ In order to allow for valid measurements of compliance, sub-factors
have been defined.
➢ Software quality metrics are suggested for each of these sub-factors.
Factors and sub-factors

• As you have probably noticed, several sub-


factors relate to more than one factor.
• This reflects the fact that some attributes
contribute to successful compliance in
more than one aspect of software use.
• For e.g., simplicity (a sub-factor)
contributes to maintainability, flexibility,
reusability and expandability factors
Let’s move on to the next part.

The components of the software quality


assurance system

Thank you!!

You might also like