Introduction

К оглавлению
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 
34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 
68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 
102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 
119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 
136 137 138 139 140 141 142 143 144 145 146 

The original work of Axelrod (1976) on causal mapping has remained a standard adopted

by others extending the technique to discovery (e.g., Fiol & Huff, 1992), evocative (e.g.,

Nelson, Nadkarni, Narayanan & Ghods, 2000) and intervention (Hodgkinson & Wright,

2002) settings to name a few. While some methodological properties of causal mapping

have recently come under scrutiny (Mohammed, Klimoski & Rentsch, 2001; Nadkarni &

Narayanan, in press), one fundamental question remains unanswered: How do the data

yielded by causal mapping techniques compare with the data obtained by other methods?

Without works comparing alternate methodologies, we cannot be fully confident of the

meaning of the data yielded by causal mapping, much less the appropriateness of the

technique to different research settings.

In this chapter we advance the causal mapping method using a comparative study that

links causal mapping data with data obtained from surveys. We take a cue from Nelson

et al. (2000), who argued that causal maps are a starting point for capturing concepts in

an exploratory context, but the concepts then become the basis of constructing large

sample surveys for validation and hypothesis testing. The domain used for this study

is object-oriented (OO) software development, which is a developing domain, and as

such robust theories that capture this domain are absent. This necessitates exploratory

works and we employ causal mapping to characterize the domain. We validate the causal

maps by administering a relatively large sample survey that in turn provides a basis of

comparison for the causal maps.

Thus the central objective of this chapter is to demonstrate an approach to couple

revealed causal maps (RCMs) developed in “evocative” domains (Nelson et al., 2000) and

large scale surveys designed for statistically based hypothesis testing. Put another way,

we propose a strategy for systematically linking discovery and hypothesis testing

contexts. An ancillary objective is to demonstrate how the approach triangulates the

causal mapping technique with survey methods, thus exploring the validity of the causal

mapping technique

To meet these objectives we organize the paper as follows: First, we establish the context

of the study, OO software development; second, we summarize the conceptual underpinnings

of the study and the strategy for triangulation; third, we provide a detailed

description of the methodology used; we then report the results of the study and finally

discuss the lessons learned.

The Context: Object-Oriented (OO)

Software Development

“OO software development” refers to a set of principles guiding software development

that emphasizes organization based on both information and processing, and that

manipulates the information according to the real-world objects that the information

describes (Brown, 1997). Unlike other approaches such as procedural software development,

OO has come into vogue more recently and theories about OO are still evolving.

As software development is knowledge work, its most important resource is expertise

(Faraj & Sproull, 2000). Yet, a systematic identification of the major constructs for objectoriented

software development expertise has yet to receive significant attention. While

there has been an exploratory study linking cognition and OO concepts (Sheetz &

Tegarden, 2001), to date no research has empirically tested the evoked theories of OO

software development. This provides the perfect context to evoke and empirically test

theories of expertise. As noted by Nelson et al. (2000, p.482), “in evocative studies,

domain experts are available, but work is needed to evoke their knowledge and cast it into

available theoretical frameworks to construct domain specific theories.”

We conducted an extensive review of theoretical literature to identify the frameworks

available to investigate OO software development. Theoretical sources we reviewed

included textbooks on traditional software development (e.g., Dennis & Wixom, 1999;

Hoffer, Valacich & George, 2001), OO software development (e.g., Brown, 1997; Martin

& Odell, 1995; Norman, 1996), “classic” books on OO software development (e.g., Booch,

1994; Coad & Yourdon, 1991a, 1991b; Henderson-Sellers, 1992; Rumbaugh, Blaha,

Premerlani, Eddi & Lorensen, 1991) and seminal articles in OO software development

(e.g., Detienne, 1995; Fichman & Kemerer, 1992; Rosson & Alpert, 1990; Villeneuve &

Fedorowicz, 1997). Table 1 lists a sample of the potential OO theories that could be used

as a starting point for this research.

The abundance of theoretical frameworks is one indicator that OO theory development

is in the early stages. To reduce the number of theories to a manageable set, we employed

two criteria: comprehensiveness and diversity. Since this was an exploratory study, we

wanted to use frameworks that represented the widest range of conceptualizations

possible. Comprehensiveness was defined as the number of concepts identified in the

Table 1. Sample of potential OO theories used in classification scheme

Author Theoretical Framework Comments

Armstrong Four OO Characteristics: Behavior,

Structure, OO Modeling/Analysis and OO

Development

Included second largest percentage of

overlap with concepts elicited in this

study (42%)

Bansiya and Davis OO Design concepts: messaging,

composition, inheritance, polymorphism,

class hierarchies

Did not include a significant percentage

of the concepts elicited in this study

(16%)

Coad and Yourdon Five OO Characteristics: encapsulation,

inheritance, message-passing, objects,

polymorphism

Did not include a significant percentage

of the concepts elicited in this study

(26%)

Henderson-Sellers OO Triangle consists of encapsulation,

abstraction, and polymorphism

Framework included third largest

percentage of overlap with concepts

elicited in this study (37%)

Rosson and Alpert Four OO characteristics: communicating

objects, abstraction, problem oriented

design, and shared behavior

Framework included largest percentage of

overlap with concepts elicited in this

study (53%)

Sutcliffe Four features of OO models: abstraction,

classification, inheritance and

encapsulation

Did not include a significant percentage

of the concepts elicited in this study

(21%)

Wegner OO concepts: complex objects, object

identity, methods, encapsulation, typing

and inheritance

Did not include a significant percentage

of the concepts elicited in this study

(21%)

framework: The more concepts the framework had, the more comprehensive the framework.

Several of the frameworks were too restricted in the number and variety concepts

they included and thus were not appropriate for this study. Diversity was assessed by

comparing the frameworks to each other. For example, the Booch (1994) framework was

almost identical to the Coad and Yourdon (1991) framework and was thus eliminated as

a candidate early in the selection process. As a result, we narrowed the theoretical

frameworks to three, the major constructs of each are presented in Table 2.

• Theoretical Framework I was developed by grouping concepts based on the

categorization scheme presented by Rosson and Alpert (1990) and utilized by

Sheetz and Tegarden (2001) in their study linking cognitive activities to objectoriented

design complexity. The categories Rosson and Alpert suggested were:

Communicating Objects, Abstraction, Problem-Oriented Design, and Shared Behavior.

The Communicating Objects category contains concepts such as message

passing; the Abstraction category contains concepts such as abstraction and

encapsulation; the Problem-Oriented Design category contains concepts such as

modeling objects; and the Shared Behavior category contains concepts such as

inheritance and class.

• Theoretical Framework II was adapted from Henderson-Sellers (1992). His book

compiles several research articles into the idea of an object-oriented triangle (see

Henderson-Sellers (1992) for a summarization of supporting literature). The first

corner includes the concepts of encapsulation and information hiding. The second

corner includes the concepts of abstraction, classes and objects. The third corner

includes the concepts of inheritance and polymorphism.

• Theoretical Framework III was developed from Armstrong (in press). The categories

suggested were based on the object-oriented model and consist of Behavior,

Structure, OO Modeling/Analysis and OO Development. The Behavior construct

contains concepts such as message passing and collaboration and is focused on

the object actions within the system. The Structure construct contains concepts

such as attribute, class and object and is focused on the relationships between

classes and objects and the mechanisms that support the class/object structure.

The OO Modeling/Analysis construct contains concepts such as identifying

objects and is focused on the analysis phase and identifying the “things” or

objects in the problem under study. The OO Development construct contains

concepts such as framework and layer and is focused on the overall development

of OO.

Table 2. Chosen theoretical framework constructs

Framework 1

Rosson and Alpert

Framework 2

Henderson-Sellers

Framework 3

Armstrong

Shared Behavior Information Hiding, Encapsulation Structure

Problem Oriented Design Abstraction, Class, Object Behavior

Communication Inheritance, Polymorphism OO Modeling /Analysis

Abstraction OO Development Concepts

The underlying strategy for triangulation of RCMs and surveys employed in this study

is anchored in key epistemological underpinnings, which we summarize before we detail

the method.