当前位置:首页 >> 天文/地理 >>

An Experiment Investigating the Effect of informating hiding on maintainablity


An Experiment Investigating the Effect of Information Hiding on Maintainability
Linda S. Rising Air Transport Systems Division Honeywell Inc Phoenix, AZ 85036-1111,USA
ABSTRACT An experiment was conducted to investigate the effects of different levels of information hiding on maintainability. Two versions of an Ada program were created. Each version contained a set of modules with good information hiding and a set with poor information hiding. Subjects were given one of two versions of an Ada program and two modifications to perform. One modification was performed on the well-designed set of modules and one on the poorly-designed set. The results show that sections of the programs with good information hiding do not suffer structural decay as a result of the modification and that sections with poor information hiding are improved in approximately two-thirds of the new versions. These results are especially notable considering that the programmers were, for the most part, unfamiliar with Ada and object-oriented design.

Frank W. Calliss
Department of Computer Science and Engineering Arizona State University Tempe, A 2 85287-5406, U.S.A.
ered important contributions. In the decade following, they were considered inadequate to provide programmers the needed abstractions t o deal with large programs. The necessary programming language s u p port for higher levels of abstraction was based on the class construct of Simula [4]. It appeared in languages like Ada [l], Modula-2 [27], CLU [15], Eiffel [17], and C++ [24]. The support provided by these languages will be referred to as a module. The concept of information hiding was introduced by Parnas in his classic paper, “On the Criteria to be Used in Decomposing Systems into Modules” [19]. According to this precept, each module hides a single design decision from all other modules by using a minimal abstract interface. Some examples of design decisions are: the implementation of a complex data structure or the details of the interface to an external device. Module interfaces or connections should reveal as little information as possible. Since interfaces are the assumptions that modules make about one another, changes to a module should not alter the interface. Parnas [20] states that the interface is created by identifying a set of operations that cannot be efficiently performed without knowing the hidden design decision. These operations may be viewed as the instruction set of an abstract machine. The result of this approach is that the programmer is provided a virtual machine defined by the hardware and his limited knowledge of the other software on the machine. As a result, the architecture of a system can be described as a hierarchy of virtual machines. These ideas of Parnas concerning hierarchical structuring of programs are based on the notions expressed in Dijkstra’s paper on the development of the THE system [5]. The THE hierarchy allowed the system to be tested beginning with the lowest level, adding succeeding levels when the previous level had been thoroughly tested. This allowed the number of test cases to be so small at each step that the tester could run them all and feel confident that nothing had been
510

1

Introduction

The development and maintenance of large software systems are overwhelmingly complex tasks. The result of a survey of activities of maintenance programmers indicates that maintainers spend at least half their time trying to understand the system and the user requests [18]. Wirth [26] has concluded that our most formidable weapon against complexity is abstraction, ignoring unimportant details and concentrating on important ones. In the development and maintenance of a large system, this means concentrating on one level of abstraction at a time, and ignoring the details of other levels. Abstraction mechanisms have evolved with our understanding of programming issues and our ability to use the abstractions [22]. At the time of their introduction, procedures and functions were consid0-7803-0922-7/93$03.00 1993aIEEE

overlooked. Information hiding was the basis for the notion of an abstract data type (ADT) defined by Liskov and Zillea [14] as a: uclass of abstract objects which is completely characterized by the operations available on those objects ... so that an ADT can be defined by defining the characterizing operations for that type.” Liskov [16] states that for abstraction to be effective, the implementation details must be encapsulated, so no other module can know the implementation details. Encapsulation ensures independent module development. Abstraction when supported by encapsulation provides locality within a program, which allows a program to be implemented, understood, or modified, one module at a time. Clearly, the works of Parnas, Dijkstra, and Liskov indicate that a measure of information hiding would provide a measure of the understandability, modifiability, and testability of a system.
1.1

Quality Measures

Boehm et al. [2], developed a taxonomy of quality characteristics to be used to create metrics, so that a measure of a quality characteristic for a given program can be determined by the value of the associated metric. The initial set of Characteristics included: Understandability, Completeness, Conciseness, Portability, Consistency, Maintainability, Test ability, Usability, Reliability, Structuredness, and Efficiency. Definitions were developed for these characteristics and then metrics were derived. It was discovered that the measures overlapped. Measures of understandability, for example, were also measures of maintainability, but there were measures of maintainability that were not measures of understandability. To express this overlap, the characteristics were organized in a tree structure. According to this scheme, maintainability comprises understandability, modifiability and testability. Other authors have defined maintainability in the same manner [7,131. To reflect this, one of the goals of this research is to show that the component characteristics of maintainability: understandability, modifiability, and testability, can be correlated with information hiding. This result would be supported by the ideas of Parnas, Dijkstra, and Liskov, who recognized the relationships between these desired software quality characteristics and information hiding.

1.2

Other Experiments

According to a recent report, precise, repeatable experiments that validate appropriate hypotheses dis51 1

tinguish mature scientific disciplines. Unfortunately, little empirical evidence exists for many of software engineering’s basic assumptions. One of the goals of this research is to show that maintainability is related to the values produced by the information hiding metric, IH(Modu1e). This result would be supported by the ideas of Dijkstra, Parnas, Habermann, and Liskov, who recognized the relationship between these software quality characteristics and information hiding. One of the earliest computer scientists to begin conducting experiments to demonstrate the value of programming practices was Weissman at the University of Toronto. His was the first study to take a behavioral perspective on how program characteristics affect programmers [3]. The primary aim of his research was to conduct experiments to determine appropriate ways to measure a subject’s understanding of a program and his ability to modify it [25]. A series of five experiments were performed. After the results of each experiment were evaluated, changes were made to the experimental techniques. Although no statistically significant results were achieved, knowledge was gained about experimental procedures. The most important thing learned from the first experiment was that students with less than a year of programming experience are not suitable subjects. The difficulties they encountered were with constructs in the language rather than details of the algorithms. In the third experiment, several students failed to record their times for the procedures. As result, it w s decided to abandon the practice of letting stua dents record their own time and enforce strict time limits for each stage. It was recognized that it is difficult to find programs that are short enough to be manageable in the time allotted for the experiment yet not too trivial to understand. It is also difficult to find subjects. Woodfield et al. [28] conducted an experiment to see how various kinds of modularization and comments related to a programmer’s ability to understand a program. The study involved four kinds of modularization: monolithic, functional decomposition, overmodularization, and abstract data type modularization. Subjects were given a set of questions about the behavior of the programs. The group assigned the abstract data type version with comments made the highest score. The programs used for this experiinent were from 100 to 192 lines of FORTRAN. The data abstraction was, therefore, not enforced by the language. Similar results were obtained in a study described in [111, conducted by Korson and Vaishnavi, where sixteen participants were given either a modular or monolithic version of a program to modify. The time for each modification was recorded and, in each case,

the time required to modify the modular version was significantly shorter than that required for the monolithic version. The modulea in this experiment were subprograms. Some of the ideas of information hiding and data abstraction appeared in the design of the programs but were not enforced by the language (Pascal). Henry and Humphrey [8] compared student performance in maintenance tasks on two systems, one written in C and one in Objective-C. The programs were approximately 4000 lines long and written with identical requirements. Their study showed that more maintainable code was produced by Objective- C, an object-oriented language, than C, a procedure-oriented language. The Objective-C code required fewer modules to be edited, fewer lines of code to be changed, and fewer new lines to be added. Rombach [21] describes LADY, a newly developed language for distributed systems, and a maintenance experiment to determine maintainability when LADY was compared with an extension of Pascal. LADY, with design features to promote abstraction, produced more maintainable software.

2.2

Experimental Design

In this experiment, there is one independent variable, the level of information hiding. There are two levels of the independent variable, good and poor. Each subject receives all conditions in the experiment and, thus, functions as his own control for potentially confounding effects of variables such as IQ, experience, etc. In this kind of design, the repeated conditions must be presented in an order that accounts for effects such as fatigue and learning, using a counterbalanced sequence [23]. Therefore, each student performed the same two modifications but not in the same order. In each group, the students were paired by their Ada experience. The resulting two sections of each group were initially assigned the first and second maintenance assignments respectively. When each student had correctly finished his first assignment, the next assignment was given. The null hypothesis for this experiment is: There is no significant difference in the time required to understand the program, and implement the two modifications. Where one modification will be performed on a portion of a program with good information hiding and one modification will be performed on a portion of the same program with poor information hiding.

2
2.1

Experiment
Overview

2.3

Subjects

Applying the ideas of Parnas to an Ada program would produce modules or packages that encapsulate a single design decision behind a minimal interface or specification. An experiment was performed to investigate the effect of information hiding principles on the maintainability of a small Ada program. Initially, each student was given a short questionnaire containing questions about his experience in software engineering and programming languages. Each subject was then given a program and two modifications to perform. The first modification was to be completed before the second was started to ensure as correct timing as possible. After the last modification had been performed, the students were to write a short paper to address the following issues for each modification: ease of understanding the part of the program to be modified; ease of actually performing the modification; ease of verifying that the modification had been done correctly. When the project was completed, a short quiz was giveri. Copies of the questionnaire, command procedures, versions of the program, and the quiz are available from the authors upon request.
512

The subjects were 22 students enrolled in a graduate class in software metrics offered during the Spring semester 1991 at Arizona State University. The students were told that they were participating in an experiment but were not told what the experiment was designed to measure. Initially, each student was given a short questionnaire containing questions about his experience in software engineering and programming languages. The subjects were all graduate students who had completed at least ten computer science courses. Of the 22 students that participated in the experiment, only 14 finished all the stages. Nine of the fourteen students who finished the experiment had spent some time working in industry and seven were currently employed in industry.

2.4

Materials

Two different versions of a small Ada program (800 lines) were created from a program originally designed with good information hiding. The original program, Flight, was altered to produce two versions, Flight1 and Flight2, each containing a poorly designed set of

modules and a well-designed set of modules. Each student was given one of these versions and asked to perform the same two modifications, although not in the same sequence. In each version, one modification was performed on the well-designed set of modules and one on the poorly designed set. The original program contains five packages and the main procedure. The five packages are: FlightPlan-Paclcage Implements an abstract state machine, an array of Flightleg. The type is hidden in the body and no extraneous information is revealed in the specification. Flight LegSackage Implements an abstract data type, a record of information for each flight leg. The type is private and no extraneous information is revealed in the specification. LocationSacEage Implements an abstract data type, a record of information about the location of each Waypoint. The type is private and no extraneous information is revealed in the specification. WaypointList Package Implements an abstract state machine, an array of waypoints. The type is hidden in the body and no extraneous information is revealed in the specification. Waypoint Package Implements an abstract data type, a record of information about each waypoint. The type is private and no extraneous information is revealed in the specification.

have presented a much more complicated setting for the maintenance task. The assignments were:

1. Change the data structure of FlightPlan from an array to a linked list.

2. Change the data structure of WaypointList from an array to a tree.
The first modification should have been relatively easy to perform in Flight2 and more difficult in Flightl. The second modification should have been relatively easy to perform in Flight1 and more difficult in Flight2. Nearly half the students viewed the class remotely a t various sites in the Phoenix area. The on-campus group was assigned one version of the program and the off-campus group was assigned the other to ensure that no knowledge of the other version was obtained by students. When the project was completed, a short, multiplechoice quiz was given. Questions were targeted for the areas of the program required for each modification. Some questions covered the well-designed parts of the program and some covered the poorly-designed parts. Some questions also covered areas of the program not needed to perform the modification to show that students could perform a modification in one part of the program without understanding the entire program.
2.5

Procedures

In Flight 1, Flightleg-Type was moved inside the specification of FlightPlanPackage. Two design decisions are now encapsulated in one package. The array data structure of FlightPlan-Type was moved to the visible part of the specification and, therefore, is no longer private. The main procedure and the body of FlightSlan-Package access the array directly. This package now has poorer information hiding that the original version since two design decisions are encap sulated in one module and the interface provides extraneous information to all users of the modules. In Flight2, the body of WaypointList-Package no longer exists. The data structure has been moved firom the body to the specification and is open. The main procedure acc,esses the array directly. This package still encapsulates a single design decision but the interface is no longer minimal. Waypoint-Type was not moved to WaypointList-Package which would have resulted in two design decisions being encapsulated. WaypointPackage was imported by every other package in the program, except LocationPackage. Moving Waypoint-Type to WaypointListPackage would
513

The modifications were performed using the DEC Ada compiler on VAX VMS. Each subject was provided with a set of command procedures which executed when the student logged on, compiled, executed f. the program and logged o f The log on procedure required the user to enter the time spent trying to understand the modification and time spent implementing the modification since the last log on. The command procedures recorded the reason for the compilation, the time of the compilation, and execution.
2.6

Results

There was no correlation between the level of information hiding and any of the following dependent variables: information from the questionnaire, time spent understanding, time spent implementing, number of compilations, executions, total time logged on. This was not entirely unexpected, since the report by Joyce [9, 101 of a similar experiment had shown no correlation with any of the multitude of dependent variables he measured. Joyce’s work investigating the effect of design guidelines on maintainability was the inspiration for this experiment. Although Joyce was

unable to show any statistical validation of his hypothesis, he was able to report some interesting results. The design guidelines produced a measurable impact on the kind of solution produced by the subjects. Joyce reported, “. . . use of language support in the form of an encapsulation unit helps preserve the integrity of the original design of a guidance based program during maintenance.” Similar results were hoped for in this experiment and, happily, these expectations were realized. There were three sources of encouraging results: the quizzes, the papers written by each subject, and the modifications themselves. 261 .. Quizzes

The results from the responses on the quizzes were mixed. The students did not know information about the parts of the program which were not involved in either modification. At least two-thirds of the answers were “Don’t know” indicating that they knew that they didn’t know. Unfortunately, the results for the parts of the program they should have known were not as good. 2 6 2 Papers .. Of the fourteen students who finished both modifications correctly, twelve stated in their papers that the modification on the part of the program with poor information hiding was more difficult to understand and implement than the modification on the part of the program with good information hiding. Eight of these students felt the reason for the difficulty was poor design. None of the students was familiar with Ada, although five of the students listed Ada as one of the top three languages in a list of programming languageq they had used. Many of the students claimed that their unfamiliarity with the language would distort the times spent on the modification, since a great deal of the time spent on the first modification was actmually spent learning about the language. 263 .. Modifications

In Flightl, the version in which FlightLeg-Type was part of the specification of FlightPlanPackage, when the flight plan was changed from an array to a linked list, all eight students working on that version added the Next pointer to the FlightLeg-Type. The object flight leg should be the same regardless of the data representation of flight plan. The linked list should have been implemented by the declaration of a new record containing Flightleg-Type and the Next pointer. In Flight2, where FlightLegPackage was separate from FlightPlanPackage, all but one of the
514

students implemented it in this way. The design of Flight2 discouraged them from making any modification to FlightLegPackage, because any change meant editing additional files and recompiling them. It is interesting that the one student who modified the Flightleg-Type, even though it was in a separate package, was also the only student of all those who completed the experiment to modify waypoint list by adding pointer fields to Waypoint-Type. Eight students performed the modification on the bad flight plan in Flightl. Five of those simply replaced the array references in the main program and flight plan body with equivalent statements referencing the linked list. The bad information hiding resulted in the students’ leaving the program as it was. Some of these students did describe their dilemma in their papers, saying they weren’t sure whether to leave the bad design or try to improve it. There was the recognition that improvement was possible. The remaining three students in this group added new routines to the FlightPlanPackage body and replaced the direct access in the main program and the package body with calls to these routines. Information hiding remained the same in five (poor remained poor) and improved in three (poor improved) of the eight new versions. Eight students performed the modification on the good waypoint list in Flightl. All eight simply r e placed routines in the body of the WaypointList with tree insertion and location routines. No one added a pointer to Waypoint-Type but instead created a new record in WaypointListPackaged and left Waypoint-Type alone. Information hiding remained good in all eight new versions. Six students performed the modification on the good flight plan in Flight2. All six simply replaced routines accessing the array by routines to access a linked list. Only one student added a pointer to FlightLeg-Type, which was encapsulated in a separate package. Information hiding remained good in five of the new versions and became poorer in one. Six students performed the modification on the bad waypoint list in Flight2. Only one student (the same student who added a pointer to FlightLeg above) added a pointer to Waypoint-Type. Four students added a body for WaypointList. This is in contrast to the three out of eight who added routines in the body of the bad Flightplan. Two students simply replaced the direct access statements in the main procedure with routines to access the tree. This is not really much of an improvement in information hiding but it is a small1 improvement in the design of the main procedure. Note that no student with this version merely replaced access statements for the array with access statements for the tree, as five of the eight students

did with the comparable problem in Flightl. Poor information hiding improved in four of the new versions and remained the same in two (with an improvement in design in the main procedure).

3

Conclusions

It has been observed that systems become increasingly difficult to maintain over time because of structural deterioration [12]. It is interesting to note that of the twenty-nine new versions of the program created in the experiment:
0

8 deteriorated by the addition of the pointer to Flightkg-Type when FlightLeg was encapsulated in FlightPlanSackage. Poor design deteriorated.
1 deteriorated by the addition of a pointer to Flight-Leg-Type even though Flightleg-Type was in a separate package. Good design deteriorated. 1 deteriorated by the addition of a pointer to Waypoint-Type even though Waypoint-Type was in a separate package. Bad design deteriorated. 10 designs deteriorated, 36%

0

0

0

0

8 remained the same when procedures accessing the WaypointList defined as a tree replaced procedures accessing WaypointList defined as an array. Good design remained good.
5 remained the same when procedures accessing FlightPlan defined as a linked list replaced procedures accessing FlightPlan defined as iin array. Good design remained good.

0

0

13 designs remained the same, 46%
4 improved the design by adding a body for Waypoint-list and writing access routines when none existed in the original version. Bad design improved.

0

This is remarkable considering the students were not given any instruction in design. They were also not given any guidance as to what sort of design alternatives to consider. The students also had little or no experience with Ada and, in some instances, had never encountered the notions of separate compilation or separate specifications and bodies for packages. that programmers It was found in a recent study [SI, unfamiliar with the ideas of information hiding and data abstraction did not develop packages that exhibited these properties. A team of four programmers created a program containing approximately 4000 lines. Only two of the team members defined any packages in their part of the system. Of the eleven packages that were created, six exhibited excessive visibility. These programmers had been given a one-month training period which comprised fifteen hours of videotaped lectures and a six-day in-house course by a consultant. The experiment reported in this paper produced such different results from that in [6] that it suggests a new way of teaching programmers about design. Instead of giving development assignments, give maintenance assignments which use programs with welldesigned and poorly-designed sections. The consequences of good and bad design can clearly be seen and, more importantly, the programs will provide good examples of good and bad design alike. Only six of them students indicated any acquaintance with object-oriented design but all fourteen students who completed the experiment could see the difference between the maintainability of good and bad sections of the program. The elegant notion of information hiding is so appealing that programmers seem intuitively drawn to enforce it in maintenance tasks if given the opportunity to see its advantages. Programs that follow information hiding guidelines are thus not only maintainable but sections that are initiallypoorly designed may become more maintainable if programmers are encouraged to improve information hiding as a supplement to other maintenance tasks.

References
[l] Reference Manual for the Ada Programming Language, 1983. ANSI/MIL-STD 1815A.
[2] Boehm, B.W., J.R. Brown, and M. Lipow, “Quantitative Evaluation of Software Quality,” in Proceedings of the Second International Conference on Software Engineering, 1976, pp. 592-605.

0

2 improved the design by adding access routines for WaypointList even though they were kept in the main procedure. Bad design improved but not infor mat ion hiding. 6 designs improved, 21%

0

Two-thirds of the new programs were the same or improved versions of the original program. These versions were the object of preventive maintenance in addition to perfective maintenance.
515

[3] Curtis, B. “A Review of Human Factors Research on Programming Languages and Specifica-

tions, Association for Educaiional Data Sgtsiems (AEDS) Monitor, MarchIApril 1983, pp. 2430.

[15] Liskov, B., R. Atkinson, T. Bloom, E. Mom, J.C. Schaffert, R. Scheifler, and A. Snyder, CLV
Reference Manual, Springer-Verlag, New York, 1980.

[4] Dahl., O.J., B. Myhrhaug, and K. Nygaard, The Simula 67 Common Base Language, Forskningsveien, Oslo, 1970.
[5] Dijkstra, E.W., “The Structure of the ‘THE’ Multiprogramming System,” Communicaiions of the ACM,Vol. 11, No. 5, May 1968, pp. 89-98.

[16] Liskov, B., “Data Abstraction and Hierarchy,” OOPSLA’87 Addendum, printed as SIGPLA N Notices, Vol. 23, No. 5, May 1988, pp. 17-34. [17] Meyer,, B., Object-Oriented Software Consiruction, PrenticeHall International, 1988. [18] Parikh, G. and N. Zvegintzov, “Part I: The World of Software Maintenance,” in Tutorial on Soflware Maintenance, IEEE Computer Society Press, New York, 1983, pp. 1-3. [19] Parnw, D.L., “On the Criteria to be Used in Decomposing Systems into Modules,” Communications o f t h e ACM, Vol. 15, No. 12, December 1972, pp. 1053-1058. [20] Parnas, D.L., “Use of Abstract Interfaces in the Development of Software for Embedded Computer Systems,” Naval Research Laboratory b port 8047, June 1977. [21] Rombach, H.D., “A Controlled Experiment on the Impact of Software Structure on Maintainability,” IEEE rrclnsactions on Soflware Engineetinil, Vol. S E 1 3 , No. 3, March 1987, pp. 344354. [22] Shaw, M., “Abstraction Techniques in Modern Programming Languages,” IEEE Software, October 1984, pp. 10-26. [23] Snodgrass, J.G., G. Levy-Berger, and M. Haydon, Human Experimental Psychology, Oxford University Press, Oxford, 1985. [24] Strousttrup, B., The C++ Programming Language, Addison-Wesley, Reading, MA, 1986. [25] Weiasman, L. “PsychologicalComplexity of Computer Programs: An Experimental Methodology, SIGPLAN Notices, vol. 9, no. 6, June 1974, pp. 25-36. [26] Wirth, N., “On the Composition of WellStructured Programs,” Computing Surveys, Vol. 6, No. 4, December 1974, pp. 247-259. [27] Wirth, N., Programming in Modula-2, SpringerVerlag, New York, third ed., 1985. [28] Woodfield, S.N., H.E. Dunsmore, and V.Y. Shen, “The Effect of Modularization and Comments on Prograin Comprehension,” in Proceedings of the Fifth International Conference on Software Engineering, March 1981, pp. 215-223.

(61 Gannon, J.D., E.E. Katz, and V.R. Basili, “Metr i a for Ada Packages: An Initial Study,” Communications of the A C M , Vol. 29, No. 7, July 1986, pp. 616-623. [7] Harrison, W., K. Magel, R. Kluczny, and A. DeKock, “Applying Software Complexity Metrics to Program Maintenance,” Computer, September 1982, pp. 65-79. [8] Henry, S. and M. Humphrey, “Comparison of an Object-Oriented Programming Language to a Procedural Programming Language for Effectiveness in Program Maintenance,” Technical Report T R 88-49, Computer Science Department, Virginia Polytechnic, Blacksburg, V 24601. A [9] Joyce, D., A n Identification and Investigation of Software Design Guidelines f o r Using Encapsulation Uniis, Ph.D. thesis, Temple University (Computer Science), 1986. [lo] Joyce, D., “An Identification and Investigation of Software Design Guidelines for Using Encapsulation Units,” The Journal of Systems and Sopware, Vol. 7, 1987, pp. 287-295. [ll] Korson, T.D. and V.K. Vaishnavi, “An Empirical Study of the Effects of Modularity on Program Modifiability,” in Empirical Studies of Programmers, E. Soloway and S. Iyengar, editors., Ablex, Norwood, New Jersey, 1986, pp. 168-186. [12] Lehman, M.M., “On Understanding Laws, Evolution, and Conservation in the Largeprogram Life Cycle,’’ The Joumal of Systems and Software, 1980, pp. 213-221. [13] Li, H.F. and W.K. Cheung, “An Empirical Study of Software Metrics,” IEEE rrclnsactions on Software Engineering, Vol. S E 1 3 , No. 6, June 1987, pp. 697-708. [14] Liskov, B. and S. Zilles, “Programming with Abstract Data Types,” SIGPLAN Notices, Vol. 9, No. 4, April 1974, pp. 50-59.

516


相关文章:
An Optimization Experiment with the Community Land Model on ....pdf
An Optimization Experiment with the Community Land ...The modified code may also be as maintainable ... Information, and Computational Sciences Division, ...
A controlled experiment investigation of an object-oriented ....unkown
Martin Shepperd d a Department of Information Technology, Technological ...in this paper is a controlled experiment, aiming at investigating the impact...
Investigating Effects of Common Spreadsheet Design Practices ....unkown
Investigating Effects of Common Spreadsheet Design Practices on Correctness and ...We have conducted a controlled experiment with 42 subjects to investigate the...
Investigating Effects of Common Spreadsheet Design Practices ....unkown
EuSpRIG 2012 Investigating Effects of Common Spreadsheet Design Practices on ...(2006): "Testing spreadsheet accuracy theory", Journal on Information and ...
Investigating the Relationship Between Violations of the Law ....unkown
in JavaTM code while investigating the to fix ...between these violations and software maintain- ...[Software of this work is an increased ...
An investigation into design for performance and code ....unkown
(E) pp.C1001C1016, 2005 C1001 An ...code maintainability in high performance computing S...are notoriously difficult to evolve and maintain. ...
...for Investigating Maintainability Quality Attribute in ....unkown
A Model for Investigating Maintainability Quality Attribute in Software ... as an essential part of the software life cycle, is a solution ...
An empirical investigation of an object-oriented design ....unkown
An empirical investigation of an object-oriented ... received in revised form 31 August 2001; ... we say that our software is maintainable (...
An investigation into design for code maintainability in HPC.unkown
D. Sunter 24 September 2004 Abstract There are two ways to interpret a title such as "A Plug-in based design for code maintainability in HPC", based...
An empirical investigation of an object- oriented design ....unkown
in JOURNAL OF SYSTEMS AND SOFTWARE FEBRUARY 2003 Impact Factor: 1.25 ... if they are, we say that our software is maintainable (Fenton and ...
Maintainability Studies Investigating Aspect Preservation via....unkown
Maintainability Studies Investigating Aspect Preservation via Automation: Lessons ...(or pairing), but use this information only if the unpaired statistical ...
A controlled experiment investigation of an object-oriented ....unkown
Martin Shepperd d a Department of Information Technology, Technological ...in this paper is a controlled experiment, aiming at investigating the impact...
A controlled experiment investigation of an object-oriented ....unkown
Martin Shepperd d a Department of Information Technology, Technological ...in this paper is a controlled experiment, aiming at investigating the impact...
A controlled experiment investigation of an object-oriented ....unkown
Martin Shepperd d a Department of Information Technology, Technological ...in this paper is a controlled experiment, aiming at investigating the impact...
A controlled experiment investigation of an object-oriented ....unkown
Martin Shepperd d a Department of Information Technology, Technological ...in this paper is a controlled experiment, aiming at investigating the impact...
Investigating Effects of Common Spreadsheet Design Practices ....unkown
Investigating Effects of Common Spreadsheet Design Practices on Correctness and ...We have conducted a controlled experiment with 42 subjects to investigate the...
Investigating Effects of Common Spreadsheet Design Practices ....unkown
Investigating Effects of Common Spreadsheet Design Practices on Correctness and ...We have conducted a controlled experiment with 42 subjects to investigate the...
Investigating Effects of Common Spreadsheet Design Practices ....unkown
Investigating Effects of Common Spreadsheet Design Practices on Correctness and ...We have conducted a controlled experiment with 42 subjects to investigate the...
Investigating Effects of Common Spreadsheet Design Practices ....unkown
Investigating Effects of Common Spreadsheet Design Practices on Correctness and ...We have conducted a controlled experiment with 42 subjects to investigate the...
A controlled experiment investigation of an object-oriented ....unkown
Martin Shepperd d a Department of Information Technology, Technological ...in this paper is a controlled experiment, aiming at investigating the impact...
更多相关标签: