1. Factor Of Software Quality
By: MSMZ

2. The need for comprehensive software quality requirements
There are some characteristics commons to all the case study which is key word “but’s”:
All the software projects satisfactorily fulfilled the BASIC requirements for correct calculations (e.g correct discount, correct loan interest)
But, all the software projects suffered from poor performance in important areas such as maintenance, reliability, software reuse, or training.
The cause for the poor performance of the developed software projects in these areas was the lack of predefined requirements to cover these important aspects of the software’s functionality.
By: MSMZ

3. The need for comprehensive software quality requirements
There is a need for comprehensive definition of requirements that will cover all attributes of software and aspects of the use of software including reliability aspects, maintainability aspects and so on .
The issues related to the various attributes of software is called as software quality factors.
So, there must be a team responsible for defining the software requirements of a software system to examine the need to define the requirements that belong to each factor.
By: MSMZ

4. McCall model
By: MSMZ

5. Classifications of Software Requirements into Software Quality Factors
McCall model (1977) consists of 11 factors.
It classifies all software requirements into 11 software quality factors.
The 11 factors are grouped into three categories
Product operation
Product revision
Product transition
By: MSMZ

6. Classifications of Software Requirements into Software Quality Factors
Product operation factors:
Correctness, Reliability, Efficiency, Integrity, Usability
Product revision factors:
Maintainability, Flexibility, Testability
Product transition factors:
Portability, Reusability, Interoperability
By: MSMZ

7. Product operation software quality factors
Five software quality factors are included in this category.
Deal with requirements that directly influence the daily operation of the software.
By: MSMZ

8. Product operation software quality factors
Correctness
The extent to which a program satisfies its specification and fulfills customer’s objectives. (McGraw Hill)
Example:-
Such as a query display of a customer’s balance in the sales accounting information system.
By: MSMZ

9. Product operation software quality factors (Correctness)
Must have an output specifications which are
The output mission
The acceptable accuracy of those output that can be affected by inaccurate data or inaccurate calculation
The acceptable of the output information, which can be adversely affected by incomplete data
The up-to-dateness of the information.
The availability of the information
The standard for coding and documenting the software system.
By: MSMZ

10. Product operation software quality factors (Correctness) - example
The correctness requirements of a club membership information system consists:-
The output mission :
A list of 11 types of reports
The required accuracy of the outputs:
The probability for a non-accurate output that containing mistakes, will not exceed 1%.
The completeness of the output information:
The probability of missing data will not exceed 1%.
The up-to-dateness of the information:
Not more than two working days for information about participation…
The availability of information:
Reaction time for queries will be less than 2 seconds on average…
The required standard and guidelines:
The software and documentation are required to comply with client guidelines
By: MSMZ

11. Product operation software quality factors
Reliability
Reliability requirements deal with failures to provide service.
The extent to which a program can be expected to perform its function with required precision. (McGraw Hill)
Example:
the failure frequency of a heart-monitoring unit that will operate in a hospital is required must be less than one in 20years.
Failure frequency of money transaction is within 10 minutes per month during bank’s office hours.
By: MSMZ

12. Product operation software quality factors
Efficiency
The amount of hardware resources and code required by a program to perform its function. (McGraw Hill)
Requirements deal with the hardware resources needed to perform all the functions of the software system in conformance to all other requirements.
Example: There are 2 software which is system A and systems B. System A required 100GB processor and 500GB HD to run the program while system B required 50GB processor and 100GB HD to run the program. WHICH ONE IS MORE EFFICIENT??
By: MSMZ

13. Product operation software quality factors
Integrity
Extent to which access to software or data by unauthorized persons can be controlled. (McGraw Hill)
Requirements deal with the software system security
requirements to prevent access to unauthorized persons
Data confidentiality, privacy
Example :-
A GIS (geographic Information System). Allow public to access through the internet. Allow only viewing and copying but not inserting.
By: MSMZ

14. Product operation software quality factors
Usability
Effort required to learn, operate, prepare input of a program. (McGraw Hill)
Is the ease of use and learnability of a human-made object. The object of use can be a software application, website, book, tool, machine, process, or anything a human interacts with
Requirements deal with the scope off staff resources to operate the software system.
Example :-
a staff member should be able to handle at least 60 services calls a day.
Training a new employee will take no more than two days.
By: MSMZ

15. Product revision software quality factor
Three quality factors comprise the product revision category
Deal with those requirements that affect the complete range of software maintenance activities:
Corrective maintenance (correction of software faults and failure)
Adaptive maintenance (adapting the current software to additional circumstances and customers without changing the software)
Perfective maintenance (enhancement and improving of existing software with respect to locally limited issues).
By: MSMZ

16. Product revision software quality factor
Maintainability
Effort required to locate and fix an error in a program (McGraw Hill)
Maintainability requirement determine the efforts that will be needed by users and maintenance personnel to identify the reasons for software failures, to correct the failures, and to verify the success of the corrections.
Refers to modular structure of the software, the internal program documentation, programmer’s manual.
By: MSMZ

17. Product revision software quality factor
Maintainability
Example : the size of a software module will not exceed 30 statements
The programming will hold to the company coding standards and guideline.
By: MSMZ

18. Product revision software quality factor
Flexibility
Effort required to modify operational program. (McGraw Hill)
The capabilities and efforts required to support adaptive maintenance activities
This includes the resources required to adapt a software package to a variety of customers of the same trade, of various extents of activities, of different ranges of products and so on.
This factor requirements also support perfective maintenance activities such as changes and additions to the software in order to improve its service.
By: MSMZ

19. Product revision software quality factor
Testability
Effort required to test a program to ensure that it performs its intended function.
Deal with the testing of an information system as well as with its operation.
Requirements for ease of testing are related to special features in the programs that help the tester, example providing predefined intermediate results and log files.
Requirements includes automatic diagnostics performed by the software system prior to starting the system, report about detected faults etc.
Also automatic diagnostic checks to detect the cause of software failure.
By: MSMZ

20. Product transition software quality factor
This category pertains to the adaptation of software to other environments and its interaction with other software systems.
Three quality factors are included in this category.
Portability
Reusability
Interoperability
By: MSMZ

21. Product transition software quality factor
Portability
Requirement tend to the adaptation of a software system to other environments consisting of different hardware, different operating systems, and so forth.
To make it possible to continue using the same basic software in diverse situation or to use it simultaneously in diverse hardware and OS situation.
By: MSMZ

22. Product transition software quality factor
Portability
Example: a software package designed and programmed to operate in a Windows environment is required to allow low-cost transfer to Linux and Window NT environment.
By: MSMZ

23. Product transition software quality factor
Reusability
Requirement deal with the use of software modules originally designed for one project in a new software project currently being developed.
Also enable future projects to make use of a given module or a group of modules of the currently developed software.
This is expected to save development resources, shorten the development period, and provide higher quality modules. This assumption is through detection of faults by previous users during earlier reuses.
By: MSMZ

24. Product transition software quality factor
Interoperability
Requirements focus on creating interfaces with other software systems or with other equipment firmware ( for example, the firmware of the production machinery and testing equipment interfaces with the production control software).
Example: the medical laboratory’s system is required to process the results according to a standard data structure and then serve as input for laboratory information systems.
By: MSMZ

25. McCall’s Software Quality Factors
Portability
Reusability
Interoperability
Maintainability
Flexibility
Testability
PRODUCT REVISION
PRODUCT TRANSITION
PRODUCT OPERATION
Correctness Reliability Usability Integrity
Efficiency
By: MSMZ

26. McCalls factor model tree
By: MSMZ

27. ALTERNATIVES MODEL
By: MSMZ

28. THE BOEHM MODEL (1978)
Introduced in 78. Boehm has defined 3 level of quality attributes:
Primary Uses
Intermediate constructs
Primitive constructs
Similar to McCall model that it represents a hierarchical structure of characteristics.
Boehm model sees the view of software with general utility. Utility from various dimension.
General utility broken down into portability, utility and maintainability.
By: MSMZ

29. Intermediate Constructs
Primary Uses
Intermediate Constructs
Primitive Constructs
By: MSMZ

30. THE BOEHM MODEL (1978)
Utility is further broken down into reliability, efficiency and human engineering.
Maintainability is in turn broken down into testability, understandability and modifiability.
This model is presented in levels called primary uses, intermediate construct and primitive constructs.
By: MSMZ

31. ISO 9126 Quality Factors
The ISO 9126 standard was developed in an attempt to identify the key quality attributes for computer software.
This standard aimed to define a quality model for software and a set of guidelines for measuring the characteristics associated with it.
Functionality
Reliability
Usability
Efficiency
Maintainability
Portability
By: MSMZ

32. ISO 9126 Quality Factors
By: MSMZ

33. Dromey
According to Dromey's (1995) model takes a different approach to software quality then the two previously presented models.
For Dromey, a quality model should clearly be based upon the product perspective of quality
Dromey has built a quality evaluation framework that analyses the quality of software components through the measurement of tangible quality properties
By: MSMZ

34. Dromey
Dromey gives the following examples of what he means by software components for each of the different models:
Variables, functions, statements, etc. can be considered components of the implementation model;
A requirement can be considered a component of the requirements model;
A module can be considered a component of the design model.
By: MSMZ

35. Dromey
According to Dromey (1995), these components all possess intrinsic properties that can be classified into four categories:
Correctness: Evaluates if some basic principles are violated.
Internal: Measure how well a component has been deployed according to its intended use.
Contextual: Deals with external influences and the use of a component.
Descriptive: Measure the descriptiveness of a component (for example, does it have a meaningful name?).
By: MSMZ

36. Dromey
These properties are used to evaluate the quality of the components. This is illustrated in a figure below for a variable component present in the implementation model.
By: MSMZ

37. Measurement of Quality
By: MSMZ

38. Fact
It is difficult and in some cases impossible to develop direct measures of these quality factors.
Many of metrics defined by McCall can be measured only indirectly.
By: MSMZ

39. Measurement of Quality
Factors that affect software quality can be put into two categories:
factors that can be directly measured
factors that can be measured only indirectly (e.g. usability and maintainability)
Software quality factors should focus on three important aspects of a software product:
its operational characteristics
its ability to undergo change
its adaptability to new environments
By: MSMZ

40. Measurement of Quality
One example of a popular metric is the number of faults encountered in the software. Software that contains few faults is considered by some to have higher quality than software that contains many faults.
By: MSMZ

41. Thank You
By: MSMZ

42. Exercise
Choose 1 factor from McCall factor model and give one scenario or example according to the factor that you have choose.
By: MSMZ

43. Assignment
Find other software quality factor, explain the factor and give the example for each factor.
One group (2 members) find only 1 factor and 1 example. The assignment need to be present in next week class.
By: MSMZ