Factor Of Software Quality By: MSMZ

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

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

McCall model By: MSMZ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

McCalls factor model tree By: MSMZ

ALTERNATIVES MODEL By: MSMZ

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

Intermediate Constructs Primary Uses Intermediate Constructs Primitive Constructs By: MSMZ

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

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

ISO 9126 Quality Factors By: MSMZ

Dromey According to http://profs.logti.etsmtl.ca 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

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

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

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

Measurement of Quality By: MSMZ

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

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

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

Thank You By: MSMZ

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

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