Fast Abstracts Archives . .
FastAbstracts
The
History
Archives
of
FastAbstracts
ISSRE
2003
ISSRE 2002
ISSRE
2001
ISSRE 2000
ISSRE 1999
ISSRE 1998
FTCS
1999
FTCS 1998
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Contrary to many other industrial processes, software production is characterized by an unusually high variance. This directly results from the significant role of the human factor in all its phases. As a result, measurements and modeling, which are predicated on the homogeneous nature of software, do not provide dependable means of process control and analysis. This points at the need to develop a new model of software that better represents software behavior. The approach is based on the empirical evidence that software defects tend to congregate to "design holes" which are deficiencies analogous to poles in linear systems (software instabilities). The new model is derived from the "fingerprints" left by software changes on the software map (see example next).
The rows represent software functionalities fi and the columns represent the timeline of software changes cj. The self-correlation chains (repeated changes of the same functionality) c1-c3-c4, c4-c6, c6-c8-c11, and c2-c6 affect functionalities f3, f5, f7 and f8, respectively. These 4 self-correlation chains are cross-correlated by software changes c4 and c6 (affecting multiple modules) to create a composite correlation graph. We construct matrix C that integrates all of the self- and cross-correlation chains and provides a relative measure of self-correlation of functionalities and cross-correlations between them. An example of matrix C is given on page 2. The values on and outside the diagonal indicate the degree of functionality self-correlation and cross-correlation, respectively. The C Matrix and Software Instabilities: Functionalities with a high level of self-correlation definitely represent areas of the software, which are subjected to a high level of repeated software changes (software instability areas). Furthermore, a cluster of several functionalities, each one being strongly cross-correlated with other functionalities inside the cluster and weakly cross-correlated with functionalities outside the cluster, will form a strongly self-correlated cluster, which represents a larger area of software instability. Evaluation of Software Architecture "Goodness": Matrix C provides a graphical description of relationships between software functionalities from the failure viewpoint. In other words, functionality i "does not exists" if it never fails (Cii = 0), and functionalities, i and j, "are not connected" if their link never fails (Cij + Cji = 0). Conversely, if Cij + Cji is very large, then functionalities, i and j, are strongly connected because both need to be repaired when one of them fails. As a result, matrix C can be used to assess the goodness of the software architecture. In principle, two strongly connected functionalities, i and j, are really one functionality, and this strong connection contributes a demerit to the software architecture. Conversely, two weakly connected functionalities, i and j, contribute to a figure of merit of the software architecture. Test Budgeting: The C matrix can be used to budget testing for new software proportionately to the size of the self-correlation (for functional testing) and of the cross-correlation (for interaction testing).
|