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 

Productivity in computing hardware for decades has roughly followed Moore’s Law in

producing doubled power at lower cost every 1.5 years or so. Similarly, the productivity

associated with networking technology continues growing exponentially as each new

user added creates value for all previously installed users. Only in the arena of software

development does productivity seem to be progressing slowly — if at all.

One target area for improving software development productivity has been documentation

and requirements structuring. For example data flow diagrams (De Marco, 1978), data

modeling (Chen, 1976), and the object-oriented modeling (Brown, 2002) have all been

added to the repertoire of systems designers. The underlying concept is that visual

representation, accuracy, and a fairly straightforward nomenclature in modeling system

characteristics can serve to help bridge understandings among system users, developers,

and programmers. Such understandings should allow for reducing the number of

systems that are technically valid but don’t address business problems and should

provide clarity for technical designers and coders to more efficiently translate requirements

into artifacts.

Despite the contributions to increased software quality because of the employment of

these techniques for representation, problems remain (Sauer, 1999). It is reported that

only 12 percent of information system projects are delivered on time and on budget. The

most often mentioned reasons for failure are not meeting users’ requirements, impaired

functionality, and purely technical problems.

Based on these observations, the objective of the present research was formulated as

increasing our understanding of how the phenomenon of representation is managed and

used in today’s business organizations; when does it work; when does it not; what are

reasons for its successful or failed employment? We realized that these issues are not

only related to projects but also to corporate efforts to define and standardize approaches

to software development, education, and outsourcing — just to mention a few dimensions.

Techniques for documentation and requirements structuring must be understood

in an organizational context.

In this study, we focused on one particular approach to system representation, the

Unified Modeling Language (UML) (Booch, Rumbaugh & Jacobson 1999). UML is the

most recent among approaches to representation and it is the most complete approach

spanning from user-information processes to implementation concerns. It is also widely

held to be the future approach to modeling information systems.

The present chapter tells the story of our initial efforts to understand the use of UML

in an organizational context. We don’t present a traditional report on completed research.

Rather, we describe and discuss the issues addressed and the decisions made in our early

search for theory, why a data driven approach may be appropriate, why causal mapping

was chosen as the method of analysis, emerging results, and lessons learned from this

first attempt at creating some kind of order in a highly complex and disjointed research

area. The chapter proceeds with theory and research approach. Next follows methodology,

followed by material about developing causal maps, leading into challenges in using

causal maps and lessons learned. The last section is the conclusion.