McCall Quality Factors Model

Several models of software quality factors and their categorization in factor categories have been suggested over the years. The classic model of software quality factors, suggested by McCall, consists of 11 factors (McCall et al., 1977). Subsequent models, consisting of 12 to 15 factors, were suggested by Deutsch and Willis (1988) and by Evans and Marciniak (1987). The alternative models do not differ substantially from McCall’s model. The McCall factor model, despite the quarter of a century of its “maturation”, continues to provide a practical, up-to-date method for classifying software requirements (Pressman, 2000).

McCall’s factor model

McCall’s factor model classifies all software requirements into 11 software quality factors. The 11 factors are grouped into three categories – product operation, product revision and product transition – as follows:

1. Product operation factors:

According to McCall’s quality factors model, five software quality factors are included in the product operation category, all of which deal with requirements that directly affect the daily operation of the software. These factors are as follows.

• Correctness: Correctness requirements are defined in a list of the software system’s required outputs, such as a query display of a customer’s balance in the sales accounting information system, or the air supply as a function of temperature specified by the firmware of an industrial control unit. Output specifications are usually multidimensional; some common dimensions include:
  Examples include:
  –Specifying accuracies for correct outputs at, say, NLT <1% errors, that could be affected by inaccurate data or faulty calculations;

• Reliability: Reliability requirements deal with failures to provide service. They determine the maximum allowed software system failure rate, and can refer to the entire system or to one or more of its separate functions.
  Example specs:
  –A heart monitoring system must have a failure rate of less than one per million cases.
  –Downtime for a system will not be more than ten minutes per month (me)

• Efficiency: Efficiency requirements deal with the hardware resources needed to perform all the functions of the software system in conformance to all other requirements. The main hardware resources to be considered are the computer’s processing capabilities (measured in MIPS – million instructions per second, MHz or megahertz – million cycles per second, etc.), its data storage capability in terms of memory and disk capacity (measured in MBs – megabytes, GBs – gigabytes, TBs – terabytes, etc.) and the data communication capability of the communication lines (usually measured in KBPS – kilobits per second, MBPS – megabits per second, and GBPS – gigabits per second). The requirements may include the maximum values at which the hardware resources will be applied in the developed software system or the firmware. Another type of efficiency requirement deals with the time between recharging of the system’s portable units, such as, information systems units located in portable computers, or meteorological units placed outdoors.
  Example spec:  An outdoor meteorological unit, equipped with a 1000 milli-ampere hour cell, should be capable of supplying the power requirements of the unit for at least 30 days. The system performs measurements once per hour, logs the results, and transmits the results once a day to the meteorological center by means of wireless communication.

• Integrity: Integrity requirements deal with the software system security, that is, requirements to prevent access to unauthorized persons, to distinguish between the majority of personnel allowed to see the information (“read permit”) and a limited group who will be allowed to add and change data (“write permit”), and so forth.
  Example spec: The Engineering Department of a local municipality operates a GIS (Geographic Information System). The Department is planning to allow citizens access to its GIS files through the Internet. The software requirements include the possibility of viewing and copying but not inserting changes in the maps of their assets as well as any other asset in the municipality’s area (“read only” permit). Access will be denied to plans in progress and to those maps defined by the Department’s head as limited access documents.
• Usability: Usability requirements deal with the scope of staff resources needed to train a new employee and to operate the software system. For more about usability see Juristo et al. (2001), Donahue (2001) and Ferre et al. (2001).
  Example spec:  A staff member should be able to process n transactions / unit time.  (me). A staff member should be able to handle at least 60 service calls a day

2. Product revision factors:

According to the McCall model of software quality factors, three quality factors comprise the product revision category. 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) and perfective maintenance (enhancement and improvement of existing software with respect to locally limited issues). These are as follows.

• Maintainability: Maintainability requirements 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. This factor’s requirements refer to the modular structure of software, the internal program documentation, and the programmer’s manual, among other items. 
  Example spec: (a) The size of a software module will not exceed 30 statements. (b) The programming will adhere to the company coding standards and guidelines.
• Flexibility: The capabilities and efforts required to support adaptive maintenance activities are covered by the flexibility requirements. These include the resources (i.e. in man-days) 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’s requirements also support perfective maintenance activities, such as changes and additions to the software in order to improve its service and to adapt it to changes in the firm’s technical or commercial environment.
  Example spec: TSS (teacher support software) should be suitable for teachers of all subjects and all school levels (elementary, junior and high schools).
• Testability: Testability requirements deal with the testing of an information system as well as with its operation. Testability requirements for the ease of testing are related to special features in the programs that help the tester, for instance by providing predefined intermediate results and log files. Testability requirements related to software operation include automatic diagnostics performed by the software system prior to starting the system, to find out whether all components of the software system are in working order and to obtain a report about the detected faults. Another type of these requirements deals with automatic diagnostic checks applied by the maintenance technicians to detect the causes of software failures.
  Example space: An industrial computerized control unit is programmed to calculate various measures of production status, report the performance level of the machinery, and operate a warning signal in predefined situations. One testability requirement demanded was to develop a set of standard test data with known system expected correct reactions in each stage. This standard test data is to be run every morning, before production begins, to check whether the computerized unit reacts properly.

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. Can I move the app to different hardware? Interface easily with different hardware / software systems;  can I reuse major portions of the code with little modification to develop new apps?

• Portability: Portability requirements tend to the adaptation of a software system to other environments consisting of different hardware, different operating systems, and so forth. These requirements make it possible to continue using the same basic software in diverse situations or to use it simultaneously in diverse hardware and operating systems situations.
  Example Space: A software package designed and programmed to operate in a Windows 2000 environment is required to allow low-cost transfer to Linux and Windows NT environments.
• Reusability: Reusability requirements deal with the use of software modules originally designed for one project in a new software project currently being developed. They may also enable future projects to make use of a given module or a group of modules of the currently developed software. The reuse of software is expected to save development resources, shorten the development period, and provide higher quality modules.
  Example Space: A software development unit has been required to develop a software system for the operation and control of a hotel swimming pool that serves hotel guests and members of a pool club. Although the management did not define any reusability requirements, the unit’s team leader, after analyzing the information processing requirements of the hotel’s spa, decided to add the reusability requirement that some of the software modules for the pool should be designed and programmed in a way that will allow its reuse in the spa’s future software system, which is planned to be developed next year.
• Interoperability: 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). Interoperability requirements can specify the name(s) of the software or firmware for which interface is required. They can also specify the output structure accepted as standard in a specific industry or applications area.
  Example Space: The firmware of a medical laboratory’s equipment is required to process its results (output) according to a standard data structure that can then serve as input for a number of standard laboratory information systems.

Know more by: https://books.google.com.bd/books/about/Software_Quality_Assurance.html