The document discusses McCall's quality factors model for classifying software quality requirements. It describes the three categories in McCall's model - product operation factors, product revision factors, and product transition factors. Under each category, it lists and describes the specific quality factors, including correctness, reliability, efficiency, integrity, usability, maintainability, flexibility, testability, portability, reusability, and interoperability. It also discusses some alternative models that other researchers have proposed and eight design principles for structuring high-quality software designs.

1. Engineering Systems Design

2. • The need for comprehensive Software Quality Requirements
• Classification of requirements into Software Quality Factors
• Product Operation Factors
• Product Revision Factors
• Product Transition Factors
• Alternative models of software quality factors
Engineering Systems Design

3. Need for Comprehensive Software Quality
Requirements
• Need for improving poor requirements documents is widespread
• Frequently lack quality factors such as: usability, reusability,
maintainability, …
• Software industry groups the long list of related attributes into
what we call quality factors.
• Unequal emphasis on all quality factors.
• Emphasis varies from project to project

4. McCall’s Quality Factors
• McCall’s has 11 factors, Groups them into categories.
Others have added few more, but this still prevail.
• Three categories:
–Product Operation Factors
• Basic Operational Characteristics
• Correctness, Reliability, Efficiency, Integrity, and Usability
–Product Revision Factors
• Ability to Change
• Maintainability, Flexibility, Testability
–Product Transition Factors
• Adaptability to New Environment
• Portability, Reusability, Interoperability

5. McCall’s SW Quality Framework
Product Revision Factors Product Transition Factors
Product Operation Factors

6. McCall's Factor Model Tree

7. • Correctness
• Reliability
• Efficiency
• Integrity
• Usability
Product Operation Factors
How well does it run and ease of
use.

8. McCall’s Quality Factors
Category: Product Operation Factors
• 1. Correctness.
• The ability of software products to perform their exact tasks or
behaviors as defined by their specification.
• Examples include:
– Specifying accuracies for correct outputs.
– Specifying the completeness of the outputs.
– Specifying the timeliness of the output.
– Specifying the standards.

9. McCall’s Quality Factors
Category: Product Operation Factors
• 2. Reliability Requirements:
• Reliability requirements deal with the failure to provide service.
–Address failure rates either overall or to required functions.
• Example:
–A heart monitoring system have a failure rate less than one / million
cases.
–Downtime for a system will not be more than ten minutes per month.
• 3. Efficiency Requirements: Deals with the hardware resources
needed to perform the functions of the software.
–Here we consider MIPS, MHz (cycles per second), Data storage
capabilities measured in MB or TB, Communication lines (usually
measured in KBPS, MBPS, or GBPS).

10. McCall’s Quality Factors
Category: Product Operation Factors
• 4. Integrity Requirements: Deal with system security that
prevent unauthorized persons access.
• Cyber Security, Internet security, network security etc.
• 5. Usability Requirements: Deals with the scope of staff
resources needed to train new employees and to operate the software
system.
– Deals with learnability, utility, usability etc.
– Example spec: A staff member should be able to easily perform one
task.

11. • Maintainability
• Flexibility
• Testability
Product Revision Factors
Fix it Easily, Retest, Version it, and Deploy it
easily ?

12. McCall’s Quality Factors
Category: Product Revision Software
Factors
• 1. Maintainability Requirements
–The degree of effort deals with measure of how easily bug fixes or
functional modifications can be accomplished with the modular
structure of the software.
–Example: Refactoring...
• Maintenance activities:
–Corrective maintenance
–Adaptive maintenance
–Perfective maintenance

13. McCall’s Quality Factors
Category: Product Revision Software
Factors
• 2. Flexibility Requirements Deals with resources to change (adopt)
software. How easily can it be updated with the new functionality.
– May also involve a little perfective maintenance to perhaps do a little
better due to the customers, perhaps slightly more robust environment.
• 3. Testability Requirements. Deals with the testing of an information
system as well as with its operation.
– Are intermediate results of computations predefined to assist testing?
– Are log files created?
– Backup?
– Example: Traceability

14. • Portability
• Reusability
• Interoperability
Product Transition Factors
Can I move the app to different hardware ?
Can I reuse major portions of the code with little
modification to develop new apps ?

15. McCall’s Quality Factors
Category: Product Transition Software Quality Factors
• 1. Portability Requirements: If the software ported to different
environments (different hardware, operating systems) and still
maintain an existing environment, then portability is used.
• 2. Reusability Requirements: Deals with the using existing
software components in a different context.
• Are we able to reuse parts of the app for new applications?
– Can save massive development costs due to errors found / tested.

16. McCall’s Quality Factors
Category: Product Transition Software Quality Factors
• 3. Interoperability Requirements: Focus on creating
interface with other existing systems. To which software components
work together.
Example:
Firmware
Web portal

17. Alternatives
• Some other SQA professionals have offered essentially renamed quality
factors.
• One has offered 12 factors; another 15 factors.
• Totally five new factors were suggested
• Evans and Marciniak offer two ‘new’ ones.
– Verifiability
– Expandability
• Deutsch and Willis offer three ‘new’ ones.
– Safety
– Manageability
– Survivability

18. McCall's Factor Model and Alternative
Models

19. Evans and Marciniak Alternatives
– 1. Verifiability Requirements Addresses design and
programming features that allow for efficient verification of design
and programming.
• This does not refer to outputs, rather, structure of code, design
elements and their dependencies, coupling, cohesion, patterns…
– 2. Expandability Requirements The implementation takes
future growth into consideration, refers to scalability and extensibility
to provide more usability.
• McCall’s flexibility

20. Deutsch and Willis Alternatives
–1. Safety Requirements: Meant to eliminate risky conditions as
a result of errors in process control software, as in setting alarms or
sounding warnings.
•Especially important to process control / real time software such as
that running conveyor belts or instrumentation for ordinance…
–2. Manageability Requirements: Maintainability is a little
similar with flexibility but it focuses on modifications about error
corrections and minor function modifications, not major functional
extensibilities.
–3. Survivability Requirements: Is the ability to remain alive or
continue to exist. Refer to MTBF(Mean time between failures),
MTTR (Mean time to recover).
• McCall’s Reliability.

21. Alternatives
– ISO 9126 Quality Model.
– Boehm’s Quality Model.
– Dromey's Quality Model.
– FURPS Quality Model.

22. Design Principles

23. Design Principles
• Tunnel Vision
• Traceable
• Reinvent
• Intellectual distance
• Accommodate change
• Degrade gently
• Assessed quality
• Conceptual errors

24. Design Principles
1. Tunnel Vision: “The design process should not suffer from tunnel
vision”. A good designer should consider alternative approaches, judging
each based on the requirements of the problem.
Example: “Smart Tunnels” can not turn back to exit to come back.
2. Traceable: “The design should be traceable to the analysis model”.
Because a single element of the design model can often be traced back to
multiple requirements, it is necessary to have a means for tracking how
requirements have been satisfied by the design model.
• Any Queries, Any confusion trace back

25. Design Principles
3. Reinvent: “The design should not reinvent the wheel”. Systems are
constructed using a set of design patterns. These patterns should always
be chosen as an alternative to reinvention.
Already Used, Tested too many times.
4. Intellectual distance: “The design should minimize the intellectual
distance between the software and the problem as it exists in the real
world”. The structure of the software design should mimic the structure
of the domain.
Example: ATM machine
Ctrl + C

26. Design Principles
5. Accommodate change: “The design should be structured to
accommodate change”. Leave the space for change the design. To adopt
new things.
6. Degrade gently: “The design should be structured to degrade
gently, even when aberrant data, events, or operating conditions are
encountered”. Well- designed software should never "bomb"; it should
be designed to accommodate unusual circumstances, it should do in a
graceful manner.
WHAT WILL YOU DO WHEN SYSTEM IS GOING TO DIE ?

27. Design Principles
7. Assessed quality: “The design should be assessed for quality as it
is being created, not after the fact”. A variety of design concepts and
quality attributes are available to assist the designer in measuring quality
throughout the development process.
8. Conceptual errors: “The design should be reviewed to minimize
conceptual errors”.
Cohesion & coupling, ambiguity, inconsistency