REP - chaRacterising and Exploiting Process components: results of experimentation Pierfrancesco Fusaro *, Maria Tortorella ** and Giuseppe Visaggio * *
DIB - Dept. of Informatica, University of Bari, Via Orabona 4, 70126 Bari, Italy
[email protected]
** Faculty of Engineering, University of Sannio Palazzo Bosco Lucarelli, Piazza Roma, 82100 Benevento, Italy
[email protected]
Abstract Software processes require continuous innovations to improve their quality and increase their maturity. Integrating process components, proposed in previous published works, to improve a process requires the formalisation of their informal description. This requirement stems from the need to understand and evaluate how adequate the process components are to the requirements of the innovation and how well they can be integrated into the software process. The approach REP, chaRacterising and Exploiting Process component, has been previously proposed by the authors. It includes a characterisation framework which serves to support the comprehension and evaluation of the process components being analysed. The aim of this paper is to verify whether the approach is effective if suitably used, by means of a controlled experiment testing the ability of the characterisation framework to formalise and evaluate a process component. The results obtained show that the framework is effective provided that the experimental subjects have been given sufficient training in its use. 1
1. Introduction In accordance with the five levels of the Capability Maturity Model [7] [8] [10] and tailoring need [1], software processes need continuous innovation to be 1
This work has been partially supported by the funds of the Italian MURST 40% and partially by the funds of the CINI (Consorzio Interuniversitario Nazionale per l’Informatica) under the project «Informatics in Public Administration», theme Nº 2, PROGRESS.
optimised and improve the quality of their products. This can be achieved by integrating innovative techniques, methods and other processes into the working software processes to be improved. Generally speaking, a process can be seen as the integration of a set of process components at different level of granularity. The term granularity refers to the particular process component being considered. The expression process component can indicate a technique, or a method, or a process, where: − a technique corresponds to an algorithm or a series of steps whose execution requires some knowledge and skill and which produces a certain effect; − a method is a particular management procedure for applying a technique; it is organised as a set of rules that evaluate, choose and establish how and when to use and to stop the application of the techniques it includes (input and output criteria); − a process is a set of methods and reciprocal interrelationship necessary to attain a specific goal (for example, to produce a deliverable). Innovation problems mainly concern either new or recently implemented software processes because these, although used in various contexts and with different aims, are still little consolidated and need continuous improvement and innovation. One approach to process improvement is founded on the reuse of process components which have previously been defined and if possible validated in known applications and experiences. This approach requires searching the literature to extract both useful suggestions for the innovation required and suitable process
1
components for integration into the existing software processes. Unfortunately, this presents some problems: • before reusing an extracted process component, it is necessary to describe it using the same formalism as the one used in the process to be improved. This task can be very difficult owing to the lack and ambiguity of the information published; • it must be possible to integrate the process component into the software process to improve; • the process component being extracted must be suited to the improvement process goals; • if more that one process components with the same purpose exist, a method is needed for choosing the most effective one with respect to the improvement goals. These problems been little dealt in the literature. In [12], [13] and [14], Song and Osterweil propose an approach for comparing project and development methods but this depends strongly on the process component being evaluated and takes no account of whether it could be integrated and made operative in the process to be improved. Discussion of these problems in greater depth is made in [15], while the lack of immediate applicability of the above approach has been demonstrated in [5]. The latter authors were only able to apply the evaluation schema to High Performance Systems after substantial modifications had been made. In [1] Basili and Romback proposed a method for evaluating the adequacy of a process component in a specific context, after characterising the project goals to be achieved and the given environment. This approach can be used to verify whether an operative process component can be replaced by an innovative one having the same purposes. It can also offer a support for evaluation of whether a candidate process component for integration in the process to be improved is suited to the new environment. However, this approach does not address the problem of understanding process components which have been informally described. The present paper describes the experimentation of the process component extraction approach REP [15]. It is a development on the method proposed by Song and Osterweil and solves the problems encountered in the latter approach by introducing a characterisation framework to support the analysis and evaluation tasks. The framework is composed of two parts: a general part that can be reused in any context and a specialised one that has to be adapted to the particular kind of process component to be analysed. This framework can evolve, being improved as new experience is gained, and modified to consider new aspects as occasion may arise. It can thus be considered as an accumulator of experience, with reference, in this case, to the comparison and evaluation of the process components. It also acts as a guide to formalising process components and helps to identify inconsistency, ambiguity and
incompleteness in the documentation published in literature. Generally speaking, when a new technology is to be adopted, even if it has solid scientific and technological basis, its effectiveness and applicability have to be evaluated, together with its ease of comprehension for a potential user. The controlled experiment presented in this paper aims to verify whether the characterisation framework improves comprehension of the process component being analysed, provided that sufficient training in its use has been given. The experimentation is based on the analysis of three innovative reverse engineering process components [3], [9] and [11]. The experiment was performed with students attending Software Engineering II, a course in the fourth year at the Department of "Informatica" of the University of Bari. The following section of this paper describes the characterisation framework proposed highlighting its adaptability to the process component to be evaluated. The third section discusses the experiment and its results and the final section presents the conclusions and outlines future works.
2. Description and use of the framework To analyse and evaluate a process component published in literature, all the necessary information must be extracted from the available documentation. Unfortunately, the documentation is often ambiguous and incomplete and it is therefore necessary to formalise the process component, reinterpreting all the information available. The Modelling Formalism adopted in this approach is the Process Conceptual Modeler (PCM), a tool in the PROMETHEUS (PROcess Model Evolution Through Experience Unfolded Systematically) environment [4]. This Modelling Formalism is based on three sets of products (WF, DR, TR), where: • WF is a set of Work Flows that define the network of activities in the process and their interfaces, represented by the deliverables. The decomposition of the Work Flows is described by a tree named the Work Flow System (WFS); • DR is a set of Derivable Reports that describe either input to the activities of the process components or output produced by them. All the deliverables of a process model form a hierarchy called Deliverable Breakdown Structure (DBS); • TR is a set of Task Reports containing the detailed descriptions of the leaf tasks in the Work Flows. Each of them is composed of five characterising elements grouped in three categories: the internal starting and ending conditions (isc e iec), the Input and Output, the
2
Procedure Scripts. The Procedure Scripts are procedures that express the control flow between a set of Basic Actions, i.e. actions that cannot be further decomposed. Instantiation of a characterisation framework for analysing and evaluating the process component is the next step after the formalisation task. The framework aims to help a software engineer to recognise those process components that satisfy the requirements of the improvement process, to evaluate them and choose the one best suited to his purposes from among a set of process components with similar features [15]. The characterisation framework is subdivided into two sections: a specification and an evaluation section. The specification section aims to determine whether the process component being analysed satisfies the requirements. It groups together the following five categories of characteristics: Input, to define the characteristics of the objects necessary for the process component to operate; Output, to define the characteristics of the objects that the process component produces; Emphasis, to identify the process component goals; Domain, to collect the characteristics that have to be satisfied by the input objects in order for processing by the process component to be possible; Environment, to express the starting state of the external environment necessary for the process component to operate, and the ending state produced by its application. The evaluation section serves to evaluate the process components, compare those satisfying the same requirements and define the risk level of adopting one of them in a software process. It takes into account the following three categories of characteristics: Techniques, to outline the technological characteristics of the process component; Formalisation, to define the rigorousness with which the process component is expressed; Quality, to express the quality of the process component and output objects produced. The characterisation framework is reusable, as a framework should be, and can be specialised for each application domain using the experience accumulated concerning the qualities necessary in the target domain. Table 1 presents the specific characterisation framework elaborated for evaluating reverse engineering process components. The reusable part of the framework consists in general questions, written in plain print, while the questions in italic represent the specialised section. The general questions are general purpose and useable in every context. Analysis has demonstrated that they extract the information required before adopting an existing process component in any kind of software
process. In fact, in forward and reverse engineering and in re-engineering it is important to be aware of the input deliverables the process component analyses and the output deliverables it produces, the requirements that have to be satisfied in the environment where it is to be applied, the techniques it adopts, formalisation used for its description, and its quality. It can be observed that some questions in the Input, Output and Environment categories refer to the specific context of the software process where the process component to be analysed is to be integrated. They help to analyse the mappability, compliance and adequacy of the candidate process components to be integrated compared with the process components previously adopted, together with the resources they provide. In fact, a candidate process component is assumed to be integrable in a software process if it is able to process the output deliverables produced by other process components (available input deliverable) and to produce (as output deliverables) the resources that other process components will then process as input (expected output deliverable). Thus, the available input deliverables must be mappable and compliant to the ones analysable by the process component, and the expected output deliverables must be mappable and compliant to the ones producible by the process component. These aspects are addressed by questions I1, I2, I5, I7, O1, O2, O5 and O7. Analogous considerations can be made about questions EN1 and EN2. All the other general questions in the framework have been constructed to evaluate the analysed process components independently of the software process that may adopt them. While the general questions in the characterisation framework can be applied to any context and are thus reusable, the specialised questions mould the framework to the particular context of the software process to be improved. The framework presented in Table 1 shows five specialised questions: I3, O3, EM1, Q5 and Q6, which the following observations will show to be specialised for reverse engineering. In reverse engineering, it is often necessary to recover the unstable knowledge residing in the minds of men who have a good working knowledge of the programs because they have interacted with them from different perspectives for many years. The aim of question I3 is the identification of the unstable knowledge used by the process component to be analysed. As previous experience suggests [16], the purpose of a reverse engineering process component can be: solely the identification of information from the input software system without any modifications (reverse engineering); some modifications to make the information extracted easier to understand (restoring); some modifications to improve its structural quality (re-engineering). Before adopting a process component, it should be known which
3
SPECIFICATION SECTION Input
I1. I2. I3. I4. I5. I6. I7.
Output
O1. O2. O3. O4. O5. O6. O7.
Emphasis Domain
EM1. D1.
Environment
EN1. EN2.
Are the input deliverable required by the process component mappable to those available? Are the input deliverable required by the process component adequate and compliant with the corresponding available input? Does the process component use the expected unstable knowledge? If the process component is language oriented, which language is it oriented to? If the process component is language oriented, is its language compliant with available language? What kind of formalisation is required to express the input deliverables? Is the kind of formalisation required to express the input deliverables compliant with the available formalization? Are the output deliverable produced by the process component mappable to the ones expected? Are the output deliverables produced by the process component adequate and compliant with the corresponding expected output? Are the output deliverables produced by the process component a modification of the Input deliverables? If the output deliverables produced by the process component are language oriented, which language are they oriented to? If the output deliverables produced are language oriented, is the language compliant with the expected language? Which kind of formalisation are the output deliverables expressed with? Is the kind of formalisation used to express the output deliverables compliant with the expected formalization? Which are the goals of the process component? Does the process component have particular requirements that the software components to be processed need to satisfy? Is the starting state in which the process component has to be applied compliant with the external environment? Is the ending state of the process component after a correct application compliant with the external environment? EVALUATION SECTION
Techniques Formalisation Quality
T1. F1. Q1. Q2. Q3. Q4. Q5. Q6.
What technology does the process component use? What formalisation level is used to describe the process component? To what extent is the process component automated? Is it possible to improve the automation solution of the process component? Does an econometric model exist? Has a quality attribute for evaluating the quality of the process component and its output deliverables been calculated? What level of the scientific maturity has the process component? What level of the experimental maturity has the process component? Table 1 - The Characterisation Framework
of the activities listed above it will perform. Question O3 aims to probe this aspect. The taxonomy introduced by Chicofsky and Cross in
[2] can help to classify a reverse engineering process component. Question EM1 has been introduced for this reason, as its answer will ascertain whether the purpose of
4
the candidate process component is compliant with the software process it is to be integrated it. Finally, the experience of real applications of processes without monitoring [6] has demonstrated that experimentally immature process components, even if they are well known and referenced, can exhibit unacceptable performances. If a software component is applied to a different environment from a research laboratory, for example, a different size of the software system it is applied to, this may lead to a worse performance. To evaluate the risks of adopting a process component in a typically innovative renewal process, questions O5 and O6 must be asked. The answers will make it possible to estimate what scientific investigations of the process component have been made and how often it has been used in other analogous industrial realities.
experimentation
The experiment took into account five independent variables: 1.
The training to the use of the characterisation framework. Training was given by means of theoretical lessons and practical sessions. The theoretical lessons presented the problems involved in the process component evaluation and the characterisation framework. They were followed by an initial experiment during which the experimental subjects were asked to apply the knowledge gained to a simple process component. Further training followed and a comparison experiment concluded the cycle. During the
Questions I1
3. Experimentation The question:
3.1 Experiment variables
addresses
the
following
Does improved knowledge and practice of the framework favour improved comprehension of an informally described process component and hence confirm the efficacy of the framework? Comprehension of the process component being analysed includes verification both that it satisfies the innovation requirements for the process model and can be integrated into the process, and that it is able to select the suitable one from among a set of process components satisfying these requirements. There is no sense in evaluating the difference between the results that could be obtained for process component comprehension using the framework and those obtainable without using any support. Such results would be oversimplified and would obviously confirm the hypothesis that, without any formalisation support, it is difficult to understand informally described process components (described in text form with a high degree of freedom and ambiguity) and render them formalised and operative. This is the main obstacle to the diffusion in production environment of the process components experimented in the research laboratories and published in literature. To summarise, the experimentation aims to establish whether a progressively improved knowledge of the characterisation framework and ability to use it leads to an improvement in the quality of comprehension of a process component. If this hypothesis proves valid, it will demonstrate that the characterisation framework provides a useful tool for comprehending and evaluating process components.
I2 I3 I4 I5 I6 I7 O1 O2 O3 O4 O5 O6 O7 EM1 D1 EN1 EN2 T1 F1 Q1 Q2 Q3 Q4 Q5 Q6
LWD SND CLV under fully under mappable mappable mappable adequate and adequate and adequate and compliant compliant compliant not adequate adequate adequate procedural COBOL procedural language language yes yes yes formal formal formal yes yes yes under over fully mappable mappable mappable adequate and adequate and adequate and compliant compliant compliant restructured not modified not modified object-oriented object-oriented procedural language language language yes not modified yes formal diagrammatic formal yes yes yes facilitate reuse facilitate reuse facilitate reuse not adequate not modified not modified yes yes yes yes yes yes static analysis static analysis static analysis algorithmic descriptive algorithmic poor good good yes yes yes no no no no no no 2 2 2 0 0 2
Table 2 – Frameworks of the three process components
5
last phase, being better trained, the experimental subjects were asked to analyse two more complex process components than the first. 2. The analysis round. Three analysis have been performed by each experimental subject: one during the initial experiment (TRIAL) after the introductory training, and the other two during the comparison experiment after the additional training. The comparison experiment has lasted two days. Hereafter, the first day is denoted as ROUND1 and the second day as ROUND2. 3. The process components to be analysed. The process component considered during the initial experiment was proposed by Liu and WilDe in [9] and is indicated as LWD. The two process components analysed during the comparison experiment were proposed by Cutillo, Lanubile and Visaggio in [3], and Nyàri and SNeeD in [11], and are indicated as CLV and SND, respectively. Table 2 shows the correct answers to the characterisation frameworks for the three process components analysed. The first column of the table indicates the identification code of each question (see Table 1), and the following three columns, the values of the answers for the three process components analysed. The answers to the questions were identified simply by analysing the available and cited documentation, evaluated with respect to some external conditions (input available and output expected) that, for reason of space, are not presented here. 4. The team composition. The experimental subjects were randomly grouped into two teams, A and B, of 9 people each. 5. The component order. During the initial experiment all the experimental subjects analysed LWD, the simplest process component. The comparison experiment involved analysis of the two remaining process components CLV and SND. The two groups of experimental subjects did not analyse CLV and SND in the same order: Group A was asked to analyse CLV during ROUND1 and SND during ROUND2, and Group B to do the reverse.
• The variable process component to be analysed is considered in order to show that, after the training, evaluation of the different process components gives the same results regardless of their complexity and application domain. This makes it possible to discard the hypothesis that the effectiveness of the framework depends on the characteristics of the process component, instrumentation effect. • The variable team composition is used to show that the results obtained are not influenced by the composition of the teams, selection effect. • The variable component order serves to demonstrate that the order in which the different process components are evaluated does not alter the results, presentation effect. The dependent variables calculated are the Correctness and Completeness. Correctness indicates the rate of the correct answers given by the experimental subjects on the total number of questions answered. It evaluates the frequency of correct answers given by the experimental subjects, by means of the formula: #correct answers Correctness = ___________________ # answered questions where #answered questions indicates the number of questions answered by all the experimental subjects without considering if they are correct or wrong, and #correct answers indicates the number of corrects answers given by the experimental subjects. The correctness of the answers was determined by comparison of the results with the answers given in Table 2. Completeness measures the rate of the answers given by the experimental subjects on the total number of questions in the framework. It is calculated as: #answered questions ___________________ Completeness = #questions
The first variable, the training, is the treatment variable. The other variables have been introduced to eliminate potential effects that might threaten the internal validity of the experiment. The potential effect and their relation to the independent variables are listed below:
where #questions indicates the total number of questions in the framework, in this case 26 (see Table 1).
• The variable analysis round is considered in order to demonstrate that after adequate training and a trial experiment, followed by additional training, all the successive process component evaluations supported by the framework provide the same results. This shows that the results of the experiment are not influenced by experience gained in the use of the framework, maturation effect.
Before carrying out the initial experiment, the experimental subjects attended on the topics shown in Table 3. After these lessons, the initial experiment was performed, analysing the process component LWD. The initial experiment emphasized the difficulties met by the experimental subjects in using the framework. To
3.2 Experimental design
6
Topic Hour Process modelling 4 Basic concepts regarding the need for, and 1 meaning of, the process innovation Methods for reusing process components 3 published in literature and developed in research environment The framework, its contents and use in 2 evaluating a process component
3.3 Experimental results Figures 1 and 2 depict the correctness and completeness rates, respectively, through box-plots. The rectangle of the box-plots includes the data points in the first to the third quartiles; the median for each process component is identified by a bar within the boxes; and the vertical lines outside the boxes extend up from the third quartile to the 95th percentile and down from the first quartile to the 5th percentile.
Table 3 – Topics discussed before the initial experiment clarify the most difficult concepts, two support lessons were then given. The experimental subjects were also asked to practise the use of the framework on various process components for 13 days prior to the comparison experiment. Each experimental subject could decide for himself how many exercises he needed to do, to be prepared for the following experiment rounds. Experimental subjects were encouraged to gain a good knowledge of the framework as the marks obtained for the application of the framework during the comparison experiment would be credited in the marks for the final examination for the whole course. The comparison experiment was performed on two successive days, so as to minimize the influence of the duration of the experiment on the results. Each experimentation session (TRIAL, ROUND1 and ROUND2) lasted four hours. Table 4 summarises the order in which each team analysed the process components proposed. TEAM A B
TRIAL LWD LWD
ROUND1 CLV SND
Figure 1 - Box plot for the correctness rate
ROUND2 SND CLV
Table 4 - Experimental design The complexity of the process components, in terms of localisation of the information necessary for their evaluation and explicit description, had previously been evaluated from the authors and was confirmed by the experimental subjects in the individual reports they wrote during the experiment. The order of complexity of the three process components was found to be the following: LWD, SND, and CLV. The material the experimental subjects received for use during the experiment was the framework, containing the questions to be answered, and documentation of the process component to be evaluated. The documentation was provided written in Italian to avoid added difficulties connected with understanding English.
Figure 2 - Box plot for the completeness rate
7
Independent Variable training (treatment variable) analysis round (maturation effect) process components (instrumentation effect) team composition (selection effect) component order (presentation effect)
Components compared LWD - SND
Df 1
SS 0.175
F 11.25
P 0.0025
LWD - CLV Round1 - Round2
1 1
0.159 0.0133
10.59 2.41
0.0032 0.1319
SND - LNV
1
0.0004
0.07
0.7915
Group A - Group B
1
0.0013
0.22
0.6399
CLV Group A – CLV Group B SND Group A – SND Group B
1
0.0032
0.58
0.46
1
0.0117
1.93
0.188
Table 5 - Correctness values
Independent Variable training (treatment variable) analysis round (maturation effect) process components (instrumentation effect) team composition (selection effect) component order (presentation effect)
Components compared LWD - SND
Df 1
SS 0.564
F 8.29
P 0.0076
LWD - CLV Round1 - Round2
1 1
0.607 0.0008
9.24 0.03
0.0051 0.8547
SND - LNV
1
0.0008
0.03
0.8547
Group A - Group B
1
0.0835
4.15
0.0512
CLV Group A – CLV Group B SND Group A – SND Group B
1
0.0033
1.70
0.2144
1
0.0509
2.16
0.1653
Table 6 - Completeness values
Figure 1 shows that good values were obtained for correctness for all three process components. Nevertheless, the median correctness value is higher for SND and CLV than for LWD. The correctness values obtained by the experimental subjects for evaluating SND and CLV are concentrated between 0.6 and 0.86, while the lowest values obtained are similar to the median value obtained for LWD. Moreover, the correctness values obtained for LWD are distributed over a wider range than those calculated for SND and CLV. Figure 2 shows that the completeness values for SND and CLV determine a median near to 100% and are concentrated around it. On the contrary, the completeness values of LWD determine a much lower median value than in the previous cases. They are not concentrated around the median value and indicate that some experimental subjects did not answer some questions at all. To summarise, the results obtained show that a better
knowledge of the framework improves both the correctness and completeness values. Moreover, the concentration of the correctness and the completeness values around the median, in SND and CLV, indicates that the improvement is systematic. It has still to be proved that the improvement of the correctness and completeness values is caused just by the training and not by other effects. This point will be discussed in the next section.
3.4. Statistical analysis Data were analysed by one-way analysis of variance for each of the five independent variables, to identify the individual variables that could explain a significant amount of variation in the rates. For each independent variable, the null and alternative hypotheses have been formulated as follows:
8
H0: there is no difference between the various treatment conditions with respect to the team scores. Ha: there is a difference between the various treatment conditions with respect to the team scores. Table 5 presents some results obtained for Correctness and Table 6 for Completeness. The values analysed and relative meaning are the following: df represents the degree of freedom, SS the sum of squares, F the value of the F statistic used to test the null hypothesis. A p value of 0.05 is the most commonly accepted threshold: when a p value is less that 0.05, the null hypothesis, H0, may be rejected and thus the independent variable has a significant effect. The considerations stemming from the values shown in the two tables are similar for the correctness and completeness. They can be summarised as follows: • The treatment variable shows a significant effect of training on the completeness and correctness values obtained for the process component in the trial experiment and those obtained for the process components in the comparison experiment, after further training (p value < 0.05). This means that the improvement obtained is influenced by the experimental subjects’ better knowledge of the framework. • The variable analysis round does not substantially influence the results obtained during the two comparison experiment days (p value > 0.05). This means that any improvement obtained in the evaluation of the two process components SND and CLV is not influenced by the experimental subjects’ greater experience in understanding process components (maturation effect). • The variable process components to be analysed does not influence the evaluation supported by the framework after the training period (p value > 0.05). This means that the improvement in quality of the evaluation is not influenced by the characteristics of the process component analysed (instrumentation effect). • The variable team composition does not influence the correctness and completeness values (p value > 0.05) (selection effect). • Finally, the variable component order does not influence the results obtained (p value > 0.05). This means that the process components can be analysed in any order (first CLV and then SND, or viceversa) without affecting the results (presentation effect). In short, the results obtained confirm the initial hypothesis that the only independent variable that can influence the completeness and correctness of the evaluation of any process component is the level of training given to the experimental subjects. When sufficient knowledge of the process component to be
analysed has been gained, and if the framework does not change, any independent variable considered does not affect the validity of the experimentation.
4. Conclusions This paper has shown that the experience in a particular application domain can be used to specialise and enrich a characterisation framework. This framework can be used as experience accumulator for the evaluation of the process components in a particular application domain. Moreover, it can be applied to any application domain after having been specialised. The experimentation has shown that a good level of correctness can be obtained for the analysis and evaluation of the process components using the approach proposed. The completeness level is less important than the correctness, as it can be improved simply by extending the time available for the task. Moreover, the experimentation has demonstrated that training in the use of the characterisation framework considerably improves its effectiveness, even when more complex process components are then analysed. This provides significant information on the validity of the framework as a tool for understanding a process in order to be able to characterize it. The training scheme can also be applied with professional experimental subjects and used to diffuse the technology presented. For this reason, the scheme is considered as an experimentation sub-product and can be reused for experimentation in other contexts. The results obtained show that technology presented can be considered valid. A further experimental survey that the authors are planning is to repeat the experimentation of the characterization framework on larger scale operative projects. Moreover, they will investigate whether the technology can be more efficiently applied if supported by a scenario based on reading techniques. To guide the definition of the characterization framework. Thanks to the formalised nature of the experiment, it can be repeated by other researchers. The authors would make the package of materials required available in this case. The results of further experiments would reinforce the validity of the findings.
Acknowledgement The authors would like to thank Vito Cristella for his collaboration in setting up the experiment, Ms. Mary V.C. Pragnell (B.A.) for her contribution as technical writer, and the unknown referees for their useful suggestions.
9
Bibliography [1] Basili V.R., Rombach H.D., Tailoring the Software Process to Project Goals and Environment, Proc. of the 9th International Conference on Software Engineering ICSE '87, Monterey, CA, March 30 - April 2 1987, ACM press, pp. 345-357 [2] Chikofsky E.J., Cross II J.H., Reverse Engineering and Design Recovery : A Taxonomy, IEEE Software, vol.7, 1990 [3] Cutillo, Lanubile F., Visaggio G., Extracting application domain functions from old code: a real experience, Proc. of 2th Workshop on Program Comprehension WPC '93, Capri, Italy, 8-9 July 1993, IEEE Comp. Soc. Press, pp 186-192 [4] Cimitile A., Visaggio G., A Formalism for Structured Planning of a Software Project, Int. Journal of Software Engineering and Knowledge Engineering, vol. 4, no. 2, June 1994, World Scientific Publishing, pp. 277-300 [5] d’Inverno M., Justo G. R. R., Howells P., A Formal Framework For Specifying Design Methods, SOFTWARE PROCESS - Improvement and Practice, John Wiley & Sons, Vol. 2, 1996, pp. 181-195 [6] Fiore A., Lanubile F., Visaggio G., Effort Estimation for Program Comprehension, Proc. of the 4th Workshop on Program Comprehension WPC '96, Berlin, Germany, IEEE Comp. Soc. Press, March 1996, pp.78-87 [7] Hunphrey W., Characterising the Software Process: a maturity Framework, IEEE Software, Vol. 5, No. 2, March 1997, pp. 73-79 [8] Hunphrey W., Introduction to the Personal Software Process, Addison Wesley, 1997
[9] Liu S., Wilde N., Identifying objects in a conventional procedural language: an example of data design recovery, Proc. of Conference on Software Maintenance, San Diego, CA, USA, 26-29 November, 1990, IEEE Comp. Soc. Press, pp. 266-271 [10] Paulk M., Weber C., Curtis B., Chrissis M. B., Capability Maturity Model. Guideline for Improving the Software Process, Addison Wesley1994 [11] Sneed H., Nyáry E., Migration of Procedurally Oriented COBOL Programs in an Object-Oriented Architecture, Proc. of 2th Working Conference on Reverse Engineering, Toronto, Canada, July 1995, IEEE Comp. Soc., pp 217-226[12] Song X., Osterweil L. J., Comparing Design Methodologies Through Process Modelling, Proc. of 1st Int. Conference on Software Process, Redondo Beach, Ca, October 1991, IEEE Comp. Soc. Press, pp. 29-44; [13] Song X., Osterweil L. J., Experience with an Approach to Compare Software Design Methodologies, IEEE Transaction on Software Engineering, Vol. 20 No. 5, may 1994, pp. 364-384. [14] Song X., Systematic Integration of Design Methods, IEEE Software, Vol. 14, No. 2, March-April 1997, pp. 107-117; [15] Tortorella M., Visaggio G., CREP - Characterising Reverse Engineering Process components methodology, Proc. of International Conference on Software Maintenance, Bari, Italy, October 1 - 3, 1997, IEEE Comp. Soc. Press, pp. 222-231; [16] Visaggio G., Comprehending the Knowledge Stored in Aged Legacy Systems to Improve their Qualities with a Renewal Process, International Software Engineering Research Network (ISERN) Technical Report n. 97-26. Submitted to the Journal of Software Maintenance, John Wiley and Sons
10
