Analysis of Software Quality Models For Organizations: Dr. Deepshikha Jamwal
Analysis of Software Quality Models For Organizations: Dr. Deepshikha Jamwal
by the user. It covers correctness, reliability, Boehm [1976, 1978] introduced his quality model to
efficiency, integrity and usability criteria. (ii) automatically and quantitatively evaluate the quality
Product revision is the ability to undergo changes, of software. This model attempts to qualitatively
including error correction and system adaptation. It define the quality of software by a predefined set of
covers maintainability, flexibility and testability attributes and metrics. Boehm‟s quality model
criteria. (iii)Product transition is the adaptability to represents a hierarchical structure of characteristics,
new environments, distributed processing together each of which contributes to the total quality. The
with rapidly changing hardware. model begins with the software‟s general utility, i.e.
It covers portability, reusability and interoperability the high level characteristics that represent basic
criteria. Not all the software evolvability sub high-level requirements of actual use. The general
characteristics are explicitly addressed in this model. utility is refined into a set of factors and each factor is
Analyzability is not explicitly included as one of the composed of several criteria which contribute to it in
perceived aspects of quality. However, as the model a structured manner. The factors include: (i)
is further detailed into a hierarchy of factors, criteria portability; (ii) utility which is further refined into
and metrics, some of the measurable properties and reliability, efficiency and human engineering; and
metrics are related to the achievement of (iii) maintainability which is further refined into
analyzability, e.g. simplicity and modularity. testability, understandability and modifiability.
Architectural integrity is not covered in the model. Neither in the Boehm quality model is all the
Moreover, none of the factors or quality criteria in software evolvability sub characteristics explicitly
the model is related to architectural integrity with addressed. Analyzability is partially addressed
respect to the understanding and coherence to the through the characteristic understandability, which
architectural decisions. This model is proposed for describes that the purpose of the code is clear to the
general application systems, and thus the domain- inspector. However, none of the factors or
specific attributes are not explicitly addressed in the measurable properties describes the capability to
scope of the model. analyze the impact at the software architecture level
due to a change stimulus. Architectural integrity is
1.2 ISO 9126 Software Quality Model not covered in the model.
ISO 9126 is an international standard for the 1.4 Dromey’s Software Quality Model
evolution of software. The standard is divided into
four parts which address respectively the following Dromey‟s proposes a working framework for
subjects: Quality model, External metrics, internal evaluating Requirement determination, design and
metrics and quality in use metrics. ISO 9126 Part-1 is implementation phases. The framework consists of
an extension of previous work done by McCall three models, i.e. Requirement quality model, Design
(1977), Boehm (1978), FURPS etc. ISO 9126 quality model and Implementation quality model. The
specifies and evaluates the quality of a software high-level product properties for the implementation
product in terms of internal and external software quality model include: (i) Correctness evaluates if
qualities and their connection to attributes. The some basic principles are violated, with functionality
model follows the factor-criteria-metric model and and reliability as software quality attributes; (ii)
categorizes software quality attributes into six Internal measures how well a component has been
independent high-level quality characteristics: deployed according to its intended use, with
functionality, reliability, usability, efficiency, maintainability, efficiency and reliability as software
maintainability and portability. Each of these is quality attributes; (iii) Contextual deals with the
broken down into secondary quality attributes, e.g. external influences on the use of a component, with
maintainability is refined into analyzability, software quality attributes in maintainability,
changeability, stability, testability and compliance to reusability, portability and reliability; (iv) Descriptive
standards, conventions or regulations. One may also measures the descriptiveness of a component, with
argue if the enhancement-with-new features type of software quality attributes in maintainability,
change is embedded within the types of modifications reusability, portability and usability. In this model,
defined in the quality model, i.e. corrections, characteristics with regard to process maturity and
improvements or adaptations of the software to reusability are more explicit in comparison with the
changes in environment, requirements and functional other quality models. However, not all the
specifications. evolvability sub characteristics are explicitly
addressed in this model. Analyzability is only
1.3 Boehm’s Software Quality Model partially covered within the contextual and
descriptive product properties at individual
International Journal of Latest Trends in Computing (E-ISSN: 2045-5364) 21
Volume 1, Issue 2, December 2010
component level, though none of these product This section discusses the chosen research
properties describes the capability to analyze the methodology. A discussion of alternative research
impact at the software architecture level due to a methods is included in Appendix at the last of
change stimulus. Architectural integrity is not fully conclusion.
addressed despite the design quality model takes into
account explicitly the early stages (analysis and I. The First method selected will use questionnaires
design) of the development process. The focus of the to measures the impact of lifecycles on the factors
design quality model is that a design must accurately that influence the outcomes of software project. The
satisfy the requirements, and be understandable, resultant data will be used to drive a model selection
adaptable in terms of supporting changes and framework. Which will suggest how suggest how
developed using a mature process. However, it is not suitable a lifecycle model is for a given project. The
sufficient for capturing architectural design decisions. framework recommendations will be examined and
Extensibility is not addressed as an explicit discussed using a set of case studies.
characteristic to represent future growths. Testability
is implicitly embedded in the internal product 2 Questionnaires provide „a structured approach to
property. Domain-specific attributes are not gathering date‟ and that „closed questions, providing
addressed. Moreover, one disadvantage of the a limited list of responses, ensures easy transcription
Dromey model is associated with reliability and for processing‟. This makes closed questions suitable
maintainability, as it is not feasible to judge them for gathering lifecycle impact data, while open
before the software system is actually operational in questions can be used to solicit and would typically
the production area. be gathered from free-text entry boxes.
1.5 FURPS Software Quality Model 3. In my experience, project lifecycle model choice is
often made automatically and without consciously
The characteristics that are taken into consideration considering alternative models. This suggests
in FURPS model [9] are: volunteers may need time to gather their thoughts
(i) Functionality includes feature sets, capabilities before answering model selection questions.
and security; Questionnaires are ideal in this situation, since there
(ii) Usability includes human factors, consistency in is no (realistic) set time limit for completing them.
the user interface, online and context-sensitive help,
wizards, user documentation, and training materials;
(iii) Reliability includes frequency and severity of
3. ANALYSIS/COMPARISON
failure, recoverability, predictability, accuracy, and
In this research paper, we have studied different types
mean time between failure (MTBF);
of software quality models like McCall, ISO 9126,
(iv) Performance prescribes conditions on functional
Dromey‟s etc. From the 17 characteristics, only one
requirements such as speed, efficiency, availability,
characteristic is common to all quality models, that
accuracy, throughput, response time, recovery time,
is, the „reliability‟. Also, there are only three
and resource usage;
characteristics (i.e. „efficiency‟, „usability‟ and
(v)Supportability includes testability, extensibility,
„portability‟) which are belonging to four quality
adaptability, maintainability, compatibility,
models. Two characteristic is common only to three
Configurability, serviceability, installability, and
quality models, that is, the „functionality‟ and
localizability / internationalization. Architectural
„maintainability‟ characteristics. Two characteristic
integrity is not covered in the model. None of the
belong to two quality models, that is, the „testability‟
characteristics or sub characteristics in the model is
and „reusability‟ characteristics. And, nine
related to architectural integrity with respect to the
characteristics (i.e. „flexibility‟, „correctness‟,
understanding and coherence to the architectural
„integrity‟ and „interoperability‟ in McCall‟s quality
decisions. Moreover, one disadvantage of this model
model; „human engineering‟, „understandability‟ and
is that it fails to take account of the software
„modifiability‟ in Boehm‟s quality model;
portability. Domain-specific attributes are not
„performance‟ and „supportability‟ in FURPS quality
addressed either in the model.
model) are defined in only one quality model.
Furthermore, it can be noted that the „testability‟,
„interoperability‟ and „understandability‟ are used as
factors/attributes/characteristics in some quality
2. METHODOLOGY models. However, in ISO 9126-1, these
factors/attributes/characteristics are defined as sub
International Journal of Latest Trends in Computing (E-ISSN: 2045-5364) 22
Volume 1, Issue 2, December 2010
characteristics. More specifically, the „testability‟ is 3. Choose a model. Based on elements you
belonging to the „maintainability‟ characteristic, the selected in step 2.
„understandability‟ is belonging to the „usability‟ 4. Develop details and examples to explain the
characteristic, and the „interoperability‟ is belonging software quality factors which are most
to the „functionality‟ characteristic. From our point of important to your organization. These will
view, the ISO 9126-1 quality model is the most help communicate priorities to your teams.
useful one since it has been built based on an 5. Build the quality factors and the quality
international consensus and agreement from all the model into your development and test
country members of the ISO organization. methodologies.
6. If you have accomplished the steps above,
1. There are some criteria‟s/ goals that support you have organized a software development,
McCall model are: Correctness, Maintainability, test and quality process which
Testability, Flexibility, Reliability, Usability, systematically addresses the software quality
Interoperability elements which match your organization‟s
Reusability, Integrity, Efficiency, and Portability. strategic goals. But things change, so
periodically recalibrate with your staff and
2. There are some criteria‟s/goals that support Boehm customers to ensure agreement on goals and
model are: Testability, Understandability, Efficiency priorities.
Modifiability, Reliability, Portability, and Human
Engineering. 4.1 Recommendations
3. There are some criteria‟s/goals that support ISO Step1. Identify a small set of agreed-upon, high-
9126 model are: Reliability, Maintainability, level quality attributes, and then, in a top-down
Portability, Usability, Functionality, and Efficiency. fashion decompose each attribute into a set of
subordinate attributes.
4. There are some characteristics/attributes/goals that
support FURPS model is: Reliability, Usability, Step2. Distinguish between internal and external
Functionality Performance, and Supportability. metrics.
5. There are some characteristics/attributes/goals that Step3. Identify type of users for each high-level
support Dromey‟s model are: Maintainability, quality attributes.
Reliability, Efficiency, Usability, Portability,
Reusability, Functionality. Step4. Put the pieces together; constructing the
new models that implement ideas from
4. PROPOSAL international standards: ISO-9126, Drome,
ISO.IEC TR 15504-2, and accordingly recognize
1. Define your organization‟s need and goals for appropriate Stakeholders for each set of attributes.
software quality. If you don‟t know what your
organizations need in terms of quality, you should 5. CONCLUSION
not waste time on a software quality model.
Answer the following questions: We have studied different types of software quality
models in software engineering each of these quality
What are your customer quality priorities? models consists of number of characteristics.
Do you have processes in place to monitor Selecting which one of the quality models to use is a
customer preferences? real challenge. In this paper, we have discussed and
How do your customers feel about your products compared the following quality models:
and services versus those of yours competitors?
Do you have special needs such as regulations or 1. McCall‟s Quality Mode.
safety concerns? 2. Boehm‟s Quality Model.
Do you have special needs such as regulations or 3. Dromey's Quality Model.
safety concerns? 4. FURPS Quality Model.
Do you have contractual or legal requirements to 5. ISO 9126 Quality Model
use a particular model?
Based on the discussion of the five quality models
2. Identify which quality elements are most and on the comparison between them, the following
important to your business goals. comments could be written:
International Journal of Latest Trends in Computing (E-ISSN: 2045-5364) 23
Volume 1, Issue 2, December 2010
1. In McCall‟s quality model, the quality is [6] R. G. Dromey, “A model for software product quality”,
subjectively measured based on the judgment on the IEEE Transactions on Software Engineering, 21(2):146–
person(s) answering the questions („yes‟ or „no‟ 162, 1995.
questions). [7] Breivold, H.P. et.al, „Using Software Evolvability
Model for Evolvability Analysis‟, Mälardalen University,
2. Three of the characteristics are used in the ISO 2008.
9126-1 quality model as sub-characteristics from
other characteristics. [8] Forrest Shull, et.al, “Contributions to Software
Quality", IEEE Software, vol. 23, no. 1, pp. 16-18, Jan/Feb,
3. The FURPS quality model is built and extended to 2006.
be used in the IBM Rational Software Company.
Therefore, it is a special-purpose quality model, that [9] R. G. Dromey, “A model for software product quality”.
IEEE Transactions on Software Engineering, 21(2):146–
is, for the benefits of that company. 162, 1995.
7. ACKNOWLEDGMENTS
This work is partially been supported by University
of Jammu & Lovely Professional University. The
authors would like to various Software companies
and professionals for providing data, with which the
paper get framed.
REFERENCES
[1] Hoyer, R. W. and Hoyer, B. B. Y., "What is quality?”
Quality Progress, no. 7, pp. 52-62, 2001.