Transactions on Information and Communications Technologies vol 4, 1993 WIT Press, ISSN

Transcription

1 Use of quality characteristics graphs for a knowledge-based assistance in software quality management H. Basson, M.C. Haton, J.C. Derniame Centre de Recherche en Informatique de Nancy, BP 239, Vandoeuvre-les-Nancy, France Abstract: This work aims at building a knowledge-based system for quality assurance of objects issued from different phases of the software life cycle. Firstly, some gaps detected in the widely-used software quality tree are invoked. A set of extensions is then proposed. The obtained model, or the Characteristics Multigraph of Software Quality, is intended to be used as the main framework for the system rule base. 1 Introduction In order to represent and handle knowledge about the quality of software components, the tree-like quality representation proposed by B. Boehm [4] and extended by J. McCall [6] constitutes an important starting model. Nevertheless, since we get concerned with an exhaustive representation of quality characteristics, this model seems to need extensions. After discussion of lacks detected in the present quality tree, we propose extensions aiming at capturing pieces of knowledge necessary for better quality design and management. The model, obtained after a set of extensions, is called, Multi- Graph of Software Quality Characteristics (MGSQC). This model is adopted to be a framework allowing uniform and simple representation of the software quality characteristics, their inter-dependency and the elements allowing their quantitative evaluation. In this paper, we presentfirst,the widely-used quality tree, as well as its use and some of its gaps in the representation of pieces of knowledge pertinent for quality assurance. Afterwards, we propose some extensions of the present model as well as their corresponding rational. The obtained model MGSQC is then presented to be a framework for Quality Assurance Knowledge-Based System (QAKBS), addressed to assist software quality management, to design, control and evaluate

2 808 Software Quality Management software quality characteristics, throughout the different phases of the software life cycle. A set of historical copies of MGSQC, parameterized with properties various applications and instantiated for already successfully developed and reused software, are stored by the system. These copies are intended to be used for quality design of software to be developed for similar applications. Finally, some advantages, brought by such a system for quality management, are given. More particularly, the quality rules generation for QAKBS is described. 2 Quality Tree Presentation The present widely used quality tree (usually called the F.C.M tree) is the one proposed by B. Boehm, then instantiated differently after some extensions by J. Me Call. The tree root represents the general quality; it is refined into three levels: Factor level: it represents an external view of software characteristics related to its use, reliability, maintainability, portability, etc.; * Criterion level: it represents an internal view of the software characteristics related to modularity, self-documentation, etc. The criteria express the software characteristics enabling to satisfy factors. Some of them are broken down, by Me Call, into one supplementary level of subcriteria; Metric level: it corresponds to measurements addressed to evaluate criteria. Notations Using graph theory, we illustrate below the present quality tree, and then the proposed extensions. Let GP = (X, U) be the graph representing the quality tree. With X = {%;,% = 0...nn} the set of the graph nodes, nn denoting number of nodes. U is the set of edges, and X is the union of the subsets of nodes representing the different tree elements, with X = Xo(JfuC\JM where : XQ = {XQ} is the root of the graph, and represents the most abstract term of quality or the global software quality and corresponds to level 0 of refinement; f {Fi,F2,..., Fm} represents the set of factors, issued from the first refinement of general software quality (or level 1 of refinement); C {Ci,C2,..., Cn] represents the set of criteria refining the factors, or the second level of refinement; M = {A/i, Jl/2,..., Mq] represents the set of metrics addressed to evaluate qualitatively and/or quantitatively the criteria. The elements of M are the tree leaves.

3 Software Quality Management The present Use of Quality Tree The present use of the quality tree can be summarized by the following points: 1. The quality tree constitutes an effective support to project technical quality plan. Through its instantiation, the quality manager can designate, for a current application, the expected external qualitative view of software or quality factors, and how it will be covered in terms of selected internal quality characteristics or criteria. At the third decomposition level, the tree instantiation corresponds to the selection of metrics for quantitative evaluation of software quality factors and criteria. 2. Through well-defined relationships between criteria and metrics, the quality tree constitutes a very useful and practical support for assisting the development team in the interpretation of numerical results issued from metrics. 3. Being a simple and easy-to-understand structure, the quality tree has been included in the most of the training courses in software quality. Since we intend, in our project, to use the quality tree as a framework for quality knowledge representation, some gaps are detected. They can be summarized by the following points: 1. The quality tree offers a synthetic view of quality of objects issued from different project phases, without structuring a precise view of quality per phase. 2. The tree represents only relationships between quality factors and criteria, and between criteria and metrics. The ''horizontal" interactions of evolutions between dependent quality factors (or criteria) are not represented. 3. In this tree, in spite of a notable difference of complexity between quality factors and criteria, they are broken down in a uniform way: one level of criteria is proposed by B. Boehm [5] to cover factors. In some cases, a supplementary subcriteria level is proposed by McCall [6]. Nevertheless, with some quality characteristic, such as software code complexity, it would be an oversimplification to attempt to quantify it, even after two successive decomposition into descendants of subcriteria. 4 The proposed extensions In order to meet the needs for exhaustive quality representation, and fulfill the above mentioned shortcomings, we present extensions intended to allow: 1. To manage, according to our needs, separately or globally, the quality characteristics of objects issued from the different life cycle phases. 2. To foresee the propagation of influences among quality factors and criteria. 3. To translate the instantiated graph into quality rules, which can be used by a knowledge base for software quality assurance and development. Below, We introduce successively the proposed extensions:

4 810 Software Quality Management 4.1 Extension I : A subtree per development phase The goal of this extension is to represent, for each phase of software life, its proper quality characteristics through a devoted specific subtree. As expected results, the quality factors, criteria and metrics, corresponding to each individual phase, can be then specified and separately designed. The advantage of such a partition, is based on the fact that each software life- cycle phase has its specific problems, formalism, and quality characteristics requirements, therefore; it would be better to be able to consider each phase by peculiar devoted subtree rather than a global synthetic quality tree for all phases. Another practical reason is, that the continuous increasing percentage of complex and large size software development projects, means their software life-cycle phases are more often carried out by different teams. Each team would be then concerned mainly by a subset of individual phases and has to deal directly, only with corresponding quality characteristics. So, to the objects issued from different life-cycle phases, starting from the tree root, representing the most general of the quality, we refine it into quality subtrees. We denote them by QG\, QG?,.. -iqgpm to correspond to pn phases of software life-cycle phases, where: QG\ is the quality subtree root of requirements definition objects; QG-2 is the quality subtree root of functional specification objects; # QG$ is the quality subtree root of preliminary design objects; QG4 is the quality subtree root of detailed design objects; # QGs is the quality subtree root of coding objects; $ QG& is the quality subtree root of individual testing objects; * QGj is the quality subtree root of integration objects; QGs is the quality subtree root of global testing objects; QGg is the quality subtree root of maintenance objects. 4.2 Extension II The goal of this extension is to provide the software quality management with global view on any software quality characteristic, and that is throughout the software life cycle. So, besides the above enumerated subtrees, we have added a particular synthetic one, denoted by QGpn+i ur QG\o here, it is devoted to allow global quality control and evaluation of the software considered as a whole. Any node of QG\o, is relative to a general software characteristic, and refers to characteristics of objects of different phases. The definition of any node Nd^ is based on: * an external node QGi, i = 1...9, or $ another local node QG\Q. In contrast with {QG\, QGi,.. -,QGpn}, devoted to vertical quality design and management per phase, QGio is addressed to horizontal evaluation of quality objects throughout the different phases.

5 Software Quality Management Extension III : Depth varying tree To avoid limitations on the number of refinements which can be applied on a given factor or criterion, we adopt a free depth tree, with a number of refinements varying according to the complexity of criterion. The recursive decomposition process of criteria into subcriteria stops, when the obtained descendants can be directly measurable by one or several metrics. Thus, between criteria and metrics, many levels S{ of subcriteria may be added. The set of nodes X, already defined, evolves to be such as : X = where : S= {Si, 52, - -., Sp} designates the set of p different levels of subcriteria, and : 5,- = {SC,-,i, 5C.-.2, - - -, 5Ci,nJ designates the set of subcriteria issued from the t** refinement of criteria. A criterion C, C being of level 2; a descendant subcriterion SC^k 5,-, «= 1...p, fc = 1...n,- is of level t Extension IV: Representation of inter-influences between Quality Characteristics For this extension we give first some definitions, then its description. Definitions: A tree node Nd+ X, representing a factor, a criterion or a subcriterion, obtained after h refinements, is said to be of level (or depth) h and denoted by #d,(6). Now, let us suppose that Ndi(h) is numerically evaluated by a function Val(Ndi(h)) = *(yn,#2,..., 3/m,)- y*j are parameters of which effective values may be obtained through static analysis, calculations, dialogue with the authorized user, or by reasoning. For a given software project development and its corresponding specific quality plan, we denote by: Min(Val(Ndi(h))) the minimal value of Val function; Max(Val(Ndi(h))) the maximal value of Val function; RANGE(Val(Ndi(h))) = [Min(Val(Ndi(h))).. Max(Val(Nd>(h)))] the range of variation of Val(Ndt(h)) between its two extreme values; AVal(Ndi(h)) a variation of Val(Ndi(h)); The function Val is defined such as: AVal(Ndi(h)) > 0 or positive evolution of Nd^(h) corresponds to an improvement of a quality factor, criterion, or subcriterion represented by Ndi(h). The improvement degree is quantified by &Val(Nd>(h)). * &Val(Ndi(h)) < 0 or negative evolution of Ndi(h) corresponds to a degradation of a quality factor, criterion, or subcriterion represented by Ndi(h). The degree of degradation is quantified by &Val(Ndi(h)). We define the inter-influence between nodes as follows:

6 812 Software Quality Management A node Ndi(h) is said to be of favorable evolution with respect to another node Ndj(h) if and only if: Each AVal(Ndi(h)) > 0 does not imply a AVal(Ndj(h)) < 0 and there exists at least a &Vat(Ndi(h)) C RANGE(Val(Nd,(h))) positive, which implies AVal(Ndj(h)) > 0. # A node Nd{(h) is said to be of unfavorable evolution with respect to another node Ndj(h) if and only if : Each &Val(Ndt(h)) > 0 does not imply a AVal(Ndj(h)) > 0 and there exists at least &Val(Ndi(h)) C RANGE(Val(Nd,(h))) positive, which implies Aya((7Vdj(/t))) < 0- A node Ndi(h) is said to be of neutral evolution with respect to another node Ndj(h), if and only if: Each &Val(Ndi(h)) C RANGE(Val(Ndi(h))) does not imply &Val(Ndj(h)) ^ 0. Two nodes Ndi(h) and Ndj(h) are mutually of favorable, unfavorable, neutral evolution respectively, if and only if: Ndi(h) is of favorable, unfavorable, neutral evolution respectively to Ndj(h) and reciprocally. The representation of horizontal dependency among factors, criteria and subcriteria, which belong to the same decomposition level, has been considered as necessary to foresee the dynamic of propagation of qualitative evolution of any quality characteristic^]. It has been represented here by adding horizontal edges to the quality tree. This extension is more particularly interesting for rapid estimation of qualitative modifications when any quality characteristic evolves. With this extension, each quality subtree is transformed into a quality subgraph; the whole is the MultiGraph of Software Quality Characteristics (MGSQC). In the following section, starting from the general quality specification, we show how the knowledge based-system using the MGSQC can help the quality management to take different decisions concerning the quality design, control and assessment. 5 Project management and quality management starting task A critical and preliminary step in software development is to identify for the current application, the different contextual elements which can influence the development process. This identification is followed by the effort and cost estimation to be devoted to the project. The project manager and quality responsible have afterwards to specify the expected environmental, functional and qualitative characteristics to be met by the future product. Generally, most of these should be already defined or invoked in the requirements specification documents; otherwise, the project and quality management, by interviewing and analysis, reach to obtain precise responses about the expected quality characteristics.

7 Software Quality Management 813 Between the product quality requirements to be met and the corresponding devoted human and materials resources, the project management designates, for each development phase, the allocated elements in terms of: budget, delays, development personnel competence, development environment tools. The quality management, according to decided allocation designates, for each development phase, the procedures, techniques and rules to be applied so as to reach already specified quality goals. Three different types of procedures are concerned: development procedures of specification, design, coding testing and integration, quality control procedures, and configuration and version management procedures. In this step, the knowledge-based system, by providing historical copies of MGSQC, offers an assistance for quality management. It indicates, required personnel competence, estimated budgets and delays, by reasoning on the historical data of similar software development. 6 Quality Characteristics Specification and Rules generation For the software components to be developed, the quality manager specifies the expected general quality characteristics to be assured by the development process. The specification of high-level quality characteristics produces a qualitative design of software, as it is expected from the outside. This external view of software corresponds to different quality requirements, expressed with agreement of the customer needs and system future users. That includes their preference and the different priorities they attach to various quality characteristics. That includes quality attributes such as: the easy-to-use of software, its modifiability, reliability, maintainability, portability, etc. In the Boehm's quality model, these external quality characteristics are called quality factors. The quality manager, by taking into account the priorities of the current application, defines an order of priorities between different required quality characteristics. In this activity, the QAKBS considers the specified quality goals, to prepare quality rules generation. They correspond to left hand part of future rules to be processed by the QAKBS inference engine.

8 814 Software Quality Management 7 Quality design and management As a succeeding step to the above starting task, the quality assurance manager establishes, for thefirstlevel of MGSQC, the corresponding levels of quality graphs already built for different development phases. As example, the software documentation quality, as a general quality requirement, is represented by a node of the synthesis graph QG\u (described in the extension //). To this node, corresponds a set of nodes in the QGi,i They are such as: Documentation Documentation quality of requirements specification, quality of functional specification, Documentation quality of software user manual, etc. To each element, the quality management proposes its proper weighting coefficient, reflecting the quality priorities of the current application. The same synthesis is also to be done to other general (or horizontal) quality criteria such as: software tractability and software modifiability, software reuse, etc. 7.1 Generation of Quality Rules Starting from the instantiated graph by the quality expert, we generate an important part of the rule base. At first the graph is transformed into triplets. For instance if at the kth level of refinement, a subcriterion SCj,k is a descendant of a criterion (Cj) with a weighted coefficient Wj,k, it will be represented by the graph edge (7V(Cj), N(SCj,k)) to which is associated the coefficient Wj,k- The corresponding triplet is: For example, in a modular structure, if the modular component hierarchy is considered as a subcriterion of the modularity with weighted coefficient Wi, this knowledge will be represented by the triplet: (Hierarchy Wi Modularity}. Using some first order rules for the generation of rules, the triplets will be transformed into quality rules to be included in the rule base. An example offirstorder rule is: IF (X, Wx,Y,Y) AND WX,Y > 0 THEN generate the rule: IF X is improved THEN Y is improved. We illustrate this point by giving an example relative to a criterion of software source code: the modularity. Let us suppose the quality manager has made the following choice:

9 Software Quality Management 815 Qv. C< lality GT-aph USER Inter-face =>J_<=> J Quality Expert "Triplet G enera.tionj USER Interface Rule Acquisition -M er 1 Rules for le gerxerat-iop^ Figure 1: The Generation Process of Quality rules $ As vertical relationships: - among the modularity subcriteria we have considered, just for illustration purpose, the modular components cohesion, coupling and hierarchy; - For the cohesion we have considered as example the following subcriteria: the communicational cohesion and the procedural cohesion as defined in [7] - the modular hierarchy is assessed in terms of hierarchical levels number, the average of modular components per level; - the coupling is limited to calling and importation relationships. $ As horizontal relationships: - reciprocal relationships between the communicational and procedural cohesion, where the evolution of each type of cohesion may have an impact on each other; - the modular hierarchy has a negative impact on the coupling possibilities; - the evolution of coupling may imply a positive, neutral, or negative on hierarchy; - the evolution of the number of hierarchical levels implies an evolution of the average of modular components per level. The persistent triplets corresponding to the choice just presented for vertical relationships are such as:

10 816 Software Quality Management (Cohesion (Coupling (Hierarchy (Communicational.Cohesion (Procedural.Cohesion (Calling ^Relationship (Importation-Relationship (Hierarchical-Levels-N umber (Modular -Components-Average.per -Level Where: (Hierarchy Wl Modularity) and (Cohesion W2 Modularity) and (Coupling W3 Modularity) Wl W2 W3 W12 Wli W21 W2j W31 W3k Modularity) Modularity} Modularity) Cohesion) Cohesion) Coupling) Coupling) Hierarchy) Hierarchy) Val(Modularity) - Wl * Val(Hierarchy) + W2 * Val(Coupling) + W3 * Val(Cohesio\ Another example of subgraph instantiation for Ada sources quality is presented in [3]. A set of primitives has been developed to define and manage the quality graph, a part of them has been described in [1]. These primitives belong to an integrated representation of objects and their associated quality graph. The corresponding model is presented in [2]. 8 Conclusions In the presented work, after a critical evaluation of the largely used quality treelike model, we have justified and proposed some extensions. These extensions allowed us, using the same framework, better representation, management and assessment of quality characteristics and their inter-influence, We have also described, through the proposed framework, the automatic generation of quality rules used by the inference engine of a knowledge-based system for quality assurance. A prototype validating the corresponding QAKBS has been implemented.

11 Software Quality Management 817 References [1] H. Basson, S. Bahsoun, and C. Barthelemy. Pour un noyau evolutif devaluation dans un environnement integre de genie logiciel. In Proceedings of Third International Workshop On Software Engineering and its Applications, Toulouse, France, December [2] H. Basson and J.C. Derniame. Towards an evolutive Kernel of Assessments an Ada Objects hosted an Integrated Software Engineering Environment. In ACM Proceedings of the 1th Washington Ada Symposium, pages 37-53, June [3] H. Basson and J.C. Derniame. Quality tree extensions and partial instantiation for Ada objects. In ACM Proceedings of the 8th Washington Ada Symposium, pages , June [4] B.W. Boehm. Software engineering. IEEE Transactions Computer, pages , December [5] B.W. Boehm, J.R. Brown, H. Kaspar, M. Lipow, and G.J. Me Leod. Characteristics of Software Quality. North Holland Publishing Company, The Netherland, [6] G.F. Walters J. A. McCall, P. K. Richards. Factors in Software Quality. Technical report, General Electric n 77(71502, June [7] R. Yourdon and L. Constantine. Structured Design. Yourdon Press, Prentice Hall Building, Englewood Cliffs, NJ 07632, 1979.