A Unifying Model for Software Quality

Klaus Lochmann
Technische Universitt Mnchen Software & Systems Engineering Munich, Germany

Andreas Goeb
SAP Research Software Engineering & Tools Darmstadt, Germany

lochmann@in.tum.de

andreas.goeb@sap.com

ABSTRACT
Assuring high quality of software is crucial, but a highly complex topic. It is intermingled with most disciplines of software engineering, which have developed their own quality assurance approaches. However, they lack a common foundation, which leads to loss of information between the disciplines and requires additional tracking eort. There is no comprehensive framework to describe all dierent concepts relating to software quality in a common way. In this paper we present a general quality model, providing the possibility to describe very dierent concepts related to quality. We show that our quality model is able to integrate the various concepts found in standards, quality models, guidelines, and static code checker rules. Furthermore, we show that the quality model is able to describe the interrelations of disciplines, like requirements engineering and software test, to software quality. With this quality model, we provide a common foundation for concepts related to software quality, enabling consistency and continuity of quality-related information during software development.

widely known, that the requirements engineering phase at the beginning of a development project has a big impact on the success of the developed software [2, 17]. Development artifacts created during subsequent development activities are also critical for the quality of the software. The architecture for example, created in the design phase, is known to be crucial for scalability and performance [1]. Of course, also implementation and test activities have a major inuence on the quality of the delivered software. In addition, there are special disciplines with a focus on certain quality attributes, like security engineering and usability engineering.

1.1

Problem Statement

Categories and Subject Descriptors

D.2.1 [Software Engineering]: Requirements / Specication; D.2.9 [Software Engineering]: ManagementSoftware Quality Assurance (SQA)

General Terms
Documentation, experimentation

Keywords
Software Quality

1.

INTRODUCTION

Software quality is a complex and multi-faceted topic [9]. Therefore it is intermingled with most software engineering activities and with the artifacts produced by them. It is

All the dierent disciplines and process phases in software engineering have developed their own approaches to assure the quality of the produced software. These include: Checklists and guidelines, which can be found in most disciplines. They describe ne-grained requirements that help satisfying high-level quality objectives. Style guides for source code describe how to write code that is easily understandable and modiable. Guidelines for designing user interfaces describe principles for achieving high usability. Security checklists describe possible vulnerabilities of the software and how they can be avoided. Static code analysis tools, which search for patterns and possible errors that should be avoided in source code and indicate them to the developer. Dynamic tests, which, in contrast, focus on ensuring the satisfaction of requirements by the software. Quality models, which have been developed with the goal of describing software quality. Quality models like ISO 9126 [14] and its successor ISO 25010 [15] describe high-level quality characteristics of software. These approaches are rather unconnected and not integrated. They lack a common foundation, which leads to loss of information between the dierent development phases and requires additional tracking eort. There is no comprehensive framework to describe all dierent concepts relating to software quality in a common way.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for prot or commercial advantage and that copies bear this notice and the full citation on the rst page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specic permission and/or a fee. WoSQ11, September 4, 2011, Szeged, Hungary. Copyright 2011 ACM 978-1-4503-0851-9/11/09 ...$10.00.

1.2

Research Objective

The objective of our research is to develop a general quality model, understood as in [5]: a model with the objective to describe, assess and/or predict quality. It must allow for the denition of high-level quality attributes, and for connecting them to ne-grained characteristics of software, as described in guidelines, checklists, etc. This qual-

ity model must provide the possibility to comprehensively describe very dierent concepts related to software quality.

Impacts

1.3

Contribution

Entity

Property

Attribute

We contribute a quality model that provides an integrated view on dierent concepts related to quality and brings different views on software quality to a common denominator. It does not introduce a new terminology, but rather shows how the existing ones relate to each other. We show that our quality model is able to integrate the various concepts found in standards, general quality models, domain-specic quality models, guidelines, and static code checker rules. Furthermore, we show that the quality model is able to describe the interrelations of disciplines, like requirements engineering and software test, to software quality. Using this quality model, we enable software developers and quality managers to ground all activities and concepts related to software quality on a common foundation to ensure consistency and continuity of quality-related information during software development.

Measures

Measure

Figure 1: Quality Meta-Model indicator for its mellowness. We model this as an positive impact from [redness@apple] on [mellowness@apple]. Another concept of the meta-model describes that it is possible to measure properties using a measure. While a property always is present at the entity to some degree, a measure can also express an attribute of an entity that is not a degree, e.g. the weight (in lbs). For example, a measure for redness could be the intensity of reection of light in a certain spectral composition.

2.

QUALITY META-MODEL

3.

QUALITY MODEL

In this section we introduce a meta-model for quality models. It is based on the meta-model developed in the project Quamoco1 that was published in [18, 16]. It describes the concepts a quality model consists of and the relations between them. Figure 1 shows its main concepts and relations. The main concept of the quality model is a property. In philosophy there is a consensus that properties include the attributes or qualities or features or characteristics of things. [25]. The main dierence between things and properties is that properties can be [. . . ] exemplied , whereas things cannot. [25]. A typical example for a property is redness of an apple. Properties according to this understanding are formalized in mathematics as unary relations. They are represented via a function p : X {true, f alse} that is true for each thing exemplifying the property. We generalize this concept by allowing to specify a degree to which a thing possesses a certain property. Usually, n-ary relations are seen as a more general case of properties, but not denoted properties. According to this understanding, a property is an attribute that is attached to a entity. Therefore, in our quality model, we dene a property as a tuple of an attribute and an entity. We say, the attribute characterizes the entity. For denominating attributes we usually use the noun forms of adjectives, like redness. For entities we use nouns, like apple. For the property combining redness and apple, we use the syntax [redness@apple]. Another main concept of the quality model is an Impact. It describes the inuence one property has on another property. More precisely, an impact species that the degree to which an entity has an attribute inuences the degree of which another entity has another attribute. The eect of the inuence can be either positive or negative. If the impact has a positive eect, the degree of which the entity has the target attribute is increased, if the entity has the source attribute; and vice versa for a negative impact. For example, we would like to model that the redness of an apple is an
1

http://www.quamoco.de/

An instance of the quality meta-model described in the previous section is used to describe the quality of a software product. Figure 2 shows an exemplary instance of such a quality model. Properties are depicted as rectangles and impacts as arrows. We dene dierent types of entities and categorize the properties according to them. The used entity types are: Product Entities describe parts of the software product. They may be parts of the source code, like identiers, classes, and expressions, or more abstract concepts, like the architecture of the software. Components of a graphical user interface, like buttons, text elds, etc. are represented as product entities as well. Activities describe a behavior that is conducted with or on the system. Examples for activities are business processes that are supported by the system, or activities that modify the system, like maintenance. Environment Entities describe all other types of entities that are relevant for the quality model; e.g. people conducting maintenance tasks, hardware platform the software runs on, or the development tools used to develop the software. According to these types of entities, dierent types of properties are dened: Product Properties describe properties of product entities. Here, we dierentiate between properties describing functional characteristics and those describing structural characteristics. Functional properties typically refer to the entity product and describe input/output behavior of the software. Structural properties typically refer to parts of the product and describe the source code, the user interface, etc. Traditional quality attributes take a special role that will be explained in Section 4.1.1. They refer to the entity product, because they describe attributes of the entire product. Activity Properties are properties that describe activities. Typical attributes used to characterize activities are eciency and eectiveness.

Organization

Fluctuation Static Aspects Dynamics

Situation
Environment Properties describe properties referring to environment entities. Techniques of collecting data or testing characteristics of objects are modeled using the concept of measures. Functional properties are measured by functional test cases, structural properties can be measured by static code analysis or manual inspections. For measuring environment characteristics arbitrary metrics can be used.

Product

4.

INTEGRATING EXISTING CONCEPTS

Documentation performed with the system. This interpretation of quality in Tools use is in line with the examples given by ISO 25010, which Infrastructure states the following as an example for eectiveness from the Knowledge Base viewpoint of the maintainer: How eectively can the system be maintained or Figure 4. Example Facts ported? According to our quality model, the capability to be easily maintained or ported is Obviously, the granularity of representedshown respec- diathe facts as [Eectivein the ness@Maintenance] and [Eectiveness@Porting] grams are too coarse to be actually evaluated. We follow the tively.

In this section, Figure 2 is used as a reference to explain how dierent concepts related to software quality can be expressed using our meta-model to provide an integrated view on these approaches.

4.1

Existing Quality Models

In the following, the relation of three existing quality models to our quality model is explained. We show how the central elements of ISO 25010 and Activity-based Quality Models translate into our notation. In addition, we pick a domain-specic quality model to show that our approach is also applicable on a more detailed level.

4.1.1

ISO 25010

Two commonly used quality models for describing highlevel quality attributes are ISO 9126 [14] and its successor ISO 25010 [15]. The product quality model of the ISO 25010 denes quality attributes, often also called -ilities like maintainability, security, usability, etc. Maintainability, for example, is dened as the degree of eectiveness and eciency with which the product can be modied (ISO 25010) This denition explicitly references the product, stating that maintainability is one of its characteristics. In addition, it references the activity modication (modied), stating that it is concerned with the eectiveness and eciency of this activity. Therefore, according to our quality model we express the concept of maintainability as a product property: [Maintainability@Product]. This property stays in a close relation to the property [Eectiveness@Modication], because it is only dened through the respective activity. In general, we understand -ilities as collective terms for all product properties having an inuence on a respective activity property. In this sense, we see maintainability as the collection of all product properties having an inuence on modication, and security as the collection of all product properties having an inuence on attack. Note that an activity property may also be inuenced by environment properties, whereas an -ility only refers to product-related properties. The quality in use part of ISO 25010 describes the following quality attributes: eectiveness, eciency, satisfaction, safety and context comprehensiveness. Eectiveness, for example, is dened as the accuracy and completeness with which users achieve specied goals (ISO 25010) The quality attributes eciency, satisfaction, and safety are dened in a similar manner. In this denition we see that they refer to the usage of the system by its users. Therefore, we use these quality attributes to characterize the activities

FCM approach in the situation tree by breaking down high 4.1.2 Activity-based Quality Models level facts into detailed, tangible ones which we call atomic Deissenboeck et al. [6] developed an activity-based qualfacts. An atomic fact is a maintainability. orThe main assessed must be conity model (ABQM) for fact that can cept of their decomposition either because its product without further quality model is to separate between assessment characteristics and is obvious ordescribe activities tasks conducted bythe system. there isdierent performed with/on developers no known decomposition. Activities To achieve or maintenance. A decomposition a given project measure maintainability in of these acduring system tivities now need to establish the interrelation like setting we is available in existing maintenance standardsbetween IEEE with facts and 1219. The product characteristics are aligned clear of activities. Because of the tree-like structures the structure of the product and therefore allow for a activities and facts it is sufcient to inuences of productwith decomposition. The model describes link atomic facts characteristics on the activities and gives best expressed atomic activities. This relationship is a rationale for eachby a inuence in prose. Such quality models are usually reprematrix as depicted inas illustrated in Figure5. sented as a matrix, the simplied Fig. 3.
Maintenance Analysis Concept- ImpactLocation Analysis Tools Static Aspects Dynamics Concurrency Recursion Identiers Cloning Code Format Debugger Refactoring Product Implementation Coding Modication

Situation

Figure 3: Activity-based Quality Model (Source: [6]) Figure 5. Maintainability Matrix ABQM concepts. In out what activities are ABQM The matrix points contrast to our quality model,affected by assumes a which factsthatthe cost of conducting an activity.ofOurthe atomic and each impactaggregatethe eectfromproduct allows to describes results property on model level onto higher levels in both trees because of the efexplicitly allows for dierent attributes of activities, like unamfectiveness and eciency. We interpret the eort or cost to biguous semantics of the edges. So, one can determine that conduct an activity as a measure for its eciency. concept location is affectedof Deissenboeck et al. activity- and by the names of identiers Based on the principles the based quality models for other Vice versa, cloned code has presence of a debugger. quality attributes have been constructed. Winter et al. [30] activities. The the conan impact on two maintenancesuccessfully appliedexample decepts to describe the usability of driver information syspicted here uses a Boolean relation between facts and actems 2 . The activities they dene represent a decomposition tivities and therefore merely expressesaction,existence of a of the activity interact into executing an the perceiving, interpreting, etc. as proposed by various standards on human computer interaction. they describe characteristics of the graphical user interface (GUI) as product properties.
2

It is obvious that our quality model heavily relies on

Infrastruct.

Assistive systems in cars operated while driving.

Product Properties

Functional Test Cases

Functional Test Case 1 Functional Test Case 2 Manual Inspections Checklist Item

Functional Properties

Quality Attributes

Register Customer @Product Password @Product

Structural Properties

Functional Correctness @Product

Activity Properties

Eff. & Eff. @Book flight

Attacker

Security @Product

Effectiveness @Attack

Encryption @Communication Accessibility @Product Eff. & Eff. @Perceive User

Checklist Item

Color independent @UI Element Unnec. complicated @Arith. Expression

Static Code Analysis FindBugs

INT_BAD_REM_BY_1

Maintainability @Product

Eff. & Eff. @Maintain Developer

Environment Metrics Fortified @Hardware Existence @Debugger

Environment Properties Physical Accessibility @Hardware Adequateness @Development Tools

Figure 2: Example Quality Model Examples of impacts are: (1) [Internal Consistency@Dialog Management] [Prob. of Error @Interpretation] (2) [Guardedness@Physical Interface] [Prob. of Error @Executing] The rst example describes that the consistency of the dialog management has an inuence of the probability of error in the interpretation of the output. The second example describes that the guardedness of the physical interface against unintentional activation inuences the probability of error in executing actions via the GUI. Similar to the model of usability, Wagner et al. [28] developed an ABQM for security. As activities they used attack patterns, describing misuse cases an attacker conducts on the system. An example for such an activity is cryptanalysis. A product property having an impact on this activity is for example [Appropriateness@Cryptographic Key Generation]. each of them being related to an SOA systems design property. These properties are further related to the quality attributes exibility, eectivity, reusability and understandability. To illustrate the overall approach, the design property consumability is considered here: Consumability is measured using the derived metric ANSOR (Adequately Named Service and Operation Ratio). This metric is dened to be composed of the design metrics SSNS (System Size in Number of Services), NINS (Number of Inadequately Named Services), NO (Number of Operations) and NINO (Number of Inadequately Named Operations), as shown in Figure 4.

Design Metrics
SSNS NINS

Derived Metrics

Design Properties

Quality Attributes

4.1.3

Domain-specic Quality Models

ANSOR
NO NINO

Consumability

Understandability Reusability

In order to show that our approach is also applicable on a more detailed level, we pick a domain-specic quality model, namely the Design Quality Model for SOA by Shim et al. [24], and transform it into our modeling structure. This model describes several metrics that are classied into the categories service internal, service external and system-wide, depending on their level of granularity. Based on these metrics, a set of more complex metrics is derived,

Figure 4: SOA QM Example (Source: [24]) Accordingly, the design properties coupling, cohesion, complexity, design size, service granularity and parameter

granularity are operationalized using derived metrics and related to quality attributes. Within the model, there is no explicit distinction between automatically and manually conducted measurements. For the example shown above, the values for NO and SSNS can easily be elicited automatically, whereas the adequateness of identiers (for NINS and NINO) requires manual assessment. All these concepts can easily be expressed in our notation: Design metrics naturally translate into measures. For derived metrics, however, Shim et al. often provide denitions in a way that they reect a degree to which a certain concept is fullled (e.g. the degree to which services and operations within the system are named adequately). Because of this, they can be represented as product properties: [Adequate Service and Operation Naming@System]. Design properties also translate to product properties by adding the according entities, e.g. [Consumability@Service]. Finally, the handling of quality attributes has already been discussed in section 4.1.1.

4.2

Requirements Engineering

Generally speaking, the discipline of requirements engineering deals with discovery and documentation of requirements to software products. The IEEE Glossary on Software Engineering [13] denes requirement as (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specication, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2). Hull et al. [12] dene a requirement as a statement that identies a product or process operational, functional, or design characteristic or constraint [...]. This denition highlights that a requirement describes a characteristic of a product or a process. Therefore, in our quality model a requirement is a requested property. The dierent types of requirements, like process requirements, product requirements, functional/non-functional requirements, found in literature are represented by the different types of properties within the quality model. A functional requirement, for example, translates to a functional property requested by a stakeholder. To express this connection to stakeholders, these are also depicted in Figure 2.

booking of ights. The functional property [Register Customer @Product] in the quality model describes that the respective scenario (i.e. interaction sequence) is supported by the system. The impact from [Register Customer @Product] on [Eectiveness@Book ight] explains that the support of the respective scenario by the product increases the eectiveness with which the business use case of booking ights can be conducted. The functional property can be tested using a classical functional test case. The functional test case assures that the system supports the scenario described by the property. Thus, the test case is modeled as a measure for the respective property. Another typical phenomenon of requirements renement can also be illustrated by the quality model: Often, highlevel security requirements are resulting in functional as well as non-functional requirements [11]. In our example, the stakeholder attacker wants to conduct the activity attack. The high-level security requirement thus requires that the property [Eectiveness@Attack ] must not be satised by the product. From this requirement, we derive the functional requirement that the system must be password protected (modeled as the property [Password @Product], representing the scenario that enforces password protection). Furthermore, from the general security requirement we derive the non-functional requirement that all communication lines must be encrypted. This requirement is modeled as a property [Encryption@Communication]. In general, detailed non-functional requirements translate to structural properties. An activity property like [Eectiveness@Attack ] may also be inuenced by properties of the environment. For IT security standards it is a common practice to prescribe certain conditions that have to be met by the environment. In the quality model we dene the hardware on which the software product is executed as part of the environment. The IT security chapter 8-308a of DoD 5220.22-M [7] states Safeguards shall be established that prevent [. . . ] unauthorized modication of the IS hardware and software. In the quality model this would be modeled as a property [Physical Accessibility@Hardware], describing that the hardware must only be accessible by authorized personnel.

4.2.2

Quality Requirement Approaches

4.2.1

General Requirements Approaches

Engineering

In requirements engineering usually a top-down approach is taken. First, the stakeholders and their general needs are elicited [29, 20, 17]. In the case of business information systems (e.g. BISA approach [21]), these general needs are expressed as a business specication that species all business processes of a company. Requirements regarding these business processes are described in the quality model as activity properties, e.g. the requested property [Eectiveness@Book ight] describes that the business use case of booking ights must be conducted eectively. The next step in requirements engineering is to derive system requirements out of the business use cases. This can be achieved by describing scenarios that must be supported by the software product in order to help conducting the business use case. In our example the system use case register customer was identied to be necessary to support the

In requirements engineering, approaches exist on specifying quality requirements (understood as a special case of non-functional requirements) using quality models. Wagner et al. [27] use an ABQM to derive quality requirements. In their work, the quality model is used as a knowledge repository, which can be used to derive detailed quality requirements. Their process mainly describes the steps outlined in this section: First, the stakeholders are identied, then the activities conducted by the stakeholders are searched for in the ABQM. By following the impacts in the quality model, detailed product characteristics are found, which are then translated into textual requirements. For example, the ABQM for usability expresses that the unambiguousness of the output data of a system has an inuence on the activity perceive performed by the user. The derived requirement states: The output data of the system must be unambiguous. Wagner et al. [28] used the ABQM for security (see Section 4.1.2) to derive security requirements for software sys-

tems. Luckey et al. [19] adapted the approach of Wagner et al. to meet special needs for reusing security requirements. They annotate the impacts and activities in the quality model with general project goals and project parameters. This information is then used to support the derivation of requirements from the quality model.

4.3

Quality Assurance Techniques

In this section selected topics of quality assurance are discussed. In quality assurance dierent techniques are applies, with the goal to nd and remove defects. Thus, they are obviously related to software quality. In this section the relation to our quality model is discussed.

4.3.1

Functional Software Test

Functional testing of software is dened by the IEEE Glossary [13] as Testing conducted to evaluate the compliance of a system or component with specied functional requirements. A functional test is conducted using test cases, which are a set of test inputs, execution conditions, and expected results [. . . ] to verify compliance with a specic requirement. [13]. The denition of functional software test is covered by the ISO 25010 [15] through the terms functional completeness the degree to which the set of functions covers all the specied tasks and user objectives and functional correctness the degree to which the product provides the correct results with the needed degree of precision. In the quality model, we modeled functional requirements as functional product properties. Therefore, functional test cases are modeled as measures for these properties. Functional test cases assess, whether a functional property is satised nor not. Also the relation of functional testing to functional completeness and functional correctness is represented in the quality model by the impact functional product properties have on business tasks ([E. & E.@Book ight] in Figure 2). All product properties with such an impact are subsumed by [Functional correctness@Product].

Any expression (exp % 1) is guaranteed to always return zero. Did you mean (exp & 1) or (exp % 2) instead? This rule expresses that an arithmetic expression calculates modulo 1, which obviously always evaluates to zero. This is not what the developer intended, because it does not make any sense to write a complex operation in order to express a constant value. In the quality model we express this by a product property [Unnecessarily complicated @Arith. expr.]. This property describes the fact that an arithmetic expression producing the same result could be simpler. This is in particular the case, if a complex expression yields a constant result. The FindBugs rule serves as a measure for this property. This property has an impact on the products functional correctness, i.e. on the activity [E. & E.@Use]. Furthermore, it has an impact on [E. & E.@Maintain], because a maintainer may be confused by it.

4.3.3

Inspections

Software inspections are widely used and generally accepted to be cost-ecient [10]. They can be used for various types of documents, like requirements specications, architectural designs, etc. To guide the inspectors, a large number of inspection checklists have been developed. Brykczynski [4] gives an overview of available checklists and classies them. We describe each category in brief and give examples how they can be expressed using our quality model. Checklist items of the category generally accepted programming practices describe general concepts applicable to (imperative) programming languages. Examples are: Has each eld been initialized properly before it is rst used? This rule would be modeled as a property [Initialization correctness@Field ]. Does the routine protect itself from bad input data? This rule would be modeled as a property [Data sanitation@Routine]. It describes that a routine checks and validates the input data it gets. Another category describes checklist items for a particular language describe language-specic rules that should be obeyed by developers. However, they can be more general than the automatically checkable rules of static code analysis tools. Examples are: Is the argument to sizeof an incorrect type? A common error is using sizeof (p) instead of sizeof (*p). This checklist item is modeled as a property [Correctness@Size operator ]. It describes that a size operator is correct, i.e. it represents the intention of the developer who wrote it. Checklist items in the category style issues refer to the visual presentation of the source code. Some of them are automatically checkable, others are not. Is each task name a noun phrase describing the function of the task? This checklist item is modeled as [Noun phrase@Task name]. It is not automatically testable by a static code analysis tool. Are all constant names uppercase? This checklist item is modeled as [Uppercasing@Constant name] and can be checked by a static code analysis tool.

4.3.2

Static Code Analysis

Static code analysis tools analyze the source code of a software product in order to nd anomalies, errors, and patterns that should be avoided. They perform dierent types of source code analyses, ranging from simple pattern-search to elaborated data-ow analyses. The knowledge of these anti-patterns, called rules, is usually coded into the tools. These tools usually analyze the entire source code of a system and report all locations where a rule is violated. The rules contained in such static code analysis tools represent a huge knowledge base on best practices. For some tools (e.g. Gendarme [22]) detailed documentation with examples is available online. The knowledge of such tools can be incorporated into the quality model. In [18] we showed how a quality model can be used to structure the large number of rules (usually several hundreds) and provide the possibility of aggregating the measurement results in a meaningful way. Here, we will explain this by example of the FindBugs [8] rule INT BAD REM BY 1:

Another category describes checklist items requiring nontrivial analysis eort. Examples are: Check the validity of assumptions: Under what conditions may this function be applied? Which assumptions describe those conditions? This checklist item is modeled as [Validity@Assumption]. It describes that each documented assumption of a function must be satised by the respective function. In the quality model, impacts of these properties to activities would have to be added. By reecting on these impacts, additional and valuable information is generated. Deissenboeck et al. [6] improved the acceptance of guidelines by the developers by providing rationales for each item in form of impacts. By explicitly stating the benet of adhering to guidelines, the developers are encouraged to do so.

4.4

Further Applications

In this section the relation of the quality model to further topics is explained.

4.4.1

Guidelines

Guidelines and checklists are often implicitly organized using similar concept as our quality model. We will illustrate this using the Web Content Accessibility Guidelines (WCAG) 2.0 [26] as an example.
Principle
Principle 1: Perceivable - Information and user interface components must be presentable to users in ways they can perceive. Principle 2: Operable Principle 3: Understandable Principle 4: Robust Guideline 1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background. Success Criterion 1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Benefits: Users with partial sight often experience limited color vision. Some older users may not be able to see color well. Users who have color-blindness benefit when information conveyed by color is available in other visual ways. People using text-only, limited color, or monochrome displays may be unable to access color-dependent information. Users who have problems distinguishing between colors can look or listen for text cues. People using Braille displays or other tactile interfaces can detect text cues by touch. G14: Ensuring that information conveyed by color differences is also available in text

Guideline

readers) can access the content. Therefore in our quality model it would be modeled as an activity access by tool. To each of these principles a set of guidelines is attached. Guidelines describe high-level goals that must be achieved by the software. Often they describe ne-grained activities, like the example of Figure 5 that would be modeled as an activity seeing and hearing content including separating foreground from background. For each principle a set of success criteria are given. They describe product characteristics for fullling the principle. They would be modeled as product properties. The example of Figure 5 would be modeled as a property [Color independence@UI Element]. The description of each success criterion includes a list of benets, describing why the given success criterion is important for accessibility. These benets are formulated very closely to our impacts. They give a reason why a certain success criterion supports one of the principles. Since the principles can be directly mapped to activities, the benets can be directly mapped to impacts. For the benets in Figure 5 the resulting impacts would be: (1) [Color independence@UI Element] [E. & E.@Perceive by people with limited color vision ] (2) [Color independence@UI Element] [E. & E.@Perceive by old people] (3) [Color independence@UI Element] [E. & E.@Perceive by people with color blindness] As we can see here, the activity perceive is broken into more subtle activities. To each success criterion one or more techniques are attached. They describe either in a general way how the success criterion can be satised, or they are specic for a certain technology (e.g. HTML) and give a precise instruction what to do. The general techniques would be modeled as product properties, while the technology-specic techniques can be used as measures.

Success Criterion

4.4.2

Formal Specications

Benefits

Technique

Figure 5: Structure and Example of WCAG Figure 5 shows the structure and an example of the WCAG. The WCAG consists of four main topics, called principles. Three of these principles directly refer to activities that must be supported by a system. In our quality model they are modeled as four properties, using the attribute eectiveness & eciency. The fourth principle is robustness. It describes the ease with which tools (like screen

Properties cannot only be expressed informally by prose text, but also using the language of mathematics. In the area of formal specications, there is extended work on specifying functional behavior. Temporal logic for example is used to describe the behavior of a system by specifying constraints on sequences of states over time [23]. A formula in temporal logic expresses a certain constraint on the behavior of the software. For example, such formulas might look like this: whenever a request with valid credentials is made, the system eventually grants access, or access is granted, until the authorization is revoked. Another methodology to formally specify the behavior of software is FOCUS [3]. It describes software as components with input and output channels. Constraints are then formulated on streams of messages on these input and output channels. In the context of the quality model, formal specications are one possible way to describe functional properties of the software product. A measure for such a property would be the application of a model checker, to test if the property holds.

5.

CONCLUSIONS AND FUTURE WORK

In this paper we proposed a quality model for describing dierent concepts related to software quality in an integrated

manner. We showed that our quality model is able to integrate the various concepts found in standards, quality models, guidelines, and static code checker rules. Furthermore, we described the interrelations of disciplines, like requirements engineering and software test to the concept of the quality model. Thus, we were able to show that the quality model can serve as foundation for concepts related to software quality. Due to the nature of activity-based quality models, we focused on quality attributes, relying directly to activities, like maintainability and usability. For future work, other quality attributes, like reliability and safety should be integrated into the model. Because for such quality attributes the only activity related to them is the usage of the software, a possible way would be to introduce properties like [Safety@Use]. Whether this leads to a reasonable quality model is still subject to investigation.

6.

ACKNOWLEDGMENTS

The presented work was partially funded by the German Federal Ministry of Education and Research (BMBF), grant Quamoco, 01IS08023B/D.

7.

REFERENCES

[1] L. Bass, P. Clements, and R. Kazman. Software architecture in practice. Addison-Wesley, Boston, 2nd edition, 2003. [2] M. Broy. Requirements Engineering as a Key to Holistic Software Quality. In Computer and Information Sciences ISCIS 2006, volume 4263 of Lecture Notes in Computer Science, pages 2434. Springer Berlin / Heidelberg, 2006. [3] M. Broy and K. Stoelen. Specication and Development of Interactive Systems: Focus on Streams, Interfaces, and Renement, 2001. [4] B. Brykczynski. A survey of software inspection checklists. SIGSOFT Softw. Eng. Notes, 24(1):82, 1999. [5] F. Deissenboeck, E. Juergens, K. Lochmann, and S. Wagner. Software quality models: Purposes, usage scenarios and requirements. In Proc. 7th Workshop on Software Quality (7-WoSQ), pages 914, 2009. [6] F. Deissenboeck, Stefan Wagner, M. Pizka, S. Teuchert, and J.-F. Girard. An Activity-Based Quality Model for Maintainability. In Proc. 23rd Int. Conf. on Software Maintenance (ICSM 2007). IEEE CS Press, 2007. [7] Department of Defense. National Industrial Security Program Operating Manual (NISPOM), 2006. [8] FindBugs. FindBugsTM - Find Bugs in Java Programs. [9] D. A. Garvin. What does product quality really mean. Sloan Management Review, 26(1):2543, 1984. [10] T. Gilb, D. Graham, and S. Finzi. Software inspection. Addison-Wesley, 1993. [11] C. B. Haley, R. Laney, J. D. Moett, and B. Nuseibeh. Security Requirements Engineering: A Framework for Representation and Analysis: Software Engineering, IEEE Transactions on. Software Engineering, IEEE Transactions on, 34(1):133153, 2008. [12] E. Hull, K. Jackson, and J. Dick. Requirements engineering. Springer, London, 3rd edition, 2011.

[13] IEEE. Standard glossary of software engineering terminology. IEEE Std 610.12-1990, 1990. [14] ISO/IEC. 9126 Software engineering - Product quality - Part 1: Qualiy model, 2001. [15] ISO/IEC. 25010 Systems and software engineering System and software product Quality Requirements and Evaluation (SQuaRE) System and software quality models, 2011. [16] M. Kls, K. Lochmann, and L. Heinemann. a Evaluating a Quality Model for Software Product Assessments - A Case Study. In 4. Workshop zur Software-Qualittsmodellierung und -bewertung a (SQMB 11), pages 1424. 2011. [17] G. Kotonya and I. Sommerville. Requirements engineering: processes and techniques. Worldwide series in computer science. Wiley, Chichester [u.a.], 2000. [18] K. Lochmann and L. Heinemann. Integrating Quality Models and Static Analysis for Comprehensive Quality Assessment. In Int. Workshop on Emerging Trends in Software Metrics (WETSoM 2011). 2011. [19] M. Luckey, A. Baumann, D. Mendez Fernandez, and S. Wagner. Reusing security requirements using an extended quality model. In Proc. 2010 ICSE Workshop on Software Engineering for Secure Systems, pages 17. ACM, 2010. [20] L. A. Maciaszek. Requirements analysis and system design. Addison-Wesley, Harlow, 3. ed. edition, 2007. [21] D. Mendez Fernandez and M. Kuhrmann. Artefact-based Requirements Engineering and its Integration into a Process Framework: A Customisable Model-based Approach for Business Information Systems Analysis. 2009. [22] Mono Project. Gendarme, 2011. [23] A. Pnueli. The temporal logic of programs. Foundations of Computer Science, 18th Annual Symposium on, pages 4657, 1977. [24] B. Shim, S. Choue, S. Kim, and S. Park. A Design Quality Model for Service-Oriented Architecture. In Proc. 15th Asia-Pacic Software Engineering Conf. (APSEC 08), pages 403410, 2008. [25] Swoyer and Chris. Properties (Stanford Encyclopedia of Philosophy). [26] W3C. Web Content Accessibility Guidelines (WCAG) 2.0. [27] S. Wagner, F. Deissenboeck, and S. Winter. Managing quality requirements using activity-based quality models. In Proc. 6th Int. Workshop on Software Quality (WoSQ 08), pages 2934. ACM, 2008. [28] S. Wagner, D. Mendez Fernandez, S. Islam, and K. Lochmann. A Security Requirements Approach for Web Systems. In Proc. Workshop Quality Assessment in Web (QAW 2009), 2009. [29] K. E. Wiegers. Software-Requirements. Microsoft Pr., Unterschleiheim, 2005. [30] S. Winter, S. Wagner, and F. Deissenboeck. A Comprehensive Model of Usability. In Engineering Interactive Systems, volume 4940 of Lecture Notes in Computer Science, pages 106122. Springer Berlin / Heidelberg, 2008.