the correct definition of software quality assurance goes something like

8/4/2019 The Correct Definition of Software Quality Assurance Goes Something Like

1/14

The correct definition of Software Quality Assurance goes something like:-

The function of software quality that assures that the standards, processes, andprocedures are appropriate for the project and are correctly implemented.

This definition is taken from Software Definitions atNASA

The problem with this, and similar, definitions for commercial SQA practitioners are:-

It tells us little about what SQA is other than repeating the definition. That is, it usesthe defined terms assures and software. It doesnt provide a scope for someone responsible for Software Quality Assurance.

It doesnt address the role, or relationship, with Software Testing.

In its pure form under which a separate audit style group needs to be established it is

difficult to apply to a small development environment.

What is QA?

The so called Quality Movement which was first established in Japan in 1946 by theU.S. Occupation Force's,was based on W. Edwards Deming (USA) research and papers on Statistical QualityControl (SQC).

The various definitions and approaches to Quality Assurance come from Deming andother so called Quality Gurus.

The important point, for this discussion, is that these methods were applied to industrialproduction.That is the production of something tangible. Fujitsus slogan Quality built-in, withcost and performance as prime consideration,

typifies this approach. Under this approach the production process was broken down andspecified.Each process would have an output (or component) that would have a requiredspecification (measurement, weight etc.)

and these would be verified as the main product was being built.

It would be a separate group Quality Control (QC) that would measure the

components, at various manufacturing stages.QC would make sure the components were within acceptable tolerances, i.e. they didnot vary from agreed specifications.It is worth noting here that in manufacturing QC (or test and inspection) is easy todistinguish from Quality Assurance QA which is process compliance.

In Software development, however, Quality Control itself presents significantchallenges due to the intangible nature of Software.

In Software development the distinction between QC (SQC) and QA (SQA) is not as clearand these terms are often mixed. A further definition of these terms, by way of example,can be found here.

These QA methods, in manufacturing, proved themselves to work (in Sales,Customer satisfaction and the right cost of production, i.e. PROFIT) and were adopted allover the world. QA groups (for manufacturing) became the norm.

These QA groups would not take any part in the manufacture process itself but wouldmeasure and audit the process to make sure the established guidelines and standards

where being followed.The QA group would then give input (metrics or measures) into a process of continuous
http://www.hq.nasa.gov/office/codeq/software/umbrella_defs.htmhttp://www.hq.nasa.gov/office/codeq/software/umbrella_defs.htmhttp://www.hq.nasa.gov/office/codeq/software/umbrella_defs.htmhttp://www.wtec.org/loyola/ep/c6s1.htmhttp://www.sqa.net/softwarequalitycontrol.htmlhttp://www.sqa.net/softwarequalitymetrics.htmlhttp://www.sqa.net/softwarequalitymetrics.htmlhttp://www.sqa.net/softwarequalitycontrol.htmlhttp://www.wtec.org/loyola/ep/c6s1.htmhttp://www.hq.nasa.gov/office/codeq/software/umbrella_defs.htm


2/14

improvement.

In this way we could have a QC department that measures certain components atvarious manufacturing stages and have a QA department that makes sure that every

process (including QC) is following the agreed and documented procedures.

In short we had someone (QA) assuring that processes were conforming todocument standards and procedures,

hence these terms showing up in SQA and QA definitions, and this group were distinctfrom QC (i.e. testing).

So far we are in great shape in the QA and QC world of manufacturing, then someone

came up with the bright idea

Why don't we apply these proven Quality Management processes to Software?

The move to SQA and SQC

Hence SQA (and SQC) were born and with it came problems of definition and

implementation.

The definition still refers back to the traditional manufacturing QA world.There are, however, some notable differences between software and a

manufactured product.These differences all stem from the fact that the manufactured product is physical andcan be seen whereas the software product is not visible. Therefore its function, benefitand costs are not as easily measured.

The following differences highlight some of the issues in taking the manufacturingQA\QC model and applying it to software development.

The manufactured product is a physical realization of the customer requirements. The function of the product can be verified against this physical realization.

The costs of manufacture, including rework, repairs, recalls etc., are readily

categorized and visible. The benefit of the product to its user\customer are readily categorized and visible.

In order to overcome these types of issues, and reap the benefit of QA\QC applied tosoftware, other terms, models and paradigms needed to be (and were) developed.

In order to identify the Software Costs and Benefits, remembering Fujitsus term with

cost and performance as prime consideration,a number ofSoftware Characteristics where defined.These characteristics are sometimes referred to as Quality Attributes, Software Metrics

or Functional and Non-Functional Requirements.

The intention here is to breakdown the Software product into attributes that canbe measured (in terms of cost benefit).

Examples of these attributes are Supportability, Adaptability, Usability and Functionality.

There are many definitions of these Software Quality Attributes but a common one is theFURPS+ model which was developed by Robert Grady at Hewlett Packard.Under the FURPS, the following characteristics are identified:-

Functionality
http://www.sqa.net/softwarequalityattributes.htmlhttp://www-128.ibm.com/developerworks/rational/library/3975.htmlhttp://www-128.ibm.com/developerworks/rational/library/3975.htmlhttp://www.sqa.net/softwarequalityattributes.html


3/14

The F in the FURPS+ acronym represents all the system-wide functional requirements

that we would expect to see described.These usually represent the main product features that are familiar within the businessdomain of the solution being developed.

For example, order processing is very natural for someone to describe if you aredeveloping an order processing system.The functional requirements can also be very technically oriented.Functional requirements that you may consider to be also architecturally significant

system-wide functional requirements may include auditing, licensing, localization, mail,online help, printing, reporting, security, system management, or workflow.Each of these may represent functionality of the system being developed and they areeach a system-wide functional requirement.

UsabilityUsability includes looking at, capturing, and stating requirements based around userinterface issues, things such as accessibility, interface aesthetics, and consistency withinthe user interface.

ReliabilityReliability includes aspects such as availability, accuracy, and recoverability, for example,computations, or recoverability of the system from shut-down failure.

PerformancePerformance involves things such as throughput of information through the system,system response time (which also relates to usability), recovery time, and startup time.

SupportabilityFinally, we tend to include a section called Supportability, where we specify a number ofother requirements such as testability, adaptability, maintainability, compatibility,configurability, installability, scalability, localizability, and so on.

+The "+" of the FURPS+ acronym allow us to specify constraints, including design,

implementation, interface, and physical constraints.

The specification of the FURPS+ characteristics needs to go into the SystemsRequirements.

The testing of these characteristics should be done by the SQC (testing team).Some of the FURPS+ characteristics, i.e. Functionality and Usability can be tested by

executing the actual software.Some, however, like Supportability and Adaptability can only be verified by code

inspection or dry running What if? scenarios.

It is important to note that neither the SQA nor SQC group should have the responsibilityof putting the desired FURPS+ characteristic into the product.They (SQC) should only test the presence or absence of the FURPS+ characteristics.

With an established practice of defining and measuring the FURPS+ (or similar

model) characteristics it is possible to implement Software QA\QC along similarlines to manufacturing QA\QC.

This should, in theory, overcome the difficulties caused by the intangible nature ofsoftware, allowing each Characteristic of the Software to be measured (by SQC) andsubject all the processes of Software production to SQA and continuous improvement.


4/14

By way of example, consider the Supportability FURPS+ characteristic. This can be

measured by the length of time in takes to fix a defect.In order to improve this measure coding standards could be implemented. In thisscenario the SQC department would inspect the code to make sure that the coding

standard was being implemented and the SQA department would make sure the SQC andthe development group followed the process.The SQA department would also collect and analyze the time needed to repair the defect(Supportability measure) in order to give input to the usefulness of the standards as well

as to the continuous process improvement initiative.

Conclusion

The definitions for SQA and SQC originate from their manufacturing QA and QC

counterparts.SQA and SQC can be implemented in Software production as their QA and QCcounterparts are in manufacturing.In order to implement SQA and SQC (as their manufacturing counterparts) a method ofcharacterizing the intangible software product is needed.

The FURPS+ model defines a system of characterization, under which software attributescan be used by SQC to Test and Measure.

Anything that is tested and measured (by SQC) needs to be defined as a requirement,this includes the FURPS+ characteristics.SQA in Theory provides further pure SQA concepts, including the SQA role within theCMMi framework. SQA in Practice provides a jump start practical approach to establishing

Software Quality Assurance (including SQC) within a small development team.

IN THEORY

SQA, SQC and CMMI Definitions

Having positioned Software Quality Assurance SQA and Software Quality Control SQC(seeSQA Definition) within their historical context,this paper outlines an example implementation of SQA and SQC, within a CMMI contextthat matches the formal definitions of these terms.

The formal definitions that are used within this paper are:-

Software Quality AssuranceThe function of software quality that assures that the standards, processes, and

procedures are appropriate for the project and are correctly implemented.

Software Quality Control

The function of software quality that checks that the project follows its standards,processes, and procedures, and that the project produces the required internal and
http://www.sqa.net/cmmi.htmlhttp://www.sqa.net/sqa-practice.htmlhttp://www.sqa.net/index.htmhttp://www.sqa.net/index.htmhttp://www.sqa.net/index.htmhttp://www.sqa.net/index.htmhttp://www.sqa.net/sqa-practice.htmlhttp://www.sqa.net/cmmi.html


5/14

external (deliverable) products.

A further definition of SQA and SQC, by way of example can be foundhere.

CMMI

A process improvement approach to software development.

CMMiidentifies a core set of Software Engineering process areas as:-

Requirements Development

Requirements Management

Technical Solution

Product Integration

Verification

Validation

CMMI also covers other process areas, such as Process Management, ProjectManagement and Support but only the core Software Engineering development processes

are used here by way of example.

It is also interesting to note that SQA and SQC are processes defined within CMMI, they

are under the Support process area.In CMMI SQA\SQC is defined as Process and Product Quality Assurance.

CMMI is an approach to process improvement, in which SQA\SQC play a major but notexclusive role.Everyone in a software development organization takes part in both the CMMI processesand any improvement initiatives for those processes.

Each of the main Engineering process areas is now described together with the role thatSQA\SQC plays within those areas.

SQA and SQC roles in CMMI Requirements Development

The CMMI Requirements Development process area describes three types of

requirements:-customer requirements, product requirements, and product-componentrequirements.

SQA role To observe (audit) that documented standards, processes, and procedures are

followed.SQA would also establish software metrics in order to measure the effectiveness of thisprocess.

A common metric for measuring the Requirements process would be the number oferrors (found during system testing) that could be traced to inaccurate or ambiguousrequirements (note: SQC would perform the actual system testing but SQA would collect

the metrics for monitoring and continuous improvement).

SQC role SQC takes an active role with Verification (this is a process itself that isdescribed later).Verification of the requirements would involve inspection (reading) and looking for clarityand completeness.

SQC would also verify that any documentated requirement standards are followed.
http://www.sqa.net/softwarequalitycontrol.htmlhttp://www.sqa.net/softwarequalitycontrol.htmlhttp://www.sqa.net/softwarequalitycontrol.htmlhttp://www.sqa.net/cmmi-overview.htmlhttp://www.sqa.net/cmmi-overview.htmlhttp://www.sqa.net/softwarequalitymetrics.htmlhttp://www.sqa.net/softwarequalitymetrics.htmlhttp://www.sqa.net/cmmi-overview.htmlhttp://www.sqa.net/softwarequalitycontrol.html


6/14

Note there is a subtle difference between SQA and SQC with regard to standards, SQCs

role is in verifying the output of this process (that is the Requirement document itself)while SQAs role is to make sure the process is followed correctly.

SQA is more of an audit role here, and may sample actual Requirements whereas SQC isinvolved in the Verification of all Requirements.

The type of requirement need not be just the functional aspect (or customer\user facing

requirements) they could also include product and\or component requirements.

The product requirements e.g. Supportability, Adaptability and Reliability etc. arecharacteristics discussed here (as part of the FURPS+ model).

The respective roles of SQC and SQA is the same for all types of requirement (customerand product) with SQC focusing on the internal deliverable and SQA focusing on theprocess of how the internal deliverable is produced, as per the formal definition.

SQA and SQC roles in CMMI Requirements Management

The purpose of (CMMI) Requirements Management is to manage the requirements of theproject's products and product components and to identify inconsistencies between thoserequirements and the project's plans and work products.

This process involves version control of the Requirements and the relationship betweenthe Requirements and other work products. One tool used in Requirements Managementis a Traceability Matrix.

The Traceability Matrix maps where in the Software a given requirement isimplemented, it is a kind of cross reference table.The traceability matrix also maps which test case verify a given requirement.

There are other processes within Requirements Management and CMMI should bereferenced for further information.

SQA role To observe (audit) that documented standards, processes, and procedures arefollowed.SQA would also establish metrics in order to measure the effectiveness of this process.A common metric for measuring the Requirements Management would be the how manytimes the wrong Version was referenced.Another measure (for the Traceability Matrix) would be lack of test coverage,that is defects detected in the shipped product that were not tested due to the fact that

they were not referenced in the Traceability matrix that referenced the requirements.

SQC role As with the actual Requirements Development, SQC would be involved in

inspecting the actual deliverables (e.g. Traceability Matrix) from this process.

SQC may also get involved at this stage as they will be the people doing the actualTesting (Verification and Validation) so for their test coverage a complete Traceability

Matrix is essential.

SQA and SQC roles in CMMI Technical solution

The purpose of (CMMI) Technical Solution is to design, develop, and implement solutions

to requirements.

Solutions, designs, and implementations encompass products, product components, andproduct-related life-cycle processes either singly or in combinations as appropriate.
http://www-128.ibm.com/developerworks/rational/library/3975.htmlhttp://www.sei.cmu.edu/cmmi/http://www.sei.cmu.edu/cmmi/http://www-128.ibm.com/developerworks/rational/library/3975.html


7/14

This is the main Design and Coding processes.CMMI puts the design and build together. Other important processes, e.g. ConfigurationManagement are listed in other process areas within CMMI.

SQA role To observe (audit) that documented standards, processes, and procedures arefollowed.SQA would also establish metrics in order to measure the effectiveness of this process.

Clearly testing the end product against the requirements (which is itself a SQC activity)will reveal any defects introduced during this (the Technical solution) process.The number of defects is a common measure for the Design\Build phase. This metric isusually further quantified by some form of scope, for example defects per 100 lines of

code, or per function.

It is important that the defect may not always be a functional (or Customer facing defect)it could be that a required adaptability scenario is absent from the Design and\or codedsolution.The FURPS+ model references typical Software Metrics that are used for specifying the

total (both functional and non-functional) software requirements.

SQC role The major SQC role during this process will be testing (see Validation andVerification).

The finished product does not have to be present before testing can begin. Unit andComponent can both take place before the product is complete. Design and Code reviewsare also something that SQC could get involved with.

The purpose of the review has to be clearly stated, i.e. to verify standards are followed orto look for potential Supportability (part of the Product Requirements) issues. TheSupportability metric is the time it takes for a defect in a system to be fixed. This metric

is influenced by the complexity of the code, which impacts the developers ability to findthe defect.

SQA and SQC roles in CMMI Product Integration

The purpose of Product Integration is to assemble the product from the productcomponents, ensure that the product, as integrated, functions properly, and deliver theproduct. Note this is the final Integration and move to production or product delivery.For large Software packages (consider SAP, Oracle Financials etc.) the assembly processis huge and the potential for errors is high. This process does not involve any coding butpure integration and\or assembly. SQA role: To observe (audit) that documentedstandards, processes, and procedures are followed. SQA would also establish metrics in

order to measure the effectiveness of this process. One measurement for this would be

the defects found that resulted from the interface specifications (part of the Productrequirements), potential process improvements could be to find other, perhaps less

ambiguous ways, of specifying interfaces. For example a development team may move toXML or Web Services for all interfaces, SQA could then measure the defects and reportback to management and development as to the effectiveness of this change. SQC role:Again testing would be a large role played by SQC. Systems Integration Testing (SIT)

would be carried out by SQC. Also install ability testing would be done during thisprocess.

SQA and SQC roles in CMMI Verification

The purpose of Verification is to ensure that selected work products meet their specifiedrequirements Theses activities are only carried out by SQC, the role of SQA would be tomake sure that SQC had documented procedures, plans etc. by audit. SQA would alsomeasure the effectiveness of the Verification processes by tracking defects that were
http://www.sei.cmu.edu/cmmi/http://www.sei.cmu.edu/cmmi/


8/14

missed by SQC during Verification. Note the term Verification, as opposed to Validation

(see below). In essence Verification answers the question Are we building the productcorrectly while Validation answers the question Are we building the correct product.Validation demonstrates that the product satisfies its intended purpose when place in the

correct environment while Verification refers to building to specification. The FURPS+model identifies both Customer and Product requirements; Verification applies to boththese types of requirements and can be applied to the intermediary work products.Design or Code reviews are examples of Verification. These terms Verification and

Validation are often mixed, CMMI makes this comment about the distinction:- Althoughverification and validation at first seem quite similar in CMMI models, on closerinspection you can see that each addresses different issues. Verification confirms thatwork products properly reflect the requirements specified for them. In other words,

verification ensures that you built it right. While SQC carries out all the Verificationactivities the Verification process itself is still subject to SQA and process improvement.

SQA and SQC roles in CMMI Validation

Validation confirms that the product, as provided, will fulfill its intended use. In other

words, validation ensures that you built the right thing. As with Verification, Validationis mainly the domain of SQC. The term Acceptance Test could also apply to Validation, in

most cases the Acceptance test is carried out by a different group of people from theSQC team that performed Verification, as the product was being built. In the case wherean application is going to be used internally, then the end user or business representativewould perform the Acceptance testing. Wherever this is done it is in essence a SQC

activity. As with Verification, SQA makes sure that these processes conform to standardsand documented procedures. The Validation process itself is subject to continuousimprovement and measurement.

Conclusion

Although only a high level snapshot has been given of how some SDLC processes are

subjected to SQA and SQC a clear pattern can be seen. In all cases the SQA and SQC donot get involved in building any of the products. SQC are only involved in Verification andValidation. The role of SQA is even more removed from development; they are mainlyproviding the role of an Auditor. In addition SQA will collect measurements of theeffectiveness (and cost) of the processes in order to implement continuous process

improvement. This separation of SQC from development and SQA from SQC ensuresobjectivity and impartiality. In an ideal environment theses (Development, SQC andSQA) would be three separate organization units reporting to different managers. Someof the benefits of SQA\SQC can be achieved in a less formal environment. This hybridapproach is typically used by small development groups. An example of this hybridapproach is documented here at SQA in Practice.

IN PRACTICE

SQA, SQC in the Commercial Workplace

Having discussed a basic definition of Software Quality Assurance SQA and SoftwareQuality Control SQC as well as a formal implementation of these defined terms, thispaper documents a typical (or hybrid) framework which benefits from the main goals ofSQA\SQC without the organizational structure of the pure implementation.
http://www.sqa.net/sqa-practice.htmlhttp://www.sqa.net/sqa-practice.html


9/14

First a caveat, the danger in environments where SQA\SQC is not formally implementedis that the Quality Group becomes a kind of Engineering Services group and do whatever the main development team does not currently (or does not want to) do. In many

environments the SQA\SQC team reports to an application development manager andthe Engineering Services approach is very attractive to this manager. For example, letssay performance is an after thought that is not specified as a non-functionalrequirement, not designed into the system but noticed when things go wrong. Under the

Engineering Services scenario it is tempting for the manager to send the QA person ona LoadRunner (or other load testing tool course) install the tool and declare the QAperson our performance expert. This type of approach will not work, the QA teammember should be able to perform load testing (as part of SQC) but the performance

requirements (that are tested for) should be part of the requirements and theDesigner\Programmer should own the performance objective.

So, accepting that SQA\SQC have to be separate from development activities and certain(mainly Requirement and Design) activities always need to take place, lets look at ahybrid, or generalized, approach to SQA. SQA and SQC will be referred to as Software QA

and the activities of this person(s) represent a good ROI for achieving the goals ofSQA\SQC with a limited resource.

Note: This is only a sample of SDLC activities but role of Software QA against these

activities should illustrate the kind of roles that a general Software QA person shouldundertake.

SQA and SQC roles against generic SDLC

RequirementsThis is the starting point, everything flows from the requirements. Templates should beestablished, that can be referenced during reviews, which have sections for all Functional

and Non-Functional requirements (see FURPS+). For example the performancerequirements should be stated in terms of user population and transaction rates, in thisway it will not be an after thought. A Traceability Matrix should also be started to assistRequirements Management. The Traceability matrix not only helps with test coverage but

also encourages the analyst to reference individual requirements, so that they can becrossed reference.

Role of Software QA, this role verifies that the Requirements conform to the basicstandard (Templates) and the requirements are free of any ambiguities. In terms ofcompleteness, Software QA would also review the risks of not completing the Non-

functional section. The Software QA would also review the Traceability Matrix in order tomake sure all requirements were referenced.

Test Cases

At this stage, some test cases that refer to the requirements could be written bySoftware QA and cross referenced in the Traceability Matrix. In many cases this exercisewill further verify the Requirements, as test cases (with data) are being built.

Interface SpecificationIf the system is component based then an Interface Specification should be produced.Again templates should exist for this. This document should be subjected to Verificationby SQA.

Other Specifications


10/14

Lower level specifications (for commercial applications) should only be subjected to

Software QA if they are critical (i.e. main loan rate calculations) modules. In generalpaying attention to Interfaces and the Requirements (Functional and Non-Functional) willprovide a good ROI for limited Software QA resources.

Unit testingThis should be done by the developers themselves.

Component TestingIf a harness (Web Services or HTTP) is available, then Software QA should get involvedwith this grey box testing. The test cases can be written ahead of time, by the SoftwareQA team. For this reason the Interface Specification is an important deliverable.

Integration TestingThe actual staging and verification of the basic hand shake should be done by thetechnical development team. If the systems dont talk then the Software QA teamshould not be involved. Once a component is integrated then Software QA can executethe Integration Testing.

SQA of Interface Specifications Both component and Integration testing will providegood measures on how effective the Interface Specification was. These measures willprovide good feedback for continuous improvement of the Interface Specification process

and documentation.

System Test against the RequirementsFollowing a complete system being built, Software QA should execute the main System

test cases that validate the system against the requirements, this phase of the SDLC iswhat most people associate with the term software testing.

Acceptance TestingThis should be owned and executed by representatives of the sign

off team. For small changes this could be Software QA.

Defect Tracking and Resolution

Software QA should track all defects, retest until testing is complete. During this processSoftware QA should determine the origin of the defect. If the defect was introduced as aresult a misunderstanding of the Requirements then this information should feed into theRequirements Development process improvement initiative.

Regression TestingSoftware QA should have a documented set of test cases that can verify if any

component or function, not already tested as part of a release, has been negativelyimpacted by the new change.

Performance Testing

Software QA should run some performance tests to verify performance parameters(response times etc.) are within the requirements. If performance issues are found thenthe development team needs to be involved in diagnosing and resolution

Move to ProductionThis should be verified by Software QA but the actual process should be carried out bysomeone else.

Support Software QA should analyze the origin of the defects and examine the SDLC todetermine where the defect was introduced (Requirements\Design or Coding) and reviewthese with the process owners for possible improvements.
http://www.software-testing.net/http://www.software-testing.net/


11/14

Conclusion

Software QA, as defined, can mix the formal SQA\SQC activities but the overridingprinciple that they remain independent from the actual Software production activitiesshould still hold. As soon as Software QA owns the build process or does UsabilityDesign or is the performance engineer or has some other non-QA role then you havemoved to an Engineering Services model and real SQA\SQC is compromised.

SOME ARTICLES

Software Quality Attributes

Article Purpose

The purpose of this article is to define the term software quality attributes and to placethat term in the context of SQA and software process improvement, SPI.

To consider the function of software quality attributes (also known as software quality

factors) lets revisit the overall goal of any quality management, namely Fujitsus sloganQuality built-in with cost and performance as prime consideration.Given the intangible and abstract nature of software, researchers and practitioners have

been looking for ways to characterize software in order to make the benefits and costsmore visible (for measurement). This quest continues today but there have been twonotable models of software quality attributes:-

McCall (1977)

Boehm (1978)

There are others (seeFURPS) but these two illustrate the general purpose and issues ofthese quality factor models.These two quality models are summarized below and similarities can be seen.

To begin with there are some common objectives of these models, namely:-

The benefits and costs of software are represented in their totality with no overlap

between the attributes. The presence, or absence, of these attributes can be measured objectively.

The degree to which each of these attributes is present reflects the overall quality of

the software product. These attribute facilitate continuous improvement, allowing cause and effect analysiswhich maps to these attributes, or measure of the attribute.

Both the measurement (software metrics) of these attributes and the use of the software

metrics in software process improvement, SPI, are discussed in other articles.
http://www.sqa.net/index.htm#furpshttp://www.sqa.net/index.htm#furpshttp://www.sqa.net/index.htm#furpshttp://www.sqa.net/index.htm#furps


12/14


McCall's Quality Model - 1977

Jim McCall produced this model for the US Air Force and the intention was to bridge the

gap between users and developers. He tried to map the user view with the developer'spriority.

McCall identified three main perspectives for characterizing the quality attributes of asoftware product.

These perspectives are:-

Product revision (ability to change).

Product transition (adaptability to new environments).

Product operations (basic operational characteristics).

Product revisionThe product revision perspective identifies quality factors that influence the ability to

change the software product, these factors are:- Maintainability, the ability to find and fix a defect. Flexibility, the ability to make changes required as dictated by the business.

Testability, the ability to Validate the software requirements.

Product transitionThe product transition perspective identifies quality factors that influence the ability toadapt the software to new environments:- Portability, the ability to transfer the software from one environment to another.

Reusability, the ease of using existing software components in a different context. Interoperability, the extent, or ease, to which software components work together.

Product operationsThe product operations perspective identifies quality factors that influence the extent to

which the software fulfils its specification:- Correctness, the functionality matches the specification.

Reliability, the extent to which the system fails.

Efficiency, system resource (including cpu, disk, memory, network) usage. Integrity, protection from unauthorized access. Usability, ease of use.

In total McCall identified the 11 quality factors broken down by the 3 perspectives, aslisted above.

For each quality factor McCall defined one or more quality criteria (a way ofmeasurement), in this way an overall quality assessment could be made of a given

software product by evaluating the criteria for each factor.For example the Maintainability quality factor would have criteria ofsimplicity,conciseness and modularity.

Boehm's Quality Model - 1978

Barry W. Boehm also defined a hierarchical model of software quality characteristics, in


13/14


trying to qualitatively define software quality as a set of attributes and metrics(measurements).

At the highest level of his model, Boehm defined three primary uses (or basic software

requirements), these three primary uses are:-

As-is utility, the extent to which the as-is software can be used (i.e. ease of use,reliability and efficiency). Maintainability, ease of identifying what needs to be changed as well as ease of

modification and retesting. Portability, ease of changing software to accommodate a new environment.

These threeprimary uses had quality factors associated with them , representing thenext level of Boehm's hierarchical model.

Boehm identified seven quality factors, namely:-

Portability, the extent to which the software will work under different computer

configurations (i.e. operating systems, databases etc.). Reliability, the extent to which the software performs as required, i.e. the absence of

defects. Efficiency, optimum use of system resources during correct execution.

Usability, ease of use.

Testability, ease of validation, that the software meets the requirements.

Understandability, the extent to which the software is easily comprehended with

regard to purpose and structure. Flexibility, the ease of changing the software to meet revised requirements.

These quality factors are further broken down into Primitive constructs that can bemeasured, for example Testabilityis broken down into:- accessibility,communicativeness, structure and self descriptiveness. As with McCall's Quality Model,the intention is to be able to measure the lowest level of the model.

Summary of the two models

Although only a summary of the two example software factor models has been given,some comparisons and observations can be made that generalize the overall quest tocharacterize software.

Both of McCall and Boehm models follow a similar structure, with a similar purpose. Theyboth attempt to breakdown the software artifact into constructs that can be measured.Some quality factors are repeated, for example: usability, portability, efficiency andreliability.

The presence of more or less factors is not, however, indicative of a better or worsemodel.

The value of these, and other models, is purely a pragmatic one and not in the semanticsor structural differences.The extent to which one model allows for an accurate measurement (cost and benefit) of

the software will determine its value.

It is unlikely that one model will emerge as bestand there is always likely to be othermodels proposed, this reflects the intangible nature of software and the essential
http://www.sqa.net/softwarequalitymetrics.htmlhttp://www.sqa.net/softwarequalitymetrics.html


14/14


difficulties that this brings. The ISO 9126 represents the ISO's recent attempt to define aset of useful quality characteristics.

McCall (1977)

Boehm (1978)A more in depth discussion of these two models can be found here
http://www.sqa.net/iso9126.htmlhttp://www.comp.dit.ie/rfitzpatrick/papers/quality01.pdfhttp://www.comp.dit.ie/rfitzpatrick/papers/quality01.pdfhttp://www.sqa.net/iso9126.html

the correct definition of software quality assurance goes something like

Documents