It is now understood that software metrics alone are not enough to characterize software quality. To cope with this problem, most of advanced and/or industrially validated quality models aggregate software metrics: for example, cyclomatic complexity is combined with test coverage to stress the fact that it is more important to cover complex methods than accessors. Yet, aggregating and weighting metrics to produce quality indexes is a difficult task. Indeed, certain weighting approaches may lead to abnormal situations where a developer increasing the quality of a software component seeing the overall quality degrade. Finally, mapping combinations of metric values to quality indexes may be a problem when using thresholds. In this paper, we present the problems we faced when designing the Squale quality model, then we present an empirical solution based on weighted aggregations and on continuous functions. The solution has been termed the Squale quality model and validated over 4 years with two large multinational companies: Air France-KLM and PSA Peugeot-Citroen.

This document presents the Squale Software Quality Model as defined by Qualixo. It first reviews existing quality models and presents the Squale model with its particular- ity, namely a practice layer. Then it reviews in details an instance of this Squale Model with its Factors, Criteria and Practices, giving precise definitions and description1. Fi- nally, it discusses possible future enhancements of this model like new practices or its agreement with the program life-cycle and the change of needs during this life cycle.

The Squale project was born from industrial effort to control software quality. Its goals are to refine and enhance Qualixo model, a software-metric based quality model already used by large companies in France (Air France-KLM, PSA Peugeot-Citroen) and to support the estimation of return on investment produced by software quality. Qualixo model is a software quality model based on the aggregation of software metrics into higher level indicators called practices, criterias and factors. The coordination of Squale is carried out by Qualixo.

ISO 9126 promotes a three-level model of quality (factors, criteria, and metrics) which allows one to assess quality at the top level of factors and criteria. However, it is difficult to use this model as a tool to increase software qualityIn the Squale model, we add practices as an intermediate level between metrics and criteria. Practices abstract away from raw information (metrics, tool reports, audits) and provide technical guidelines to be respected. Moreover, practice marks are adjusted using formulae to suit company development habits or exigences: for example bad marks are stressed to point to places which need more attention.The Squale model has been developed and validated over the last couple of years in an industrial setting with Air France-KLM and PSA Peugeot-Citroen.

Following previous work on displaying static data dependences and experience with large sets of dependence displaying strategies, we developed a tool for visualizing dynamic data dependences. Our prototype is based on a modified Lisp interpreter and this paper presents our evaluation of its application to a highly complex AI program. This permitted us to build efficient visualizations and to evaluate the benefits of using dynamic dependences for program understanding, debuging and correctness checking. In this paper, we present our prototype, detailing especially the different visualizations we introduced to allow users to deal with hard to understand programs, and we discuss our findings working with dynamic dependencies.

We propose a new paradigm to query information about programs, namely query by outlines. This paradigm relies on an outlining model that conceptually describe units of code according to the computations they perform. Outlines are automatically constructed by our system PRISME for C and Lisp programs. Currently, both our model and our system are restricted to loops.QBO is a prototype tool that implements the query by outline paradigm. It proposes to browse the loops of a program directly through their outline, and allows to restrict these loops to browse with queries expressed as constraints on the outlines. Thus it enables to answer questions such as "where is this variable modified?", "where is this kind of computation performed?", or "are there many places where this computation is performed?".In this paper, we sketch our outlining model, introduce QBO and argue that query by outline is a helpful paradigm to manage programs.

We introduce QBO, or Query by Outlines, a tool specially developed to help explore programs. It relies on a previously implemented system able to automatically construct outlines (F. Balmas, 1997; 1998): every linear loop identified in a program is conceptualized according to the kind of computations it performs. QBO proposes an outline storage mechanism together with a query algorithm that enables outlines to be efficiently retrieved. QBO eases exploration of programs, thus program management, clone detection or plan recognition can be envisaged at lower cost; as outlines are already computed and indexed, only high level constructs have to be checked. Therefore, answering queries is a rather fast process. We sketch our outlining model, present our query tool and discuss how query by outlines may help explore programs

We report on a system developed to construct outlines of loops in C programs. It is derived from a model and a system previously defined to outline LISP loops, that have both been enhanced to handle those constructs of an imperative language like C that were out of scope in (pure functional) LISP, especially: iterative control flow structures, variable assignments, and manipulations of arrays, structures or pointers. In this paper, we first introduce our model for C loop outlining. Then we present the architecture of our system and describe the main steps of the outline construction process. We then discuss results obtained from the application of our system to two real-world programs and finally we show that this experiment gives a preview of the use of outlines as indexes for browsing and querying large scale programs.

The author proposes the re-documentation of programs with outlines. The interesting feature of outlines is that they allow one to contract, as in a zoom, the amount of information necessary to understand programs, easing the localization of given computations or identification of the role of a piece of code. As a first stage toward a framework of program outlines, she has defined a model suited to the representation of computations performed within loops. The main feature of the outlines is that they are both formal and conceptual: they are represented within frames which are semantically equivalent to the outlined loop and help understanding what is computed by revealing how this is computed. In order to re-document loops, she implemented a system, PRISME, able to automatically construct outlines of a subset of Lisp looping functions. PRISME allowed one to validate the implementation of the model. Currently, she uses it intensively to experiment the role of outlines for debugging and reverse specification of programs.

We present a pattern matcher specially developed far the parsing of LISP functions. Its main features are patterns defined by context-free grammars, parametrized patterns, multi-step matching, as well as dynamic synthesis of new patterns. We have designed a model far the conceptual description of functions, which abstracts computations performed by a function, but is still complete enough to be executable. It constitutes a key for the understanding of the function. The augmented pattern matcher is used by our system PRISME to analyze LISP functions and to synthesize conceptual descriptions. We are currently working on the extension of the system in order to handle programs and to use the conceptual descriptions as guide to program verification and optimization

In this paper, we argue that source code is not the best support for commenting programs and we introduce dependence graphs as a better support since they offer different levels of abstraction and make visible objects that are not directly represented in the source code.We first introduce our tool to display dependence graphs, focusing on how different views of the same program can be built and tuned by grouping together nodes that are syntacticallyor conceptually related. We also show how these views make visible objects of the program that aren't accessible for comment in the source code while they can be, in our tool, richly documented through typed annotations. Then we review which kinds of units can be commented this way and discuss a typical way to apply our tool to document programs. Finally, we give strategies towards the automation of program documentation.