Cognitive Heuristics in Software Engineering: Applying ... - IEEE Xplore

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,

VOL. 30,

NO. 12,

DECEMBER 2004

873

Cognitive Heuristics in Software Engineering: Applying and Extending Anchoring and Adjustment to Artifact Reuse Jeffrey Parsons, Member, IEEE Computer Society, and Chad Saunders Abstract—The extensive literature on reuse in software engineering has focused on technical and organizational factors, largely ignoring cognitive characteristics of individual developers. Despite anecdotal evidence that cognitive heuristics play a role in successful artifact reuse, few empirical studies have explored this relationship. This paper proposes how a cognitive heuristic, called anchoring, and the resulting adjustment bias can be adapted and extended to predict issues that might arise when developers reuse code and/or designs. The research proposes that anchoring and adjustment can be manifested in three ways: propagation of errors in reuse artifacts, failure to include requested functionality absent from reuse artifacts, and inclusion of unrequested functionality present in reuse artifacts. Results from two empirical studies are presented. The first study examines reuse of object classes in a programming task, using a combination of practicing programmers and students. The second study uses a database design task with student participants. Results from both studies indicate that anchoring occurs. Specifically, there is strong evidence that developers tend to use the extraneous functionality in the artifacts they are reusing and some evidence of anchoring to errors and omissions in reused artifacts. Implications of these findings for both practice and future research are explored. Index Terms—Software psychology, requirements/specifications, reusable software, reusable libraries, reuse models, human factors in software design.

æ 1

INTRODUCTION

T

HE concept of software reuse has a long history in systems development and software engineering, where libraries of routines to handle common operations play an important role in a variety of programming languages. Once developed and tested, these libraries can be reused across a variety of applications and provide reliable code that does not have to be developed from scratch for each new application. With the advent and growth of the object-oriented (OO) approach to systems development, the ability to develop reusable class libraries and components has been hailed as one of the major benefits of OO programming [1], [2], [3], and this has accelerated interest in reuse during systems development. In addition, the scope of reuse has been broadened to include classes of application-specific objects (e.g., customers, orders) and migrated backward in the systems development process to include artifacts such as analysis and design patterns [4], [5], [6], [7]. A compelling argument for reuse is the potential benefit to be gained by companies that can effectively leverage software assets. The primary benefits identified include improved software quality [8], decreased development time

. J. Parsons is with the Faculty of Business Administration, Memorial University of Newfoundland, St. John’s, NL, Canada, A1B 3X5. E-mail: jeffreyp@mun.ca. . C. Saunders is with the Haskayne School of Business, University of Calgary, Calgary, AB, Canada, T2N 1N4. E-mail: chad.saunders@haskayne.ucalgary.ca. Manuscript received 2 Dec. 2003; revised 8 June 2004; accepted 27 Aug. 2004. Recommended for acceptance by W. Frakes. For information on obtaining reprints of this article, please send e-mail to: tse@computer.org, and reference IEEECS Log Number TSE-0197-1203. 0098-5589/04/$20.00 ß 2004 IEEE

and cost [9], or increased customer satisfaction [10]. In some cases, substantial benefits accruing from reuse have been claimed [11], [12], [13]. There is also evidence that reuse in practice might not be living up to its billing. In a case study of OO development in four large companies, Fichman and Kemerer found that the amount of reuse achieved was disappointing [14]. More importantly, the kind of reuse achieved was only of basic components (e.g., classes to handle string processing and dates). Reuse of domain-specific application classes did not occur in the cases studied. Fichman and Kemerer propose some possible accounts for the lack of reuse in the companies they studied, focusing on organizational (rather than technical) reasons for failing to reuse designs or code, and revisit the issue of reuse failure in the context of incentive alignment in the organization [15]. In a similar vein, Love [16] gives anecdotal evidence on widespread lack of reuse in systems development projects and Frakes and Terry [17], recognizing the prevalence of the problem, provide a typology of reuse that includes a model of failure mode analysis that can be used to identify and order the impediments to reuse in a given organization. Moreover, Irwin [18] provides empirical evidence from a study of analysts that the benefits of reuse should be treated with skepticism. In light of such evidence, nontechnical factors including organization, processes, business drivers, and human involvement are receiving increasing attention [3]. Although human factors are recognized as important to the success of reuse, cognitive aspects of the reuse process have received little empirical attention, despite the influence such issues can have on understanding the impact of reuse [19]. Published by the IEEE Computer Society

874


This paper presents theoretical arguments to support a claim that cognitive heuristics used by software developers can affect the way in which software engineering artifacts are reused, potentially impeding or enhancing the successful reuse of code and design. Two empirical studies that test this claim are presented, the results of which highlight the importance of considering cognitive issues in reuse.

2

SCOPE

AND

BOUNDARIES

OF THE

REUSE VISION

Reuse has received considerable attention in software engineering, particularly since the advent of OO development. Frakes and Terry [17] identify 10 systems artifacts ranging from source code, designs, and documentation to requirements and test cases, all of which are candidates for reuse at various points in the software development life cycle. In response to this widespread interest in reuse, special issues of journals such as IEEE Software (vol. 11, no. 5, 1994) and IBM Systems Journal (vol. 32, no. 4, 1993) have been devoted to the topic, and a search of ABI Inform covering the past five years found 69 peer reviewed articles in the information systems field directly drawing upon the tenets of reuse. Finally, Mili et al. [20] go so far as to call for an “engineering discipline” of reuse. Reuse in OO programming has roots in inheritance. An object class can be declared a subclass of another (its superclass). Through this declaration, it inherits the functionality (attributes and operations) of the superclass. Additional functionality can be added to the subclass, or existing functionality from the superclass can be overridden (polymorphism). Through inheritance, the code from the superclass is reused (i.e., does not need to be rewritten) in the subclass. From this origin, the concept of class reuse has grown to encompass the idea that generic classes of application domain objects (e.g., customer), suitably defined, can be added to libraries and made available across many different applications that require the same kinds of objects. Another trend in reuse is the recent evolution of research on developing generic analysis and design patterns [5], [6], [21], as well as work on locating reusable patterns in a repository [22]. Analysis patterns are defined as a group of related generic objects (metaclasses) with stereotypical attributes (data definitions), behaviors (method signatures), and expected interactions defined in a domain-neutral manner [5], [6], [21]. Preconditions for reusing patterns are less stringent than those for reusing code; a pattern merely provides a general template of attributes and operations that are to be modified for specific needs. Achieving the kind of widespread reuse of object classes envisaged by some [23] hinges on the assumption that the definitions (attributes and operations) of these classes be common across a variety of applications.1 For some types of problems, this is very likely the case. For instance, the operation to calculate the mean of a set of numeric attribute values is identical for every application that requires 1. An additional precondition for widespread reuse is the ability to locate reusable components, an issue that has generated a distinct stream of technical research on managing repositories of reusable artifacts [2].

VOL. 30, NO. 12,

DECEMBER 2004

calculating means. Once debugged, the code that performs this calculation can be used by any application that needs it. However, the assumption of compatible definitions is more difficult to reconcile with a wide range of research in cognitive psychology and linguistics on the nature of classes and categories [24], [25]. Such research suggests that agreement on the definition of classes cannot, in general, be achieved [26]. The basis for this conclusion is simple— classes are constructed to provide useful abstractions of similarity among objects, and what is useful varies from person to person (and over time). Hence, different abstractions are appropriate for different users and one should not assume that classes created for one set of users or applications can or should be reused “as is” by other users or applications [27]. In database design, the reality of multiple classification abstractions has given rise to the large body of research on view integration [28]. In the context of reuse, the absence of complete agreement on class definitions implies that libraries of implemented classes or patterns in most cases serve as templates that must be adapted to the unique needs of a specific application. This means either changing a class definition or defining a subclass with additional functionality needed for the application. In this regard, there is an important distinction between white box reuse, in which developers have access to the code and can make modifications to meet their requirements, and black box reuse, in which they essentially must use the code without modification. Despite growing interest in black box reuse, white box reuse still dominates [29]. Adaptation itself is not inconsistent with OO development. In programming, polymorphism provides a form of adaptation in which operations in a subclass can override operations inherited from a superclass. In requirements analysis and system design, patterns serve as templates that are to be modified to meet the needs of a specific application. In fact, objected-oriented reuse typically involves two phases: finding a related class and then modifying it to suit the new requirements [30]. However, there is also evidence that reuse imposes a high cognitive burden [31], [32], and this complexity necessitates a large number of judgments be made by the developer [33]. Drawing upon evidence from cognitive psychology, we suggest that making judgments about the modifications needed to meet specific application needs can be difficult, thereby adding to the challenge of achieving widespread effective reuse of both code and designs.

3

ANCHORING AND ADJUSTMENT ADAPTIVE REUSE

AS

FACTORS

IN

3.1 Foundations of Anchoring and Adjustment It has been shown in a wide variety of domains that, when people are given a problem for which there exists a correct solution and an initial estimate of its solution, they tend to provide final estimates close to the initial estimate when asked to solve the problem [34]. This is termed anchoring. For example, in controlled experiments where participants are asked to estimate the value of the product of a set of numbers, the estimates are highly anchored to the ordering

PARSONS AND SAUNDERS: COGNITIVE HEURISTICS IN SOFTWARE ENGINEERING: APPLYING AND EXTENDING ANCHORING AND...

of the numbers. Thus, estimates of the product 1 x 2 x 3 x 4 x 5 x 6 x 7 x 8 are consistently lower than estimates of the product 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1. The anchoring heuristic helps humans simplify problem solving in a complex situation without conscious effort. However, since they are not aware they are using the heuristic, people often fail to make adequate modifications to an initial solution and produce estimates that are severely flawed with respect to the correct solution. This is termed an adjustment bias. Studies on the effects of anchoring and the resulting adjustment bias have been conducted in several areas relevant to decision sciences and software engineering. For example, Schweitzer and Cachon [35] consider decision bias in the context of a decision maker ordering inventory before a one period selling season with stochastic demand, while Buchanan and Corner [36] examine the issue in the context of interactive multiple criteria decision making (MCDM). Within the information systems field, George et al. [37] test a decision support system (DSS) designed to mitigate the effects of anchoring and the adjustment bias and demonstrate that the bias is robust even under such interventions. The tendency to anchor appears to resist novice/expert distinctions. There is some evidence that, in the absence of direct behavioral experience, individuals tend to anchor to general/abstract criteria, but, as one gains experience, user judgments reflect specific concrete criteria that result from interaction with the target object and less from normative criteria [38], [39]. However, some studies indicate that general anchors rather than direct experience are stronger determinants [38]. In that regard, the use of heuristics is a basic cognitive process that operates subconsciously; thus, the process might not be moderated by experience [40]. Although differences between novices and experts have been hypothesized in judgment making literature [33], [41], the empirical evidence has been mixed. In particular, in the context of anchoring and adjustment, training does not appear to reduce the use of an erroneous strategy [33], suggesting that the effects remain even as one gains expertise.

3.2

Anchoring and Adjustment in Software Engineering Although much of the empirical research on anchoring and adjustment has focused on subjective probability estimation [42], the general concepts have a natural application to the reuse process in systems development. As indicated in Section 2, it might be unreasonable to expect that domain classes can be reused “as is” in new applications. In the words of one informant in the Fichman and Kemerer [14] study, “not many objects are common across systems; when they are, say, a customer object, they have different behaviors” (p. 55). Instead of direct reuse, artifacts including code and designs might need to be modified to satisfy specific application needs. If, in this setting, programmers or analysts stick closely to the class definition, they might not make the modifications necessary to ensure the system meets explicitly specified requirements of the application. For example, in an artifact being considered for reuse, a customer object may be required to have made at least one purchase of some product, while, in a new application, a

875

customer may be simply someone who has been contacted by a salesperson. Reusing an artifact constructed according to the first requirement might pose problems if the developer fails to make adaptations necessary to be consistent with the requirements of the new application. In other circumstances, such as a customer object having a “loyalty program” attribute, reuse artifacts might suggest additional potentially useful functionality not requested in requirements specifications. This basic cognitive factor adds an interesting dimension to the reuse debate. Many people have advocated the need for reuse, and there has been considerable discussion of the kind of organizational and technical environment needed to promote effective and widespread reuse [11], [14], [43], [44]. In stark contrast, and at the level of the individual software developer, the pervasiveness of cognitive biases suggests that the extent to which developers are able to successfully reuse existing code or patterns might depend on two kinds of gaps. First, the degree to which the reused artifact falls short of requirements for the new application might have a negative impact on reuse. In particular, developers might anchor to initial solutions and fail to make necessary adjustments to adapt code or patterns to the problem at hand, such as adding missing functionality or identifying errors in the artifact being reused. Second, the degree to which the reused artifact contains functionality not specified in requirements for the new application might have either a potential positive or negative impact on reuse when developers retain this unrequested functionality in their solutions. In some situations, retaining unrequested functionality might lead to systems that are perceived by the client as better (e.g., containing useful functionality not envisioned during requirements analysis), while, in other situations, the client might conclude that the developer, by adding functionality, has not listened to the client’s needs. These possibilities suggest the need for empirical research to improve our understanding of the impact of cognitive factors such as heuristics and biases on reuse in systems development. Webb and MacMillian [45] point to the potential impact of certain cognitive biases in software engineering and note a lack of empirical research in this area. Moreover, Irwin [18] notes an “absence of empirical research on the effectiveness of reuse or the factors that facilitate or impede reuse” (p. 222). In particular, we are not aware of any empirical evidence on what role, if any, anchoring and adjustment might play in reuse within a systems development context.

3.2.1 Applying Anchoring and Adjustment to the Reuse of Software Engineering Artifacts With respect to reuse of systems development artifacts, we propose that anchoring and adjustment can be understood in terms of two types of developer behavior. These are based on the ways in which any artifact being reused (hereafter termed a reuse artifact) can deviate from requirements for an application in which attempts are made to reuse it. First, the application in question might require functionality not provided by the reuse artifact. If we regard providing the required functionality as amounting to “correctness” in a solution, anchoring, in this case, would

876


mean that developers unconsciously adhere closely to the reuse artifact and fail to adjust sufficiently by making modifications to include requested functionality. We think it is reasonable to assume that developers would not consciously omit functional requirements. Second, a reuse artifact might contain functionality that is erroneous with respect to the requirements specified for an application. For example, an artifact might have functionality requiring that a customer have a membership number, while customer memberships are optional in a new application in which the artifact is being reused. Again, if we treat providing the required functionality as amounting to “correctness” in a solution, anchoring, in this case, would mean that developers unconsciously stick closely to the reuse artifact and, therefore, the errors contained in the artifact propagate to the final solution.

3.2.2 Extending the Notion of Anchoring and Adjustment A reuse artifact can contain functionality not specified in the requirements for the current application (hereafter termed extraneous functionality). In that case, a developer sticking closely to the reuse artifact might still include this extraneous functionality in a design model or code. However, this situation differs from the previous two in several respects. First, the concept of correctness as discussed above does not necessarily hold. If this added functionality does not contradict stated requirements, the notion of a correct solution inherent in the concept of adjustment bias does not apply since providing the extraneous functionality does not necessarily lead to a solution that does not meet user needs. As noted earlier, inclusion of such functionality might be appreciated or rejected by users, depending on the situation. Second, the retention of extraneous functionality might result from conscious consideration by the developer, rather than as an unintended result of an unconscious process (inherent in the traditional view of anchoring and adjustment). If conscious consideration is involved, the inclusion might result from a variety of factors, such developer experience (e.g., with similar projects in the past) or lack thereof (e.g., not recognizing that retaining unrequested functionality might inhibit user acceptance). In view of these factors, we propose a modification to the definition of anchoring and adjustment in the context of dealing with extraneous functionality in reuse artifacts.2 Specifically, we extend the definition of anchoring to include the case in which developers incorporate extraneous functionality from a reuse artifact into a final solution (e.g., design or program). This might have positive or negative consequences, depending on the situation. In some cases, it might lead to the inclusion of enhanced or unconsidered functionality that meets user requirements. In others, it might lead to problems if the extraneous functionality is inconsistent with user requirements and might make maintenance more difficult. 2. Given the differences identified, it might be appropriate to introduce new terminology. However, the terms anchoring and adjustment remain evocative in the context of dealing with extraneous functionality. Therefore, we retain the terms but articulate the differences.

VOL. 30, NO. 12,

DECEMBER 2004

3.3 Implications The following propositions are based upon the pervasiveness of anchoring observed in other contexts and the range of anchoring-related outcomes identified within a development context. Propositions. Given potentially reusable systems development artifacts in a systems development task, developers will: 1. omit more necessary additions, 2. propagate more errors in the artifacts, and 3. include more extraneous functionality, than developers who complete the task without having reuse artifacts available. The remainder of this paper presents two studies that explore these propositions in the contexts of programming and requirements modeling artifacts, respectively. The literature review pointed to the experience level of the developer, the phase in the reuse process, the nature of the reuse artifact, and the context under which the reuse is conducted as factors relevant to understanding the impact of the anchoring heuristic and potential adjustment bias in the context of developing software applications. The studies collectively vary: 1) participants—experts (Study 1) versus novices (Study 2); 2) artifacts—code (Study 1) versus designs (Study 2); and 3) settings—field (Study 1) versus lab (Study 2).

4

STUDY ONE: CODE REUSE

4.1 Experimental Design OO programming offers a highly conducive setting for testing whether anchoring and adjustment affect reuse of code. Given a well-defined programming task and reuse artifacts consisting of a library of classes that can be applied to the task, the extent to which a programmer sticks closely to the reuse artifact (according to the propositions stated above) can be measured easily. By providing code that requires modification in order to strictly satisfy stated requirements, we can measure the extent to which the necessary changes are made. Also, by including additional functionality in the code, we can measure the extent to which this is retained in the final solution. In both cases, comparing the results against a control group receiving no class library support indicates the extent of adjustment bias. 4.1.1 Task Participants were asked to write a simple C++ program to process rental and sales transactions at a video store. A written narrative was provided to participants, outlining the general requirements of the problem (Appendix A.1). Participants were instructed that the “client needs a working prototype that implements the functionality stated in the problem description.” In the experimental scenario, rentals and sales had some similarities: The movie identifier was to be recorded, a transaction total was to be calculated, and the change due back to the customer on payment was to be calculated. In addition, there were several differences: rentals required a membership number (optional for sales), rentals were taxed at a


lower rate, and a due date was to be calculated for movies rented. The experimental task was pretested with five participants. Despite its apparent simplicity, the task required from 1.5 to 3 hours to be completed from scratch. Discussions with pretest participants and observation of their work indicated that much of the time was spent handling the input (menu and data entry) and output (producing the customer receipt). Since this added complexity to the task without addressing the issue of reuse, it was decided for the main study to provide participants with a skeleton program (a main() function in C++) that handled input and output (Fig. 1). This reduced the time to complete the task (to a range of 60 to 90 minutes), allowing participants to focus on writing code to support the transaction logic.

4.1.2 Participants Participants in the experiment were all familiar with OO programming in C++. Their experience ranged from course work only to several years of work experience with OO programming using C++. Participants had, on average, more than 1.5 years of programming in C++ and spent an average of 14 hours per week programming. More than three quarters had received university level training in OO programming. The questionnaire also assessed the level of familiarity with OO concepts by asking participants to rank a list of items in terms of how important they are as OO concepts (e.g., encapsulation, inheritance, and polymorphism). All participants recognized the major concepts of object-orientation. Twenty-three individuals participated in the study and were randomly assigned to either the treatment or control group. 4.1.3 Independent Variable We were interested in the extent and nature of anchoring to library code available for adaptation to the task. In the experimental task, some of the functionality needed to solve the problem was included in a generic Transaction class (Fig. 2). Specifically, this class included common operations such as adding transaction items and calculating totals. The class omitted one requirement stated in the problem description—the calculation of a return date for movie rentals. In addition to the need to add functionality to a generic class, other opportunities for anchoring (from the propositions in Section 3) were tested. The transaction class included functionality that was incorrect, based on the problem description. It contained incorrect tax rates (for rentals and purchases) and did not allow for customer identifiers to be an option in purchase transactions. Finally, two examples of extraneous functionality (i.e., features not required by the problem description) were included. First, the Transaction class included a “tape protection fee” constant. Second, code was included in the main() function requesting “customer type” data. Note that we have spread the extraneous functionality across the Transaction class (given only to the Treatment group)

877

and the main() function (given to both Treatment and Control groups). This prevents us from combining these elements for testing (see Section 4.2.1) since the Treatment and Control groups received identical extraneous functionality with respect to “customer type.” To the extent these features show up in the final solutions, participants are anchoring to the reuse artifact rather than following the requirements specification. In summary, the independent variable was the presence or absence of a reuse artifact that served as a potential anchor. One group of participants (Treatment) was given a Transaction class as described above. The second group of participants (Control) did not receive this class. Both groups were provided with a main() function that handled the required input and output tasks.

4.1.4 Dependent Variables At a gross level, the dependent variable consisted of the solution to the problem. A coding system was developed to measure the extent to which solutions conformed to the functionality stated in the original problem narrative. In particular, in the Treatment group, we measured the extent to which the omissions, errors, and extraneous functionality in the Transaction class showed up in the solutions provided by participants. Similarly, we measured the functionality delivered by the control group. Table 1 lists the specific variables associated with each of the three dependent measures (categories of potential anchoring). In essence, the dependent variables measured the extent to which the potential anchors introduced in the manipulation were preserved in the solutions (in the Treatment group) or the extent to which this functionality was introduced (in the Control group). The measures were coded so that higher scores reflect a greater degree of anchoring. A score was calculated for each of the three dimensions: “omission” (whether the requirements omitted from the Transaction class were included in the final solutions), “error” (whether the errors in the Transaction class were present in the final solutions), and ”extraneous” (whether the unrequested functionality in the Transaction class was carried through to the final solutions). The score on the “error” dimension was calculated for each participant by summing the scores of the three variables making up that dimension. On the “omission” and “extraneous” dimensions, the score was simply taken as the value of the dependent measure. With respect to the two variables used in computing the “extraneous” score, a multipoint scale was used, with values of 0 to 3 on the “customer type” variable (indicating an increasing magnitude of anchoring to the reused code) and 0 to 2 on the “tape protection” variable. Because we provided code to all participants to handle all potential input, code was included in the main() function which requested “customer type” data as input while the problem statement made no reference to differentiating types of customer. Thus, for the purpose of this variable, the Control Group has effectively received a partial treatment. To avoid a potential confound, we keep these variables

878


VOL. 30, NO. 12,

DECEMBER 2004

Fig. 1. main() function provided to participants in study 1.

separate in the analysis (see Section 4.2.1 and Table 2). The “customer type” code could be deleted, left in but not used, or used as the basis to modify the transaction processing functionality of rentals and purchases (e.g., passing

customer type data to rental or purchase objects). Similarly, the constant designated as a tape protection fee within the Transaction class could be deleted from the final solution, left as a constant but not used, or used in modified transaction


879

Fig. 2. Transaction class provided to treatment group.

logic to calculate fees not stated in the written problem specification (the last indicating the highest level of anchoring). As expected, the scores on this variable were always zero in the Control group. The authors independently coded scores. There were only a few minor differences in coding and these were resolved easily by discussing the program code.

4.1.5 Operational Hypotheses Based on the propositions in Section 3 and the operationalization of variables described above, the following hypotheses were tested. Hypothesis 1: OmissionT reatment > OmissionControl .

Participants provided with reusable code (Treatment) will omit from their solutions more of the requirements missing in that code than will participants who are not provided with reusable code (Control). Hypothesis 2: ErrorT reatment > ErrorControl . Participants provided with reusable code (Treatment) will include in their solutions more of the errors (with respect to required functionality) in that code than will participants who are not provided with reusable code (Control). Hypothesis 3: ExtraneousT reatment > ExtraneousControl . Participants provided with reusable code (Treatment) will include in their solutions more of the unrequested

880


VOL. 30, NO. 12,

DECEMBER 2004

TABLE 1 Dependent Variables for Study 1

TABLE 2 t-Test Results for Extraneous and Error Functionality

functionality provided by that code than will participants who are not provided with reusable code (Control).

4.2 Results 4.2.1 Statistical Analysis Since the Omission measure consisted of a single categorical variable (whether or not the requirement to calculate a return date, omitted from the reuse artifact, was omitted from the final solution), a 2 test was used to compare the proportions of participants in each group who omitted the specified functionality. There was no significant difference in the proportions in each group who omitted this functionality (82 percent in the Treatment group versus 67 percent in the Control group; 2 ¼ 0:683). Thus, there is no support for Hypothesis 1.

Table 2 contains the results of t-tests of differences between the Treatment and Control groups on the Error and Extraneous variables. There is one dependent variable associated with each of the hypotheses (scores on questions in each of the subcases of the Extraneous category and the sum of scores for variables in the Error category). Each hypothesis makes a priori predictions about differences in scores between the Treatment and Control groups. Therefore, it is appropriate to test each hypothesis as if it was the only one under consideration rather than make a Bonferroni-style adjustment to the -level to account for multiple dependent variables [46], [47]. As Table 2 shows, the Treatment group did not produce code with significantly more errors than the Control group. Thus, there is no support for Hypothesis 2.


However, Table 2 does provide support for Hypothesis 3. Participants in the Treatment group scored significantly higher than those in the Control group on the inclusion of extraneous functionality (calculating a tape protection fee) in the final solutions. Furthermore, the mean score on the customer type variable (tested as a single sample) was greater than zero. Interestingly, some participants fundamentally changed their program structure to accommodate this functionality. For example, although one piece of the extraneous code simply prompted for a customer type (“Regular,” “Plus,” “Premium”), some participants modified the transaction class to pass this membership information to the rental and purchase objects created during the execution of the program and included comments about how this data might be used.

4.3 Discussion The statistical analysis in the previous section found no differences between the treatment and control groups with respect to the propensity to propagate logical errors in reused code or to omit necessary functionality not contained in the reused code; however, the groups did differ on their propensity to include unrequested functionality. While this analysis points to the need for a greater awareness of the potential for introducing extraneous functionality in a reuse context, it does not provide any insight into the extent to which these developers were aware they were including extraneous functionality. To further our understanding of this issue, we included a question in the exit questionnaire asking participants to list any items in the sample code that either appeared to be extraneous, omitted or inconsistent with the problem description. The following excerpts from the exit questionnaire are insightful. One participant explicitly indicated that “no option for tape protection [was] required by [the] program description,” but still proceeded to include that functionality in the final solution. This suggests that even if an individual is aware that certain functionality is extraneous to the stated requirements, s/he might still be reluctant to remove it from a final solution. Another issue involving the inclusion of functionality was identified from the exit survey. Participants, in addition to anchoring to the solution provided, might, in some cases, also have anchored to domain specific knowledge drawn from experience (i.e., renting movies), while ignoring the documented requirements. For example, one participant noted that s/he “added a function to give the rental due date, which was not given in the problem” (italics ours), despite the fact this was a stated requirement (Appendix A.1). Similarly, another participant added functionality to handle the display of due dates for movie rentals and made a special note that, despite this not being requested, s/he “worked that into the code.” This comment is interesting since the participant added the ubiquitous “winking-smile” to indicate this act was somewhat mischievous. This participant made several comments like “it is likely that the client would want to extend this transaction tracking system” and “there are lots of opportunities to provide

881

capabilities to the system.” These examples demonstrate a strong inclination to add functionality and even plan for future functionality well beyond the stated client requirements. That is, even though these participants appeared not to recognize that calculation of the due dates was a requirement, they still included this functionality in their solution. This offers some qualitative evidence of anchoring to general domain knowledge and not to specific functionality in the sample solution. Finally, one of the last participants in the study summarized the process we are investigating here, noting, “I modified my solution somewhat to conform with the process implemented in the skeleton.” Even though this participant was aware that his/her solution was affected by the sample code provided, s/he was reluctant to move beyond that sample solution. These results have both theoretical and practical relevance. Although the task is simple, the study demonstrates fundamental cognitive processes that can be applied and extended to a programming context. In the extensive reuse literature, we are not aware of any discussion of the potential impact of anchoring and adjustment on reuse practices followed by developers. The results indicate that programmers reusing available code tend to retain and build on functionality in the code that is not contained in the requirements specification. In some cases, it might be advantageous to use a code library containing features that users have not considered, but that might be useful in the final product. However, it might be extremely undesirable for programmers to build on such library functionality without confirming its value with users. With respect to extraneous functionality, the results suggest that programmers are inclined to focus more on the code library, or even general domain knowledge, than on stated requirements. The lack of evidence of anchoring with respect to errors and omitted requirements is also interesting. It suggests programmers are able to identify requirements that are either incorrectly specified in, or missing from, code that is being reused. Additional research is needed to corroborate this finding since the sample size was small and the means were in the direction hypothesized but not statistically different. If it holds, it is important to determine the factors enabling experienced programmers to overcome anchoring and adjustment in the context of errors and omissions. Finally, the exit survey responses indicate a strong “culture of functionality” among programmers by which extra features are assumed to be universally beneficial and desirable. Considered in the context of diffusion research, these extra features can be viewed as innovations subject to a pro-innovation bias [48]. The pro-innovation bias in this context implies that programmers assume all clients want extra functionality and that these innovations should be adopted rapidly and universally. The next section details a second empirical study that builds upon the findings in Study 1 to investigate the role of our extended view of anchoring and adjustment in the context of the reuse of a design artifact.

882

5


STUDY TWO: DESIGN ARTIFACT REUSE

5.1 Study Design The results from Study 1 provide evidence of inclusion of extraneous (with respect to stated requirements) functionality as a significant form of anchoring in code reuse. However, code reuse is just one type of reuse. Some have argued that the real benefits of reuse are likely to accrue from leveraging the investment in earlier systems analysis and design artifacts, as well as in the adaptation of existing libraries of standard design patterns [49]. In this study, we examine aspects of anchoring to earlier artifacts in systems development, specifically, the development of a conceptual model of the classes of objects (or entities) relevant to some application. We are interested in whether the tendency to include extraneous functionality can also be demonstrated in a design task. 5.1.1 Task To gain some insight into the possible influence of anchoring and adjustment on the reuse of design artifacts, participants were asked to develop an Entity-Relationship model for an airline application based on a written narrative describing the domain. The narrative described the operations of a small airline offering sightseeing tours of the Grand Canyon and surrounding areas of the US Southwest, focusing on the types of entities relevant to the operation of the airline, the attributes of these entities, and the relationships among them (Appendix A.2). We used ER diagrams, rather than UML class diagrams, due to the availability of a pool of participants with ER modeling experience. Moreover, given the essential similarity between class diagrams and ER diagrams (both are based on classes/types, attributes, and associations/relationships), models created using each notation are essentially equivalent for the questions of interest in this research. 5.1.2 Participants Participants in the experiment were undergraduate students in computer science. All had completed a database course in which four weeks were devoted to conceptual database design using the Extended ER model. Twenty-one people participated in the study. Students were used in this study for several reasons. First, they represented a convenient pool from which to draw research subjects. Second, anchoring and adjustment are basic psychological activities. The results of Study 1 showed that experts tend to include unrequested functionality present in a reuse artifact; therefore, a study using relative novices broadens the scope of this research. Third, the student subjects in this study are future developers. Therefore, the findings from such a sample would at least have applicability in situations involving inexperienced developers. 5.1.3 Independent Variable Based on the results from Study 1, our primary interest was in establishing whether participants include extraneous elements in a solution if those elements are contained in a design artifact provided to participants for possible adaptation in the solution. Since none of the participants in the control group in Study 1 included any of the

VOL. 30, NO. 12,

DECEMBER 2004

extraneous functionality present in the artifacts provided to the treatment group in that study, it is reasonable to expect a similar outcome if a control group was used in the present study. Therefore, to optimize our use of a limited pool of subjects (enabling us to better assess the size of an effect), the research question was tested using a single-sample posttest design consisting of a treatment group, but no control group [50]. This eliminates the ability to impute causality (unlike Study 1) since participants might still anchor to their general knowledge of the domain by including functionality that seems appropriate, but not required by the requirements statement. However, the design still affords an opportunity to identify whether there is a pattern of results consistent with Study 1. Participants were provided with an Entity-Relationship model for a commercial charter airline operating flights between Canada and tropical vacation destinations (Fig. 3), and told to pretend they had found this model (taken from a project they had previously worked on) in their files. In the instructions, they were advised that they could, if they wished, use this model as a starting point for developing their solution. This sample model constituted the treatment. The model given to participants contained several elements of extraneous functionality with respect to requirements for the sightseeing tour airline. It contained extraneous (i.e., not required by the problem narrative given to participants) entity types (PERSON, EMPLOYEE, AIRCRAFT, MECHANIC, and FLIGHT-ATTENDANT), extraneous attributes of entity types (e.g., FrequentFlyer Number of CUSTOMER), extraneous relationships, and an extraneous type hierarchy. In addition, following the approach used in Study 1, the model provided to participants had some information that contradicted the problem narrative (e.g., relationship cardinalities and relationship names). Finally, the model omitted a number of requirements stated in the problem narrative (including entity types, attributes, relationships, and a type hierarchy). Although a single-sample design does not allow us to draw strong conclusions if these errors and omissions appear in solutions, we included them to parallel the structure of Study 1. With no control group, we can only provide either evidence consistent with the finding in Study 1 of no differences on these variables or evidence inconsistent with Study 1, which would warrant further research.

5.1.4 Dependent Variables At a gross level, the dependent variable consists of the solution to the problem. A coding system was developed to measure the extent to which the solutions conformed to the functionality stated in the original problem narrative. In particular, we measured the extent to which the extraneous functionality in the data model for the charter airline showed up in the final solutions provided by participants for the sightseeing airline. In addition, we measured the extent to which the errors and omitted functionality in the reuse artifact showed up in the final solutions. The two authors independently coded each solution. Very few differences were noted, and these were resolved by discussion.


883

Fig. 3. Analysis model available for potential reuse by participants in study 2.

A score on each of the three dimensions was calculated for each participant by summing the scores of the variables on that dimension. That is, the Extraneous dependent variable score for each participant was the sum of the extraneous requirements provided in the sample model provided to participants that appeared in the solution. The Error dependent variable score for each participant was the sum of the requirements erroneously specified in the sample model provided to participants that remained erroneous in the solution. The Omission dependent variable score for each participant was the sum of the problem requirements not contained in the sample model provided to participants, and that were omitted from the solution. One point was awarded for each extraneous, erroneous, or omitted entity type, attribute, relationship, and type hierarchy. Table 3 shows the specific variables in each category.

5.1.5 Operational Hypotheses Based on the propositions in Section 3 and the operationalization of variables described above, the following hypotheses will be tested. Hypothesis 4: ExtraneousT reatment > 0. Participants will include in their solutions significantly greater than zero elements of unrequired functionality contained in the analysis model available for reuse. Hypothesis 5: ErrorT reatment > 0.

Participants will include in their solutions significantly greater than zero errors (with respect to the required functionality) present in the analysis model available for reuse. Hypothesis 6: OmissionT reatment > 0. Participants will omit from their solutions significantly greater than zero requirements that are not contained in the analysis model made available for reuse.

5.2 Results Table 4 contains the results of single-sample t-tests on each of the three dependent variables of interest (one for each hypothesis above). Each value represents the mean score on one of the aggregate dependent variables of interest. The Extraneous variable is of particular interest since there would be no reason to expect modelers to include these specific items in their models if they did not start from a reuse artifact containing them. Therefore, their presence in solutions would be evidence of anchoring to specific aspects of the reuse artifact, rather than to general domain knowledge about the application. Likewise, there is no reason to expect the specific errors constituting the Error variable (namely, errors in the available reuse artifact with respect to the stated requirements) to appear in a solution developed from scratch. We include the Omissions variable to parallel the first study, recognizing that, in a single sample study, it is impossible to determine whether these omissions are

884


TABLE 3 Dependent Variables for Study 2

TABLE 4 t-Test Results for Study 2

VOL. 30, NO. 12,

DECEMBER 2004


different than would be the case among a group that was starting from scratch (without the aid of a design model they are attempting to reuse). As this is a single-sample study, we are testing the probability that the observed scores are indeed greater than zero. As Table 4 shows, there were highly significant results on each of the dependent variables. In addition, we analyzed results for different types of ER constructs (entity types, type hierarchies, relationships/cardinalities, and attributes). All were significantly greater than zero.

5.3 Discussion This study provides clear evidence of anchoring to extraneous functionality in the use of design artifacts. In particular, consistent with the results of Study 1, participants tended to incorporate extraneous (i.e., not indicated by the requirement statement) functionality in the solutions they constructed. It is evident that the anchoring identified was with respect to specific elements in the reuse artifact provided to participants. However, participants might in some cases be drawing upon their general knowledge of the domain. For example, participants might infer the need to model “aircraft” based on prior experience with airlines. Thus, a conceptual distinction can be drawn between anchoring with respect to general knowledge about entity types in the domain and anchoring to information in the reuse artifact. We did not use this distinction in our coding. In addition, we found that errors with respect to explicit requirements in the reuse artifact tended to propagate to the solutions provided by participants. In the absence of a control group in this study, a strong claim cannot be made regarding this finding since we do not know whether a control group (provided with no reuse artifact) would have included similar errors in their solutions. Nevertheless, it is interesting to note that, unlike Study 1, participants showed a significant tendency to retain, in their final solutions, the errors (with respect to the stated requirements) present in the reuse artifact. These errors were highly specific (e.g., relationship cardinalities, names assigned to entity types and relationships), so it seems implausible that identical errors would appear in solutions generated without the availability of the particular reuse artifact given to the participants. In addition, the results show that requirements missing from the reuse artifact tended to be omitted from the final solutions of participants. Our findings add useful insights into prior research on reuse. We show in an empirical setting that cognitive variables affect the process of adaptive reuse of existing artifacts, as well as the outcome of reusing these artifacts, thus extending the extant research that has focused on technical and organizational factors influencing reuse. In addition, our results indirectly reinforce the conclusions of some prior research on reuse. For example, whereas researchers have pointed to the potential benefits of the use of analogy in specification reuse within requirements analysis [32], our study provides insight into the anchoring heuristic and adjustment bias as one mechanism through which these benefits can be enabled or impaired in practice.

6

885

CONCLUSIONS

Anchoring is a fundamental cognitive heuristic used in problem solving. Prior research has not looked at the potential role of anchoring in software development contexts. We have shown that the definition of anchoring can be applied to reuse in software engineering and have extended the definition to deal with cases in which reuse artifacts contain extraneous functionality with respect to requirements specifications. We have shown empirically in two controlled situations that developers deliver artifacts that exhibit aspects of anchoring, according to our extended definition, in not conforming precisely to stated requirements. The results of both studies are consistent in finding that extraneous requirements in reusable artifacts tend to show up in final solutions. This result spans programming artifacts and design artifacts, as well as both experienced developers (programmers in Study 1) and relatively inexperienced novices (students in Study 2). In addition, while participants in Study 1 did not anchor to errors in, or functionality omitted from, the reuse artifact, participants in Study 2 anchored to both errors and omissions. We speculate this may be because novice analysts do not apply strategies to counteract error detection and omissions that experienced programmers are able to use. Collectively, the results suggest that understanding the cognitive heuristics used by developers can be as important to successful reuse as either technical solutions (repositories of reusable components) or incentives to engage in reuse. Given the observed strength of the tendency to include unrequested functionality, strategies might be needed to counteract potentially detrimental effects of anchoring, such as providing functionality that users have not asked for and view as evidence that developers are not listening to their needs. At the same time, attention should be directed to exploiting potentially positive applications of anchoring by encouraging developers to explain to users their reasoning for including additional functionality (especially since the qualitative evidence from Study 1 shows that at least some of them do so intentionally). In particular, the tendency to retain extraneous functionality in reuse artifacts points to the need for clear communication between developers and users to evaluate the suitability of such functionality and avoid potentially unpleasant surprises at the end of a project. Our research points to the importance of trying to identify when and what might get reused by different developers in various circumstances, so this knowledge can be exploited to benefit a project. For example, more effective and experienced programmers might be granted more access to reuse artifacts than less effective programmers or novices. Alternatively, if it is determined that extraneous requirements are to be avoided, statements to that effect can be provided explicitly in a requirements document in order to prevent or minimize the propagation of extraneous functionality in reuse artifacts. In addition, technologies for locating reuse artifacts in repositories could eventually provide general reminders

886


to the issue or contextual guidance. Further research is needed to investigate these possibilities. The results of these studies need to be interpreted in the context of their limitations. First, both studies are relatively small. It is recognized that obtaining large sample sizes in empirical software engineering research is difficult [52], [53]. Nevertheless, every effort should be made to obtain meaningful sample sizes. Our small samples do not, for example, allow us to test whether, in Study 1, important variables such as years of experience affect the tendency to include extraneous functionality. Second, we demonstrate the applicability of anchoring and adjustment to the reuse of systems development artifacts in a laboratory setting, but do not study real world reuse situations. It might be that development teams have mechanisms in place to support reuse by: identifying anchoring and counteracting the potential negative effects of the adjustment bias, as well as exploiting its potential benefits in terms of adding unrequested but useful functionality. Third, we use very simple tasks amenable to use in a controlled laboratory setting, but that do not necessarily scale up to real projects. Finally, Study 1 does not provide insight into why programmers seem to anchor only to extraneous functionality (not errors or omissions), whereas there is some evidence that the novices in Study 2 exhibit all three forms of anchoring. These apparent differences might be associated with training and/or experience.

7

FUTURE RESEARCH

As suggested by the limitations identified above, it is important to determine whether the findings in these studies can be replicated in a more realistic setting. Moreover, it would be valuable to know whether experience, training, and/or the structure of development teams affect how anchoring is manifested and managed during reuse. More generally, strategies to prevent, detect, and correct potential negative effects of the adjustment bias, as well as to exploit the potential positive effects of consciously incorporating additional functionality, need to be developed. In the studies reported in this paper, we simultaneously varied several dimensions between the studies in order to explore our hypotheses in a range of situations. Future research is needed to isolate these effects by conducting a family of experiments [54] in which each study varies and considers the effects of one factor. Additionally, recent trends in systems development, such as the adoption of agile methods, might affect the extent of anchoring in systems development. For example, extreme programming, while not explicitly recognizing reuse in the context presented in these studies, might lead to “opportunistic,” or ad hoc, reuse. Our research also investigated the anchoring heuristic only in the context of individual programming efforts. Investigations of these phenomena in a team setting, such as the use of programming pairs in extreme programming, are needed to determine whether and how anchoring occurs under such approaches. Finally, this research highlights the importance of understanding the impact of only one cognitive bias on

VOL. 30, NO. 12,

DECEMBER 2004

software engineering; it will be important to examine other cognitive biases (e.g., availability, representativeness) and their potential impact on systems development [45].

APPENDIX COGNITIVE HEURISTICS IN SOFTWARE ENGINEERING: APPLYING AND EXTENDING ANCHORING AND ADJUSTMENT TO ARTIFACT REUSE A.1 Written Narrative Provided to Participants in Study 1 Your client recently purchased a video rental business. This business started out as a small convenience store that had about 50 movies available for rental. This operation grew to the point where the movie rental business became the main activity and much of the convenience store operation has been eliminated. Unfortunately, the accounting system and record keeping methods remained the same throughout this period of high growth and change in product focus. Your task as the consultant hired to fix this problem is to develop a working prototype that demonstrates how rental and sales transactions could be processed. The following information is relevant to constructing a functioning prototype. A.1.1 Inventory The business currently has an inventory of 6,000 movies that are available for rent. There is also a selection of 100 popular new movie titles that are available for direct purchase. All movies have a unique movie ID number and there is only one copy of each movie available for rent or purchase. Rented movies are due back by midnight of the day following the date the movie was rented. A.1.2 Rental and Purchase Transactions Customers can either rent from the 6,000 rental titles or purchase from the 100 sale titles. Available rental movies are rented for $3.50. Sale titles sell for $19.95. A customer renting a movie must have a valid membership number while movies can be purchased by anyone. A customer may rent or purchase one or more movies in a single transaction. Rentals and purchases will be treated as separate transactions. Rental. During the rental process, the customer’s membership number must be recorded as part of the transaction. (At this stage, we will not deal with a transaction for creating new memberships.) In addition, the movie ID and the date and time of rental must be entered and stored. During the transaction, the amount due must be calculated (subtotal of rentals plus HST) and displayed. The movie due date should also be calculated and displayed. Finally, the amount tendered by the customer must be entered, and the amount of change due back to the customer must be calculated and displayed. (At this stage, we will assume all payments are by cash.) Purchase. During a purchase, the movie ID and the purchase date and time must be recorded. In addition, if the purchaser is a member, the customer’s membership number should be recorded. During the transaction, the amount due must be calculated (subtotal of purchases plus HST) and


displayed. The movie due date should also be calculated. Finally, the amount tendered by the customer must be entered, and the amount of change due back to the customer must be calculated. (At this stage, we will assume all payments are by cash.) The main() function provided to participants in study 1 is shown in Fig. 2.

A.2 Written Narrative Provided to Participants in Study 2 Grandview Air Tours is a small airline offering sightseeing tours of the Grand Canyon and surrounding areas of the US Southwest. The airline operates scheduled flights daily, as well as chartered flights for groups on an as-needed basis. Individual customers call to make bookings on scheduled flights. Each scheduled flight has scheduled departure time, length, cost, and itinerary (e.g., “Grand Canyon” and “Death Valley” would be examples of itineraries). The airline maintains customer names, addresses (street, city, state, and zip code), and the names and telephone numbers of next-of-kin. A customer may have multiple bookings at any time, and a booking may involve one or more customers (e.g., a booking for four people). Each booking involves a single flight, while a flight can have many bookings. Chartered flights have no scheduled departure time, length, or itinerary. A chartered flight has exactly one booking, involving one or more customers. Each flight is assigned to one qualified pilot. A pilot may be assigned many flights. Information to be kept about pilots includes name, rating, and hours flown. The analysis model available for potential reuse by participants in study 2 is shown in Fig. 3.

[9] [10]

[11]

[12] [13]

[14]

[15]

[16] [17] [18]

[19]

[20]

[21]

[22] [23]

ACKNOWLEDGMENTS

[24]

The authors wish to thank the senior editor and two anonymous reviewers, as well as participants in a research seminar at Tulane University, for their valuable comments on earlier versions of this paper. This work was supported in part by grants from the Social Sciences and Humanities Research Council of Canada and the Natural Sciences and Engineering Council of Canada to Jeffrey Parsons.

[25] [26]

[27] [28] [29]

REFERENCES [1] [2] [3] [4] [5] [6] [7] [8]

B. Cox, “Planning the Software Industrial Revolution,” IEEE Software, vol. 7, no. 6, pp. 25-33, Dec. 1990. H. Mili, F. Mili, and A. Mili, “Reusing Software: Issues and Research Direction,” IEEE Trans. Software Eng., vol. 21, no. 6, pp. 528-561, Dec. 1995. M. Morisio, M. Ezran, and C. Tully, “Success and Failure Factors in Software Reuse,” IEEE Trans. Software Eng., vol. 28, no. 4, pp. 340-357, Apr. 2002. P.W. Fach, “Design Reuse through Frameworks and Patterns,” IEEE Software, vol. 18, no. 5, pp. 71-76, Sept./Oct. 2001. M. Fowler, Analysis Patterns: Reusable Object Models. AddisonWesley, 1997. E. Gamma, R. Helm, R. Johnson, and J. Vissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994. D.C. Schmidt, “Using Design Patterns to Develop Reusable Object-Oriented Communication Software,” Comm. ACM, vol. 38, no. 10, pp. 65-76, 1995. W.B. Frakes and G. Succi, “An Industrial Study of Reuse, Quality and Productivity,” J. Systems and Software, vol. 57, no. 2, pp. 99106, 2001.

[30]

[31]

[32] [33]

[34] [35]

[36]

887

M. Griss, “Software Reuse: From Library to Factory,” IBM Systems J., vol. 32, no. 4, pp. 548-566, 1993. G. Succi, L. Benedicenti, and T. Vernazza, “Analysis of the Effects of Software Reuse on Customer Satisfaction in an RPG Environment,” IEEE Trans. Software Eng., vol. 27, no. 5, pp. 473-479, May 2001. Y. Kim and E.A. Stohr, “Software Reuse: Survey and Research Directions,” J. Management Information Systems, vol. 14, no. 4, pp. 113-147, 1998. W. Lim, “Effects of Reuse on Quality, Productivity, and Economics,” IEEE Software, vol. 11, no. 5, pp. 23-30, Oct. 1994. M.A. Rothenberger and K.J. Dooley, “A Performance Measure for Software Reuse Projects,” Decision Sciences, vol. 30, no. 4, pp. 11311153, 1999. R. Fichman and C.F. Kemerer, “Object Technology and Reuse: Lessons from Early Adopters,” Computer, vol. 30, no. 10, pp. 47-59, Oct. 1997. R. Fichman and C.F. Kemerer, “Incentive Compatibility and Systematic Software Reuse,” J. Systems and Software, vol. 57, no. 1, pp. 45-60, 2001. T. Love, Object Lessons: Lessons Learned in Object-Oriented Development Projects. New York: SIGS Books, 1993. W.B. Frakes and C. Terry, “Software Reuse: Metrics and Models,” ACM Computing Surveys, vol. 28, no. 2, pp. 415-435, 1996. G. Irwin, “The Role of Similarity in the Reuse of Object-Oriented Analysis Models,” J. Management Information Systems, vol. 19, no. 2, pp. 221-250, 2002. A. Sen, “The Role of Opportunism in the Software Design Reuse Process,” IEEE Trans. Software Eng., vol. 23, no. 7, pp. 418-436, July 1997. A. Mili, S. Yacoub, E. Addy, and H. Mili, “Toward an Engineering Discipline of Software Re-use,” IEEE Software, vol. 16, no. 5, pp. 2231, Sept./Oct. 1999. S. Purao, V. Storey, and T. Han, “Improving Analysis Pattern Reuse in Conceptual Design: Augmenting Automated Processes with Supervised Learning,” Information Systems Research, vol. 14, no. 3, pp. 269-290, 2003. V. Sugumaran, M. Tanniru, and V. Storey, “Supporting Reuse in Systems Analysis,” Comm. ACM, vol. 40, no. 11, pp. 312-322, 2000. I. Jacobson, M. Griss, and P. Jonsson, “Making the Reuse Business Work,” Computer, vol. 30, no. 10, pp. 36-42, Oct. 1997. G. Lakoff, Women, Fire and Dangerous Things: What Categories Reveal about the Mind. Chicago: Univ. of Chicago Press, 1987. E. Smith and D. Medin, Categories and Concepts. Cambridge, Mass.: Harvard Univ. Press, 1981. G.S.J. Novak, “Creation of Views for Reuse of Software with Different Data Representations,” IEEE Trans. Software Eng., vol. 21, no. 12, pp. 993-1005, Dec. 1995. J. Parsons and Y. Wand, “Choosing Classes in Conceptual Modeling,” Comm. ACM, vol. 40, no. 6, pp. 63-69, 1997. S. Navathe, R. Elmasri, and J. Larson, “Integrating User Views in Database Design,” Computer, vol. 19, no. 6, pp. 50-62, June 1986. T. Ravichandran and M.A. Rothenberger, “Software Reuse Strategies and Component Markets,” Comm. ACM, vol. 46, no. 8, pp. 109-114, 2003. K. Maruyama and K.-i. Shima, “An Automatic Class Generation Mechanism by Using Method Integration,” IEEE Trans. Software Eng., vol. 26, no. 5, pp. 425-440, May 2000. J. Kim and F.J. Lerch, “Why Is Programming (Sometimes) So Difficult? Programming as Scientific Discovery in Multiple Problem Spaces,” Information Systems Research, vol. 8, no. 1, pp. 25-50, 1997. N. Maiden and A. Sutcliffe, “Exploiting Reusable Specification Through Analogy,” Comm. ACM, vol. 35, no. 4, pp. 55-64, 1992. D. Batra and S.R. Anthony, “Novice Errors in Conceptual Database Design,” European J. Information Systems, vol. 3, no. 1, pp. 57-69, 1994. S. Plous, The Psychology of Judgment and Decision Making. New York: McGraw-Hill, 1993. M.E. Schweitzer and G.P. Cachon, “Decision Bias in the Newsvendor Problem with a Known Demand Distribution: Experimental Evidence,” Management Science, vol. 46, no. 2, pp. 404-420, 2000. J.T. Buchanan and J.L. Corner, “The Effects of Anchoring in Interactive MCDM Solutions Methods,” Computers and Operations Research, vol. 24, no. 10, pp. 907-918, 1997.

888


[37] J.F. George, K. Duffy, and M. Ahuja, “Countering the Anchoring and Adjustment Bias with Decision Support Systems,” Decision Support Systems, vol. 29, pp. 195-206, 2000. [38] V. Venkatesh, “Determinants of Perceived Ease of Use: Integrating Control, Intrinsic Motivation, and Emotion into the Technology Acceptance Model,” Information Systems Research, vol. 11, no. 4, pp. 342-365, 2000. [39] V. Venkatesh and M.G. Morris, “Why Don’t Men Ever Stop to Ask for Directions? Gender, Social Influence, and Their Role in Technology Acceptance and Usage Behavior,” MIS Quarterly, vol. 24, no. 1, pp. 115-139, 2000. [40] C.B. Mervis and E. Rosch, “Categorization of Natural Objects,” Ann. Rev. of Psychology, vol 32, pp. 89-115, 1981. [41] J.R. Bettman and M. Sujan, “Effects of Framing on Evaluation of Comparable and Noncomparable Alternatives by Expert and Novice Consumers,” J. Consumer Research, vol. 14, pp. 141-154, 1987. [42] A. Tversky and D. Kahneman, “Judgment under Uncertainty: Heuristics and Biases,” Science, vol. 185, no. 4157, pp. 1124-1131, 1974. [43] D. Farchamps, “Organizational Factors and Reuse,” IEEE Software, vol. 11, no. 5, pp. 31-41, Oct. 1994. [44] M. Pittman, “Lessons Learned in Managing Object-Oriented Development,” IEEE Software, vol. 10, no. 1, pp. 43-53, Feb. 1993. [45] S. Webb and J. MacMillian, “Cognitive Bias in Software Engineering,” Comm. ACM, vol. 38, no. 6, pp. 57-69, 1995. [46] N. Cliff, Analyzing Multivariate Data. San Diego, Calif.: Harcourt Brace Jovanovich, 1987. [47] R. Harris, A Primer of Multivariate Statistics. New York: Academic Press, 1975. [48] E.M. Rogers, Diffusion of Innovations, fourth ed. New York: The Free Press, 1995. [49] B.W. Boehm and P.N. Papaccio, “Understanding and Controlling Software Costs,” IEEE Trans. Software Eng., vol. 14, no. 10, pp. 14621477, Oct. 1988. [50] C.W. Emory, Business Research Methods. Homewood, Ill.: Irwin, 1980. [51] B.P. Lientz and E.B. Swanson, “Discovering Issues in Software Maintenance,” Data Management, vol. 16, no. 10, pp. 15-24, 1978. [52] B.A. Kitchenham, S.L. Pflegger, L.M. Pickard, P.W. Jones, D.C. Hoaglin, K. El-Eman, and J. Rosenberg, “Preliminary Guidelines for Empirical Research in Software Engineering,” IEEE Trans. Software Eng., vol. 28, no. 8, pp. 721-734 Aug. 2002. [53] S.L. Pfleeger, Software Engineering Theory and Practice, second ed. Upper Saddle River, N.J.: Prentice Hall, 2001. [54] V.R. Basili and F. Lanubile, “Building Knowledge through Families of Experiments,” IEEE Trans. Software Eng., vol. 25, no. 4, pp. 456-473, July/Aug. 1999.

VOL. 30, NO. 12,

DECEMBER 2004

Jeffrey Parsons received the BComm (honours) degree from Memorial University of Newfoundland in 1985, and the PhD degree from the University of British Columbia in 1992. He was on the faculty at the University of Manitoba for two years, was a visiting faculty member at the University of Pennsylvania, and is currently a professor and associate dean (research) on the Faculty of Business Administration at Memorial University of Newfoundland. He cochaired the 2001 Workshop on Information Technologies and Systems. His research is funded by the Natural Sciences and Engineering Research Councial of Canada and the Social Sciences and Humanities Research Council of Canada. His work has appeared in journals such as the ACM Transactions on Database Systems, Communications of the ACM, Journal of Management Information Systems, and Management Science. His current research interests include artifact reuse in systems development, conceptual modeling, database design, and recommender systems. He is a member of the IEEE Computer Society, ACM, Institute for Operations Research and Management Science, and Association for Information Systems. Chad Saunders received the BSc degree in 1996 and MBA degree in 2000 from Memorial University of Newfoundland. He is currently a PhD candidate in mangement information systems at the Haskayne School of Business, University of Calgary. His current research interests focus on the impact of the use of knowledge management systems on professional practice.

. For more information on this or any other computing topic, please visit our Digital Library at www.computer.org/publications/dlib.