Information and Software Technology 47 (2005) 383–397 www.elsevier.com/locate/infsof
Does UML make the grade? Insights from the software development community Martin Grossmana,*, Jay E. Aronsonb,1, Richard V. McCarthyc,2 b
a Department of Management, Bridgewater State College, Bridgewater, MA 02325, USA Department of Management Information Systems, Terry College of Business, University of Georgia, Athens, GA 30602, USA c Lender School of Business, Quinnipiac University, Hamden, CT 06518, USA
Received 25 January 2004 Available online 11 November 2004
Abstract The Unified Modeling Language (UML) has become the de facto standard for systems development and has been promoted as a technology that will help solve some of the longstanding problems in the software industry. However, there is still little empirical evidence supporting the claim that UML is an effective approach to modeling software systems. Indeed, there is much anecdotal evidence suggesting the contrary, i.e. that UML is overly complex, inconsistent, incomplete and difficult to learn. This paper describes an investigation into the adoption and use of UML in the software development community. A web-based survey was conducted eliciting responses from users of UML worldwide. Results indicate a wide diversity of opinion regarding UML, reflecting the relative immaturity of the technology as well as the controversy over its effectiveness. This paper discusses the results of the survey and charts of the course for future research in UML usage. q 2004 Elsevier B.V. All rights reserved. Keywords: Unified Modeling Language; UML; Object-oriented analysis and design; OOAD; Task-technology fit
1. Introduction Object-oriented (OO) technology has profoundly changed the way software systems are designed and developed [44]. Proponents of OO technology are quick to claim the advantages over the traditional structured or processoriented (PO) approaches, such as easier modeling, increased code reuse, higher system quality, and easier maintenance [17,26]. Indeed, object-oriented technology has often been promoted as a silver bullet, capable of solving many of the longstanding ills facing the software industry. The advent of the Unified Modeling Language (UML) has fueled the continued growth and acceptance of objectoriented technology. UML is a visual modeling language, * Corresponding author. Tel.: C1 508 531 2723. E-mail addresses:
[email protected] (M. Grossman), jaronson @uga.edu (J.E. Aronson),
[email protected] (R. V. McCarthy). 1 Tel.: C1 706 542 0991. 2 Tel.: C1 203 582 8468. 0950-5849/$ - see front matter q 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.infsof.2004.09.005
composed of notations and textual components to express object-oriented system designs [16]. During the early 1990s, the object-oriented methods landscape was one of the contention and confusion. Prior to 1994, there were many competing visual modeling languages and methodologies on the market. All of these had their loyal followers as well as their detractors, and the selection of one technique over another was not an easy choice. The impetus behind UML was to fuse, or unify, the best practices from the strongest of these methods. Ultimately, three methods emerged as the primary contenders: the Booch Method [4], the Object Modeling Technique or OMT [33], and the Objectory Method [25]. Elements from each of these methods make up the core of UML, and the primary authors, better known as ‘the Three Amigos,’ are still working on the ever evolving UML specification, along with many other participants, under the tutelage of the Object Management Group (OMG). Although UML has achieved tremendous popularity and is rapidly becoming the standard for object-oriented systems development, there are many who feel that it is
384
M. Grossman et al. / Information and Software Technology 47 (2005) 383–397
too difficult to use and that it is not fulfilling its promise. Commonly heard complaints about UML are that it is too big and complex, it is semantically imprecise, it is implemented in a non-standard manner, it has limited customizability, it has inadequate support for componentbased development, and that it is unable to easily interchange model diagrams [28]. Much of the existing literature relating to UML usage focuses on such shortcomings [11,18,22,24,36,42]. However, there is still very little empirical evidence available describing the actual usage patterns or performance impacts of UML. There is a critical need for such empirical research to determine how UML is currently being used, how it is perceived by those individuals using it, and what individual, task and organizational factors are impacting its use. A number of research models have emerged that attempt to explain the acceptance and utilization of technology. One such framework is provided by task-technology fit (TTF) theory [19,20] which links performance with the fit between the task being performed and the particular type of technology being utilized. Researchers have used the TTF framework to investigate a wide assortment of information technologies, such as software maintenance tools [9], knowledge management systems [31], data warehousing [30], simulation modeling [10], the World Wide Web [7,38], e-commerce [43], manufacturing task support systems [40], group support systems [32,34,45] and enterprise resource planning [37]. Assuming that we can learn to select technologies that are a better fit within the context of the organization, the research in this area has several important implications for managers planning enterprise wide strategy. The present study was conducted to explore how the adoption and usage of UML can be explained using the TTF framework.
The variables to be tested in this study are adapted from Goodhue’s task-technology fit instrument [19]. They include: 1. 2. 3. 4. 5. 6. 7. 8.
Right data Accuracy Compatibility Flexibility Understandability Level of detail Training Ambiguity
The survey questions were modified to reflect that the technology in question is UML and not information systems in general. The first part of the survey consists of UML usage questions mapped directly to the task-technology fit constructs as described by Goodhue [19] with some modifications to make it UML specific. These questions were presented in a random order to avoid clustering by variable. Respondents were asked to indicate the answers to these questions using a Likert scale providing five possible levels of agreement (strongly disagree to strongly agree). The second part of the survey contained questions which asked for additional information, divided into four subsections. The first subsection relates to individual characteristics such as gender, educational background, and experience level. The second subsection deals with project characteristics such as the type and complexity of application being developed. The third subsection focuses on organizational characteristics, such as corporate culture and industry sector. Subsection four contained questions specifically relating to UML and how it is being utilized in the specific environment of the respondent. 2.2. Survey administration
2. Methodology 2.1. Survey development A review of the literature surrounding UML usage led to the following questions: 1. Do individuals who use UML perceive it to be beneficial? 2. Does UML provide a task-technology fit to individuals who utilize it? 3. What are the characteristics that affect UML use? The survey research instrument was developed utilizing constructs that were originally developed by Goodhue and Thompson [19] and subsequently expanded by a number of other researchers [9,20,31]. The sample population for this survey consisted of information technology professionals with experience utilizing UML for systems development.
The sample population used in this study was derived by accessing various online newsgroups with threads relating to UML, object-oriented analysis and design tools and software development methodologies (e.g. The UML Forum, UML Cafe´, Objects by Design Forum, UML Zone, The Precise UML Newsgroup, Rational Unified Process Forum, Sparx System Forum, Rose Forum, Object Technology User Group). The e-mail addresses of UML users were culled from the archives of these discussion groups as well as from other sources (e.g. UML related user groups, Web sites, conferences, and articles) and entered into a database of survey subjects. Targeting participants in this manner increased the chances that the population consisted only of those information technology professionals who have actually used UML on software development projects. Only those individuals believed to be serious users of UML, based on the context of the environment in which their name was encountered, were selected for the survey. There is a certain level of bias
M. Grossman et al. / Information and Software Technology 47 (2005) 383–397
inherent in survey research of this kind, since only interested parties can be solicited. Direct e-mails were sent to all of individuals in the database, asking them if they would volunteer to participate in a survey on UML usage and providing a link to the actual survey page. Of the 1507 e-mails initially sent, 133 did not reach their intended recipient, and bounced back. Of the remaining 1374 emails, a total of 150 users responded to the survey (over 83% of whom responded within 72 h from the time the emails were initially sent). This represents a response rate of 10.91%. Considering that no monetary incentives were offered to entice respondents to complete this survey, a practice typically used by commercial Internet researchers [12], this response rate was considered to be a reasonably good outcome. The response rate in this study can be attributed in part to the interest level of the targeted group of UML users solicited. Based on the percentage of subjects who provided additional comments on the survey (28.2%) and who indicated a willingness to participate in future studies (58.8%), one may conclude that the individuals who did respond to this survey were relatively opinionated regarding UML usage and eager to express their views. Nineteen surveys were eliminated from the sample due to incomplete responses, leaving the final sample size used in this study at 131.
3. Results 3.1. Instrument validity and reliability The present study consisted of 32 survey questions, mapped to eight variables. Variables were derived from the original task-technology fit study of Goodhue and Thompson [20], with some minor modifications to reflect UML usage. Cronbach’s alphas were computed for each of the eight variables. Reliability coefficients for each of the variables are shown in Table 1. Three of the constructs (accuracy, compatibility and level of detail) exhibited Cronbach’s alphas below the accepted value of 0.70 and were therefore eliminated from the study. To determine the validity of the remaining constructs, a Pearson product-moment correlation was performed. Strong positive correlations at the 0.01 level of Table 1 Cronbach’s alpha reliability analysis
385
Table 2 Pearson’s correlation coefficients for task variables Variable
Correlation coefficient
Flexibility Right data Understandability Training Ambiguity
0.888** 0.902** 0.664** 0.712** K0.174*
**Correlation is significant at the 0.01 level (2-tailed). *Correlation is significant at the 0.05 level (2-tailed).
significance were exhibited for flexibility, right data, understandability and training. The ambiguity variable however, exhibited a negative correlation at the 0.05 level (Table 2). 3.2. Respondent characteristics To be included in this survey the respondent had to be directly involved with UML. Aside from that requirement, there were no other criteria for inclusion in the sample. One area of interest is the educational level of the respondents. Table 3 reveals that over 87% of the population had at least a Bachelors degree. Also relevant to the discussion of UML usage is that of experience in object-oriented technology. Experience level has been considered in a number of research studies on object-oriented analysis and design [1,14]. As revealed in Table 4, 57% of the respondents in the present study have over six years of experience using object-oriented technology while less than 5% have one year or less. This is significant because it indicates that our sample population is well qualified to assess the task-technology fit of UML. The likelihood of obtaining an international sample was greatly increased because the World Wide Web was used as the primary means of locating subjects. In this study, the sample population was representative of the global software development community, consisting of individuals from many different countries. This is reflective of the global following that UML has achieved and the fact that it is quickly becoming an international standard. Two survey questions asked for country data, one relating to country of origin of the developer and the other to the location of the organization in which UML is being used. Tables 5 and 6 show the breakdown of countries in each of these categories. Table 3 Educational level
Variable
Number of items
Reliability
Right data Accuracy Compatibility Flexibility Understandability Level of detail Training Ambiguity
4 4 4 4 4 4 4 4
0.7732 0.4446 0.6003 0.8175 0.7427 0.6280 0.7517 0.7584
Educational level
Frequency
Percent
Cumulative percent
No response Bachelors degree High school graduate Masters degree or above Some college Total
1 57 3 57 13 131
0.8 43.5 2.3 43.5 9.9 100.0
0.8 44.3 46.6 90.1 100.0
386
M. Grossman et al. / Information and Software Technology 47 (2005) 383–397
Table 4 Number of years experience with object-oriented technology
Table 6 Location of organization
Years experience
Frequency
Percent
Cumulative percent
Country
Frequency
Percent
Cumulative percent
0–1 2–3 4–5 6C Total
6 24 26 75 131
4.6 18.3 19.8 57.3 100.0
4.6 22.9 42.7 100.0
USA United Kingdom India No response Germany Australia Belgium The Netherlands Sweden Austria Canada China Estonia Israel Italy Norway South Africa Sri Lanka Afghanistan Albania Argentina Bulgaria Czech Republic Denmark France Hungary Madagascar New Zealand Poland Saudi Arabia Taiwan Uruguay Yugoslavia Total
49 16 7 6 6 4 4 3 3 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 131
37.4 12.2 5.3 4.6 4.6 3.1 3.1 2.3 2.3 1.5 1.5 1.5 1.5 1.5 1.5 1.5 1.5 1.5 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 100.0
37.4 49.6 55.0 59.5 64.1 67.2 70.2 72.5 74.8 76.3 77.9 79.4 80.9 82.4 84.0 85.5 87.0 88.5 89.3 90.1 90.8 91.6 92.4 93.1 93.9 94.7 95.4 96.2 96.9 97.7 98.5 99.2 100.0
Not surprisingly, the tables closely mirror one another. Most of the respondents are Americans working in organizations located in the United States. It is evident however, that UML has become a global phenomenon with activity in every corner of the world. The sample of UML users in this study originally came from 35 different countries while working at organizations in 32 countries. It is interesting to note the foreign nationalities in this sample with the most sizable representation of UML users (e.g. United Kingdom, Australia, and India) and Table 5 Country of origin Country
Frequency
Percent
Cumulative percent
USA United Kingdom India Australia Germany Belgium No response Austria Canada China The Netherlands Norway Sweden Estonia France Italy Nigeria South Africa Argentina Belarus Bulgaria Colombia Czech Republic Denmark Georgia Hungary Israel Jamaica Jordan Lithuania Pakistan Poland Saudi Arabia Sudan Taiwan Yugoslavia Total
41 16 8 7 6 4 3 3 3 3 3 3 3 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 131
31.3 12.2 6.1 5.3 4.6 3.1 2.3 2.3 2.3 2.3 2.3 2.3 2.3 1.5 1.5 1.5 1.5 1.5 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 100
31.3 43.5 49.6 55.0 59.5 62.6 64.9 67.2 69.5 71.8 74.0 76.3 78.6 80.2 81.7 83.2 84.7 86.3 87.0 87.8 88.6 89.3 90.1 90.8 91.6 92.4 93.1 93.9 94.7 95.4 96.2 96.9 97.7 98.5 99.2 100.0
the countries in which it is being used the most (e.g. United Kingdom, India, and Germany). This is not completely unexpected however, as the survey was only available in English. The data revealed that 57.2% of the respondents to this study were originally from English speaking countries, while 59.5% were working for organizations located in English speaking countries. Another demographic variable analyzed was current job title. In the present study, respondents were broken down into three primary groups: developers, analysts, and managers. As seen in Table 7, the majority of respondents Table 7 Current job title Job title
Frequency
Percent
Cumulative percent
No response IT manager or supervisor Systems analyst Software developer Other Total
3 19 23 39 47 131
2.3 14.5 17.6 29.8 35.9 100.0
2.3 16.8 34.4 64.0 100.0
M. Grossman et al. / Information and Software Technology 47 (2005) 383–397 Table 8 Industry
387
TTF indices. In addition, other project and technology characteristics are examined.
Industry
Frequency
Percent
Cumulative percent
Wholesale/retail Aerospace Insurance Government No response Healthcare Industrial/manufacturing Telecommunications Education Banking/financial services Other Information technology Total
3 3 5 5 6 7 7 7 9 10 18 51 131
2.3 2.3 3.8 3.8 4.6 5.3 5.3 5.3 6.9 7.6 13.7 38.9 100.0
2.3 4.6 8.4 12.2 16.8 22.1 27.5 32.8 39.7 47.3 61.1 100.0
did not see themselves fitting into any of the categories offered, selecting the ‘other’ category instead. Closer inspection of the actual entries written in by these respondents revealed some other titles not captured in the original survey, such as consultant, student, researcher, engineer and architect. In general, it can be said that the sample population reflected a wide cross section of practitioners with direct hands-on experience using UML. The industry in which the respondent was working was also collected. Table 8 shows this breakdown, indicating that most respondents are working in the IT industry, but that the use of UML spans other industries as well. Responses within the other category exposed a number of other industry categories, not included in the survey, such as agriculture and transportation. 3.3. Additional findings Aside from the demographic data described above, this study addressed the research question of whether or not individuals who use UML perceive it to be beneficial. A positive perception underlies task-technology fit [20] and can be analyzed further by examining all of the individual items originally included in the survey as well as aggregate
3.3.1. Raw survey results First, we look at the survey items themselves, broken down by variable type. Response frequencies for all questions are displayed in Tables 9–16. Inspection of these response frequencies reveal some interesting patterns in light of the negative descriptions of UML found in the literature [11,18,22,24,36,42]. For example, complexity of UML is frequently cited as an impediment to its usage. It does not appear however that most respondents feel this to be so, based on the responses in the survey items related to the ‘understandability’ variable (Table 12). Similarly, the responses to those items in the ‘accuracy’ and ‘flexibility’ categories (Tables 9 and 11) reflect somewhat favorable perceptions on the part of most respondents. UML does not appear to be deemed overly inflexible or inaccurate to meet the needs of the majority of developers surveyed. Some survey items however did generate a greater percentage of negative responses from the sample. For example, items relating to both ‘compatcompatibility’ and ‘ambiguity’ generated a majority of negative responses for several questions (Tables 10 and 15). Nearly, 62% of those surveyed agreed with the statement that UML is insufficiently specified which allows for misinterpretation. 3.3.2. TTF response indices Prior to performing statistical analysis, all responses were normalized to account for the wording of the survey questions. For example, some questions were posed positively (e.g. UML provides sufficiently detailed diagrammatic constructs), while others were cast in a negative format (e.g. I find UML to be too complex and difficult to understand). The normalization process was simply a matter of inverting the responses of negatively cast statements (e.g. strongly disagree changed to strongly agree). After normalizing the data all numerical rankings were consistent, with 5 indicating the highest level of approval of UML and 1 indicating the lowest. Consistent with other TTF researchers [9,19,31,40], we were able to derive TTF indices for each
Table 9 Right data–response frequencies Survey item
The right data
1. UML is missing critical constructs that would be useful in performing analysis 9. The diagrams and notational elements of UML are at an appropriate level of detail for my purposes 17. It is more difficult to do my job effectively because some of the constructs I need are not available 25. UML semantics do not adequately capture some important analysis and design concepts
Strongly disagree
Somewhat disagree
Neither agree nor disagree
Somewhat agree
Strongly agree
12 (9.2%)
30 (22.9%)
16 (12.2%)
52 (39.7%)
21 (16.0%)
4 (3.1%)
17 (13.0%)
16 (12.2%)
61 (46.6%)
33 (25.2%)
28 (21.4%)
41 (31.3%)
26 (19.8%)
22 (16.8%)
14 (10.7%)
16 (12.2%)
32 (24.4%)
18 (13.7%)
45 (34.4%)
20 (15.3%)
388
M. Grossman et al. / Information and Software Technology 47 (2005) 383–397
Table 10 Accuracy–response frequencies Survey item
Strongly disagree
Accuracy
2. UML’s notational elements are accurate enough for my purposes 10. There are accuracy problems in the UML constructs that I use or need 18. UML leads me down the right path in developing systems 26. UML models often lead to inaccurate representations of the underlying system being developed
Somewhat disagree
Neither agree nor disagree
Somewhat agree
Strongly agree
4 (3.1%)
21 (16.0%)
9 (6.9%)
62 (47.3%)
35 (26.7%)
14 (10.7%)
47 (35.9%)
35 (26.7%)
28 (21.4%)
7 (5.3%)
3 (2.3%)
18 (13.7%)
42 (32.1%)
32 (24.4%)
36 (27.5%)
18 (13.7%)
53 (40.5%)
24 (18.3%)
32 (24.4%)
4 (3.1%)
Table 11 Compatibility–response frequencies Survey item
Compatibility
3. When it is necessary to compare or aggregate data from two or more different UML diagrams, there may be unexpected or difficult inconsistencies 11. There are times when supposedly equivalent information from two different UML diagrams is inconsistent 19. Sometimes it is difficult or impossible to compare or aggregate data from two different UML diagram sources because the data is defined differently 27. UML notations consistently mean the same thing regardless of where they are used
Strongly disagree
Somewhat disagree
Neither agree nor disagree
Somewhat agree
Strongly agree
3 (2.3%)
18 (13.7%)
39 (29.8%)
57 (43.5%)
14 (10.7%)
9 (6.9%)
31 (23.7%)
41 (31.3%)
39 (29.8%)
11 (8.4%)
4 (3.1%)
26 (19.8%)
43 (32.8%)
53 (40.5%)
5 (3.8%)
8 (6.1%)
34 (26.0%)
40 (30.5%)
37 (28.2%)
12 (9.2%)
Strongly agree
Table 12 Flexibility–response frequencies Survey item
Flexibility
4. UML is too inflexible to be able to respond to the changes in system requirements models 12. When business requirements change it is easy to change the selection and format of UML diagrams 20. It is difficult to change UML models. 28. UML provides enough flexibility to model any system
Strongly disagree
Somewhat disagree
Neither agree nor disagree
Somewhat agree
28 (21.4%)
65 (49.6%)
16 (12.2%)
17 (13.0%)
5 (3.8%)
7 (5.3%)
32 (24.4%)
25 (19.1%)
58 (44.3%)
9 (6.9%)
35 (26.7%) 6 (4.6%)
48 (36.6%) 24 (18.3%)
21 (16.0%) 21 (16.0%)
22 (16.8%) 54 (41.2%)
5 (3.8%) 26 (19.8%)
Somewhat agree
Strongly agree
Table 13 Understandability–response frequencies Survey item
Understandability
Strongly disagree 5. The UML diagrams that I need are displayed in a readable and understandable form 13. The UML diagrams are presented in a readable and useful format 21. I find UML to be too complex and difficult to understand 29. UML adequately conveys the meaning and intent of the underlying system
Somewhat disagree
Neither agree nor disagree
3 (2.3%)
12 (9.2%)
7 (5.3%)
56 (42.7%)
53 (40.5%)
2 (1.5%)
6 (4.6%)
11 (8.4%)
67 (51.1%)
45 (34.4%)
54 (41.2%)
40 (30.5%)
17 (13.0%)
13 (9.9%)
7 (5.3%)
5 (3.8%)
24 (18.3%)
29 (22.1%)
56 (42.7%)
17 (13.0%)
M. Grossman et al. / Information and Software Technology 47 (2005) 383–397
389
Table 14 Level of detail–response frequencies Survey item
Level of detail
Strongly disagree 6. On the models that I deal with, the exact meaning of UML’s notational elements is either obvious, or easy to find out 14. The exact definition of UML notational elements related to my tasks is easy to find out 22. UML provides sufficiently detailed diagrammatic constructs 30. UML contains too many notations and diagrams to be used effectively
Somewhat disagree
Neither agree nor disagree
Somewhat agree
Strongly agree
6 (4.6%)
26 (19.8%)
19 (14.5%)
50 (38.2%)
30 (22.9%)
2 (1.5%)
22 (16.8%)
22 (16.8%)
58 (44.3%)
27 (20.6%)
3 (2.3%)
16 (12.2%)
21 (16.0%)
67 (51.1%)
24 (18.3%)
33 (25.2%)
45 (34.4%)
26 (19.8%)
19 (14.5%)
8 (6.1%)
Strongly disagree
Somewhat disagree
Neither agree nor disagree
Somewhat agree
Strongly agree
18 (13.7%)
30 (22.9%)
25 (19.1%)
36 (27.5%)
22 (16.8%)
19 (14.5%)
21 (16.0%)
37 (28.2%)
32 (24.4%)
22 (16.8%)
27 (20.6%)
36 (27.5%)
20 (15.3%)
35 (26.7%)
13 (9.9%)
12 (9.2%)
25 (19.1%)
28 (21.4%)
38 (29.0%)
28 (21.4%)
Table 15 Training–response frequencies Survey item
Training
7. There is not enough training on how to understand, access or use UML 15. I am getting the training I need to be able to use UML effectively in my job 23. There is no one to go to for help when I encounter a problem using UML 31. I received enough UML training to effectively use it
dimension by averaging the scaled data. A cursory inspection of the obtained TTF indices (Table 17 and Fig. 1) indicates a response pattern that is slightly above neutral, which represents a generally positive perception of UML. Indices fell between 2.1 and 4.35, with an overall TTF index of 3.35.
Breaking down the computed indices by TTF dimension (Table 18), reveals that perception of UML is by no means uniform across the variables used in this study. The understandability dimension, for example, was found to have the highest index (3.89), while ambiguity revealed a neutral index (3.0). As seen previously (Table 3), over 77%
Table 16 Ambiguity–response frequencies Survey item
Ambiguity
8. There are so many different UML diagrams and notational systems, each with slightly different symbols, that it is hard to understand which one to use in a given situation 16. UML diagrams are represented in so many different places and in so many forms; it is hard to know how to use them effectively 24. Some UML models are insufficiently specified, allowing developers to interpret them in more than one way 32. It is not always clear how to use UML’s notations across the different diagram types
Strongly disagree
Somewhat disagree
Neither agree nor disagree
Somewhat agree
23 (17.6%)
49 (37.4%)
17 (13.0%)
34 (26.0%)
8 (6.1%)
18 (13.7%)
48 (36.6%)
22 (16.8%)
37 (28.2%)
6 (4.6%)
6 (4.6%)
21 (16.0%)
23 (17.6%)
53 (40.5%)
28 (21.4%)
11 (8.4%)
39 (29.8%)
25 (19.1%)
48 (36.6%)
8 (6.1%)
Table 17 Distribution of TTF indices
TTF
N
Min.
Max.
Mean
Std. dev.
131
2.10
4.35
3.3481
0.4668
Strongly agree
390
M. Grossman et al. / Information and Software Technology 47 (2005) 383–397
Fig. 1. Histogram of TTF indices.
of the respondents in this survey had 4 or more years of experience in object-oriented technology. That, in conjunction with the high degree of college education of the respondents (Table 4), may partially explain the relatively high index exhibited along this dimension. A major part of understanding UML is predicated on having a solid comprehension of the object-oriented model. Since most of our respondents were already highly experienced with this technology, one might assume that there would be little problem understanding the fundamental concepts underlying UML, which is based on that paradigm. Although UML has a reputation for being overly complex [36,42], we should also consider that most practitioners may only be using a subset of the language [13], exhibiting the phenomenon known in software engineering as the ‘80/20 rule’ (i.e. 80% of the systems are developed using 20% of the language constructs). The relatively high understandability index may actually reflect usage of a smaller subset of UML, which is less complex and easier to work with.
Several authors [2,35,36] have pointed to ambiguity as one of the most problematic aspects of UML. Ambiguity of UML constructs may indeed be related to the very way in which the standard was created, i.e. as a synthesis of already existing OOAD techniques. As if attempting to satisfy the widest range of participants involved in the standardization process, UML has incorporated a number of overlapping constructs, which potentially introduce ambiguity in their usage. The relatively low index calculated for the ambiguity index in this study, may reflect this somewhat disjointed aspect of UML. Averages of scaled data for each of the TTF dimensions are displayed in Table 18. It is interesting to revisit the location data described previously, broken down according to TTF indices. Table 19 reveals that US developers have a slightly lower overall TTF index than those in most of the other regions represented in the survey. Particularly noteworthy are the differences between the US/Canada, Europe and Asia/Middle East regions, each with sizable portions of the sample. Ironically, the level of satisfaction of US developers seems to be lower than those in Europe and Asia. Perhaps, this trend reflects the fact that non-US developers have been using OOAD methods longer than those in the US [27]. Further investigation of the intercultural aspects of UML usage and adoption is warranted [21]. 3.3.3. Other characteristics of UML In addition to the primary questions, there were 19 questions that related to other project and technology characteristics. These questions were designed to learn more about how UML is actually being used in the field and to determine which factors might influence usage. One important variable, which was included in the primary study, is training. Table 20 reveals that all training categories presented are being utilized to some degree. Although 41% of the population received some type of formal training, an even greater percentage was self-taught, either through online tutorials or through other means
Table 18 TTF indices by dimension Right data
Flexibility
Understandability
Training
Ambiguity
General TTF index
3.17
3.53
3.89
3.15
3
3.35
Table 19 TTF indices by geographic location of company Geographic region
Frequency
Percent
Cumulative percent
TTF index
USA and Canada Europe Asia/Middle East Australia/New Zealand Africa South America Total
52 52 17 5 3 2 131
40 40 13 3.8 2.3 1.5 100.0
40 80 93 97 99 100
3.24 3.39 3.52 3.15 3.77 3.40
M. Grossman et al. / Information and Software Technology 47 (2005) 383–397 Table 20 Type of UML training
Formal course Mentor Online tutorial Other
Table 22 Project development costs Frequency
Percent
51 37 71 55
41.2 28.2 54.2 42.0
(e.g. self-study, books, etc.). A smaller percentage had the added advantage of having access to a mentor. The survey asked respondents to indicate their primary purpose for using UML. Table 21 indicates the response breakdown. The other category included such entries as: business domain modeling, capture design level decisions, identify risks, and satisfy a certification or degree requirement. It appears that most of the respondents of the survey are using what Fowler [16] calls ‘UML by sketch’, which is the most informal and dynamic approach to modeling and which utilizes UML constructs primarily to aid in communication. Using UML in this fashion does not require strict enforcement of every rule of the specification, as opposed to ‘UML by blueprint’ and ‘UML as programming language’, two other approaches that are much more rigorous and more concerned with completeness. Project development costs were elicited and are presented in Table 22. The results indicate that UML is used on projects of all sizes. About 15% were $150,000–$499,000, and overall, some 52% were $150,000 or more. It is interesting to note that such a sizeable percentage (13.7%) of the projects had a cost less than $30,000. Given the relatively high experience level of the respondents (Table 4), it is curious that so many are engaged in such ‘low-end’ projects. The project expected/realized benefit in dollars was also collected. A high percentage of respondents (39.7%) either failed to respond to this item or selected ‘other’, indicating that they were not privy to financial data. It is interesting to note that 30% of the respondents did not seem to have knowledge of the benefit of the project they were working on. Table 23 shows the breakdown for the respondents. The results seem to reflect the same pattern as the project costs (Table 22) above, i.e. a bimodal distribution, with 21.4% at the high end (over 1 million) and 16.0% at the low end (less than $30,000). Management buy-in is believed to be an important prerequisite for successful technology adoption [6,23,41]. Table 21 Main objective for using UML
Capture and communicate requirements Guide development of code Reverse engineering Other
391
Frequency
Percent
Cumulative percent
74
56.5
56.5
39 13 5
29.8 9.9 3.8
86.3 96.2 100.0
Project cost
Frequency
Percent
Cumulative percent
No response Less than $30,000 $30,000–$39,999 $40,000–$49,999 $50,000–$59,999 $60,000–$74,999 $75,000–$99,999 $100,000–$149,999 $150,000–$249,999 $250,000–$499,999 $500,000–$999,999 $1,000,000 or more Other Total
4 18 1 1 5 4 4 6 10 10 7 41 20 131
3.1 13.7 0.8 0.8 3.8 3.1 3.1 4.6 7.6 7.6 5.3 31.3 15.3 100
3.1 16.8 17.6 18.4 22.2 25.3 28.4 33 40.6 48.2 53.5 84.8 100.0
Table 24 displays the results of the survey question asking for the level of management involvement in UML usage. Results show a mixed level of management involvement across the sample population. UML is relatively new and has still not been adopted universally. This is reflected in Table 25. Only 27.5% of the sample, for example, has adopted UML as the primary development approach, using it consistently on all projects while over 44% use it only sporadically. These last two survey items (‘management involvement’ and ‘use of UML in organization’) warrant further discussion, since they represent aspects of UML utilization. The concept of utilization plays a key role in IT research. Utilization has been conceptualized as the extent to which the information system has been incorporated into the individual’s work routines [19]. Such integration may be either by individual choice or by organizational mandate. Although a number of other ways have been used to conceptualize ‘utilization’, such as frequency of use and diversity of applications employed [8,39] the concept is still not well understood and is in need of refinement [19]. Table 23 Project expected/realized benefit Project benefit
Frequency
Percent
Cumulative percent
No response Less than $30,000 $30,000–$39,999 $40,000–$49,999 $50,000–$59,999 $60,000–$74,999 $75,000–$99,999 $100,000–$149,999 $150,000–$249,999 $250,000–$499,999 $500,000–$999,999 $1,000,000 or more Other Total
14 21 1 1 5 2 1 9 2 6 3 28 38 131
10.7 16.0 0.8 0.8 3.8 1.5 0.8 6.9 1.5 4.6 2.3 21.4 29.0 100.0
10.7 71.0 45.8 46.6 50.4 54.2 55.0 38.9 40.5 45.0 52.7 32.1 100.0
392
M. Grossman et al. / Information and Software Technology 47 (2005) 383–397
Table 24 Management involvement Management involvement
Frequency
No response Does not seem to care about methods used as long as project is completed on time Fully endorses and encourages the use of UML and allocates necessary resources Moderate endorsement but limited spending Other Total
Percent
and 0.088 for ‘management involvement’, suggesting that there is some relationship. We plan to investigate this more thoroughly in future studies. UML is just a notational language and does not include a methodology. Although the Unified Process [29] is the recommended approach, UML is meant to be independent of any specific software development methodology. It is therefore important to consider this, as it may impact successful usage of UML. Table 27 reveals that there is a wide variety of methods employed along with UML, including 21% who indicated they are using an older structured methodology. The majority of the respondents selected ‘other’, which on further inspection included a wide array of methodologies including: DSDM, ICONIX, modified Objectory approach, Catalysis, Contextual Design, Feature Driven Design, DOD specific methodologies, and in-house methods. The version of UML under investigation (1.X) has nine diagrams (the recently adopted UML 2.0 has 13 diagrams). Therefore, when we query users of UML, we need to take into account which of the diagrams they are using. There is quite a bit of variation with regard to how developers use UML. Again, we can look to Fowler’s designation of the three types of UML usage (i.e. as sketch, blueprint or programming language) as a way to explain users’ selection of specific diagram types [16]. Depending on the specific needs of the developer, one might casually create use case and class diagrams, while another might pay stricter attention to the full Object Management Group specification and use all diagrams to model systems. Fig. 2 displays the ranking of diagrams in order of use. The three most important diagrams in terms of order of use are Use Case, Class and Sequence. Adoption of object-oriented analysis and design techniques takes time and the completion of several projects is generally necessary before gains are realized [23]. The present survey asked respondents to indicate how many UML-based projects they completed (Table 28). Over 50% of the respondents have completed less than five projects in UML, reflecting the relative immaturity of the modeling language. But, about 40% have done five or more projects; while 10% have done 10 or more. The one data point indicating completion of 500 UML projects was considered an outlier. Given the relative immaturity of UML, it is highly unlikely that this represents useful information.
Cumulative percent
2 39
1.5 29.8
1.5 31.3
40
30.5
61.8
36
27.5
89.3
14 131
10.7 100.0
100
Percent
Cumulative percent
Table 25 Use of UML in organization UML usage
Frequency
No response Other Used consistently on all development projects Used for large projects only Used sporadically with no mandate from management Total
1 14 36
0.8 10.7 27.5
0.8 10.7 27.5
22 58
16.8 44.3
16.8 44.3
131
100.0
100.0
With this in mind, a closer inspection of the computed TTF indices was undertaken to determine if there was a relationship with utilization, derived from the survey questions on ‘use of UML within the organization’ and ‘management involvement’, a related concept also believed to have an impact on successful adoption and use of objectoriented technology [23,41]. Table 26 displays the indices broken down according to responses in both of the utilization related questions from the survey. The results of this analysis suggest that there is a relationship between TTF and utilization. As the degrees of both management involvement and extent of usage increases, so do the TTF indices. After operationalizing the survey responses (i.e. converting them from textual to scalar data), we ran regressions to see if this relationship could be further established. Table 25 shows the adjusted R-squares of 0.074 for ‘use of UML within the organization’ Table 26 TTF indices by utilization factors
Management involvement (adjusted R2Z0.088) Extent of usage (adjusted R2Z0.074)
Full endorsement Moderate endorsement Indifferent Used consistently Large projects only Sporadically
Right data
Flexibility
Understandability
Training
Ambiguity
TTF index
3.76 3.17 2.92 3.36 3.18 2.99
4.08 3.47 3.38 3.83 3.51 3.4
3.88 3.94 3.67 4.04 4.18 3.72
2.74 3.06 2.96 3.49 3.44 2.93
3.47 2.95 3.28 2.99 2.73 3.13
3.57 3.32 3.24 3.54 3.41 3.23
M. Grossman et al. / Information and Software Technology 47 (2005) 383–397 Table 27 Methodology used in conjunction with UML Methodology
Frequency
Percent
Cumulative percent
No response Agile methodology None Structured approach Unified process Other Total
2 20 21 21 39 28 131
1.5 15.3 16.0 16.0 29.8 21.4 100.0
1.5 16.8 32.8 48.8 78.6 100.0
There are many products on the market aimed at helping software developers create UML diagrams. One of the most popular products comes from Rational Corporation, the employer of the ‘Three Amigos’ and the company whose name is most closely associated with UML. It was not surprising that a large number of the sample uses Rose, the primary UML CASE tool offering of Rational. It was also interesting to see what other tools are being used by the sample population. Fig. 3 displays the distribution of UML tool usage. It is obvious that the selections offered on the survey missed the mark, since the majority of respondents selected the other category. Within the other category, there was one product that emerged as the clear leader. Over 80% of those selecting the other category were using Enterprise Architect, a product of the Australian company Sparx Systems (www.sparxsystems.com). Other tools represented in the sample were Together, Visio, and manual methods such as ‘pencil and paper’, whiteboards, or flipcharts. Over 28% of the respondents added comments to the survey. Though not statistically analyzed, these comments are important in that they provide additional insight into how UML is being used. The following responses, for example, support the idea that UML is really not a methodology, but simply a way to communicate using visual notations. Many of the questions imply that UML is more of a method than a way of communicating—and to many, I think it is. But to me, it is a way of communicating, and
393
my only use for it is to allow the team to guess enough about the solution to begin writing tests and code. I use UML to communicate an idea that is too complex to describe by hand-waving. The moment we understand each other enough to start writing code, we stop writing UML. And the moment the code teaches us more than the UML diagram did, we abandon (rather than update) the diagram. We are also very sloppy with notation as long as the diagram communicates what we need to say. UML is not a complete and comprehensive solution to all of the challenges associated with defining requirements and designing software systems. It is however, a useful and valuable technique. It is by no means the only technique that an analyst or designer needs any more than a hammer is the only tool that a carpenter needs. These comments are consistent with the writings of agile methodology proponents [3,5,29], who warn against placing too much emphasis on UML itself, which is ultimately just a notational tool, and not enough on the fundamental processes underlying systems analysis and design. Other comments reflect the belief that UML is still too incomplete to adequately build complex systems as several authors have claimed [3,22]. Examples include: UML is very powerful. Still it lacks the primary constructs for Systems Engineering and good architecture work. Many will be added in the SE working group and the architecture working group. Still there is a GREAT deal to do. We are inventing the language of engineering for the future. It may take a couple more years. UML is quite useful but adequate training is quite lacking. The notation itself is just the medium. Also, over engineered systems are (wrongly) linked to UML and this leads to a bad perception of it. UML can be simple and efficient, thought provoking and on the contrary help in *simplifying* overly complex designs or concepts. In that UML can add significant shareholder
Fig. 2. UML diagrams in order of use.
394
M. Grossman et al. / Information and Software Technology 47 (2005) 383–397
Table 28 Number of UML projects completed by respondent UML projects completed
Frequency
Percent
Valid percent
No response 0 1 2 3 4 5 6 7 8 9 10 12 15 17 18 27 30 50 500 Total
11 8 12 20 17 10 14 6 2 2 1 15 2 3 1 1 1 3 1 1 131
8.40 6.11 9.16 15.27 12.98 7.63 10.69 4.58 1.53 1.53 0.76 11.45 1.53 2.29 0.76 0.76 0.76 2.29 0.76 0.76 100
8.40 14.51 23.67 38.93 51.91 59.55 70.23 74.81 76.34 77.87 78.63 90.08 91.61 93.90 94.66 95.42 96.19 98.48 99.24 100.00 100
find practical methods of application. Without a lot or encouragement and support, most developers will quickly abandon the new technique and return to more familiar ways of doing things. A future study will analyze these comments in more detail and solicit further input from the respondents to this survey.
4. Implications
value. In being wrongly used, it can for sure be subtracting value. And yet other comments shed light on the difficulties in adopting new technologies such as UML. For example: Relative to the total number of software developers, the number of those who actually use UML is quite small. The adoption pattern seems to be very much like that we saw for “structured” methods. Many developers attend an introductory class on UML and make at least some attempt at applying it to “real world” problems. Inevitably, trying to apply the technique to realistic problems (as opposed to the small, contrived examples from the classroom) reveals shortcomings in both the technique and in the student’s knowledge. A few practitioners will be convinced enough of the potential benefits of the technique to work through these issues to
There are a number of managerial implications that arise as we study UML in the context of task-technology fit. As UML’s popularity has increased, an entire industry providing related products and tools has also begun to emerge. Companies are starting to invest in UML, hoping that it will facilitate more productive software development. But UML is not a trivial technology. Simply throwing it at developers does not mean that it will result in the performance gains desired. We need first to ask a number of important questions to determine how well the usage of UML will fit within the organizational context. How will UML be used, i.e. casually or at a more rigorous level of detail? Do the users have adequate object-oriented experience to understand the complexities of UML and to be able to use it successfully? Does management support the use of UML and/or is there a champion in the company who can guide the effort? Is there adequate training available? These are just a few questions that need to be considered. In short, we need to take into account the multitude of complex factors that make up the organizational environment, striving to achieve alignment between them. The implication for management is clear. The greater the fit between the individual, task and technology, the better the chances that UML will be perceived positively thus leading to greater performance impacts. The model utilized in this study shows modest support for what is so intuitively obvious regarding task-technology fit. However, as can be seen by the somewhat lackluster perception of UML, there is still much about the technology that is open-ended and poorly
Fig. 3. UML tool usage.
M. Grossman et al. / Information and Software Technology 47 (2005) 383–397
defined to allow its users to perceive its benefit. As UML matures, it is tempting to conjecture that this situation will change and that a task-technology fit will be more definitively evident. 4.1. Future research There is a critical need for further research in all areas relating to UML usage. Very few empirical studies have been performed to date. The present study served as a starting point from which to launch subsequent studies. A follow-up study will be performed that breaks down the population along different demographic factors. Goodhue and Thompson performed a similar analysis in their exploration of managerial level as a possible determinant of user evaluations of information systems [19]. The demographic variables included in the present study (e.g. industry, country of origin, education level, etc.) should be analyzed in a similar fashion, to determine how they influence task-technology fit of UML usage. Specifically, intercultural studies along the lines of [15] would be interesting to see how cultural factors impact UML usage. In addition, much of the project, organizational and technology specific data collected via this survey should be further analyzed to see if other patterns emerge. Another future study could be based on longitudinal data. With the solidification of the new UML 2.0 standard and the increasing use of UML across the world, it would be informative to reevaluate the responses to this same survey several years from now. Through this research, task-technology fit was shown to be a promising framework to explore UML; however, much work needs to be done in order to improve the model used for study of this technology. We will continue to investigate other variables and plan to fine tune the model for future studies. A more robust conceptualization of UML ‘utilizutilization’ will also be an important aspect of this effort.
5. Summary and conclusion 5.1. Summary The Unified Modeling Language (UML) has become the de facto standard for object-oriented systems development and will soon be an international standard. Promoted as a unified approach which incorporates the ‘best practices’ of previous notational methods, UML promises to relieve some of the problems associated with object-oriented software development. However, there is a severe lack of empirical evidence supporting the claim that UML leads to greater performance and a number of problems continue to be reported concerning its usage (e.g. complexity, inconsistency, difficulty to learn, incompleteness). This study used task-technology fit theory as a theoretical backdrop to examine UML. Task-technology fit theory
395
suggests that for an information technology to impact performance, it must first meet the needs of the user, i.e. there must be a fit between the task requirements of the user and the functionality of the system. This study extended prior task-technology fit research by investigating how individual and task characteristics impact UML usage. In addition, it provided much needed data relating to current usage of UML in the global software development community. UML users were identified from a number of online sources, such as newsgroups, conference proceedings, user groups, and directories involving individuals who have experience with UML. E-mail messages were sent to 1507 UML users, inviting them to participate in the study by linking to the Web hosted survey. A final sample size of 131 was obtained. Analysis involved inspection of the raw responses to individual survey items as well as examination of aggregated TTF indices. While there was a wide spectrum of opinion regarding UML usage, this analysis revealed some interesting patterns. For example, it appears that the UML community surveyed had a more positive perception of UML than some of the literature has suggested [11,18,22, 24,36,42]. The majority of respondents viewed UML as accurate, consistent, and flexible enough to use on development projects. Further analysis is needed to determine which factors might have influenced such perceptions. Aggregating the TTF indices across dimensions provided some additional empirical data related to TTF. It was demonstrated that the ambiguity variable had the lowest index and understandability the highest index. An exploratory attempt at establishing a relationship between the derived TTF indices and an ad hoc conceptualization of ‘utilization’ also showed some promise. Although the R-squares were low, a definite effect was observed, supporting the idea that TTF is positively related to both the extent of UML use and to management’s involvement in the use of UML on development projects. Finally, analysis of other survey questions demographic makeup of the sample population, as well as provided information regarding UML usage. 5.2. Conclusion The characteristics identified in this study were right data, accuracy, compatibility, flexibility, understandability, level of detail, training, and ambiguity. Three variables were dropped from the model as a result of low reliability. These were accuracy, compatibility and level of detail. One of Goodhue’s original constructs [20], accuracy was meant to measure the correctness of the data. In the present study, accuracy was altered slightly to reflect the ‘correctness’ of UML’s constructs. To some extent, it attempts to determine whether UML diagrams result in accurate depictions of the system, or whether they actually
396
M. Grossman et al. / Information and Software Technology 47 (2005) 383–397
mislead the developer, as Simons and Graham’s ‘cognicognitive misdirection’ concept suggests [36]. The questions in this category, although intuitively consistent, fail to hold together as evidenced by the low Chronbach’s alpha. One reason could be the experience level of the sample population, which was very high (approximately 77% of the respondents had 4 or more years experience with object-oriented technology). The concept of accuracy may not be relevant to this group of users, who already has a firm enough grasp of the object-oriented paradigm. The ‘level of detail’ construct was also included in Goodhue’s questionnaire [20], and originally measured whether data in general was maintained at the right level of detail. In this survey it was meant to convey whether UML is easy to figure out or whether it is too detailed. Lack of cohesion within this variable might be related to the variety of ways in which UML is being used among those sampled. UML is used by some simply as a communications tool and by others as a formal mechanism for requirements definition and design [16]. To further complicate the matter, UML has fragmented into various dialects with separate domains for enterprise systems, Web-based systems, and real-time systems [13], which are evolving differently and which involve different levels of detail. We may also need to consider the process used along with UML (e.g. Unified Process, agile methodologies) as well, since some of these methodologies are inherently more detailed than others. Like previous studies of other information technologies, this study suggests that task-technology fit theory has some explanatory power, but due to the elusive nature of UML, there are still many questions that need to be answered. While the aggregated index of 3.35 indicates a slightly positive perception of UML, it by no means represents an overwhelming endorsement. At this early stage in its evolution, it may be that the people using UML still do not have enough of a feeling for how this technology fits with the tasks they are trying to perform. The fact that respondents to this survey failed to express strong opinions may reflect the fact that UML is an immature standard that is still undergoing codification. The UML phenomenon presents an enigma. While it is increasingly being adopted throughout the world, there is really no consensus on how it should be used or on whether it is providing beneficial effects. Much of the literature points to a technology that is complex, poorly understood, and used inconsistently. Perhaps, the results of this survey reflect a certain degree of confusion among the user community surrounding UML. Developers clearly seem eager to use this highly hyped technology which is spreading across the world. Yet, they are lacking an adequate enough understanding of the technology to determine if it is making any real difference in the way they are performing their development tasks.
References [1] R. Agarwal, A.P. Sinha, M. Tanniru, The role of prior experience and task characteristics in object-oriented modeling: an empirical study, International Journal of Human–Computer Studies 45 (1996) 639– 667. [2] D.H. Akehurst, A.G. Waters, UML deficiencies from the perspective of automatic performance model generation, OOPSLA’99 Workshop on Rigorous Modeling and Analysis with the UML: Challenges and Limitations, 1999. [3] S.W. Ambler, The Object Primer: The Application Developer’s Guide to Object Orientation and the UML, second ed., Cambridge University Press, Cambridge, 2001. [4] G. Booch, Object-oriented Analysis and Design with Applications, second ed., Benjamin/Cummings, Redwood City, 1994. [5] A. Cockburn, Agile Software Development, Addison-Wesley, Boston, 2000. [6] J.G. Cooprider, J.C. Henderson, Technology-process fit: perspectives on achieving prototyping effectiveness, Journal of Management Information Systems 7 (3) (1991) 67–87. [7] J. D’Ambra, Preliminary investigations of user evaluation of the WWW, Proceedings of the Fifth Americas Conference on Information Systems, Milwaukee, WI, 1999. [8] F. Davis, R. Bagozzi, P. Warshaw, User acceptance of computer technology: a comparison of two theoretical models, Management Science 35 (8) (1989) 982–1003. [9] M.T. Dishaw, D.M. Strong, Supporting software maintenance with software engineering tools: a computed task-technology fit analysis, The Journal of Systems and Software 44 (1998) 107–120. [10] M.T. Dishaw, D.M. Strong, D.B. Brandy, Assessing task-technology fit in simulation modeling, Proceedings of the Seventh Americas Conference on Information Systems, Boston, MA, 2001. [11] D. Dori, Object-process methodology applied to modeling credit card transactions, Journal of Database Management 12 (1) (2001) 4–14. [12] T. Downes-Le Guin, P. Janowitz, R. Stone, S. Khorram, Use of preincentives in an internet survey, The IMRO Journal of Online Research, 2002, http://www.ijor.org/ijor_archives/articles/use_of_ pre-incentives_in_an_internet_survey.pdf [13] J. Erickson, K. Siau, Unified Modeling Language: theoretical and practical complexity, Proceedings of the Ninth Americas Conference on Information Systems, Tampa, FL, 2003, pp. 1323–1327. [14] J. Fedorowicz, A.O. Villeneuve, Surveying object technology usage and benefits: a test of conventional wisdom, Information & Management 35 (1999) 331–344. [15] T.W. Ferratt, G.E. Vlahos, An investigation of task-technology fit for managers in Greece and the U.S., European Journal of Information Systems 7 (1998) 123–136. [16] M. Fowler, K. Scott, UML Distilled Third Edition: A Brief Guide to the Standard Object Modeling Language, Addison-Wesley, Boston, 2004. [17] L. Garceau, E. Jancura, J. Kneiss, Object-oriented analysis and design: a new approach to systems development, Journal of Systems Management 44 (1) (1993) 25–33. [18] M. Glinz, Problems and deficiencies of UML as a requirements specification language, Proceedings of the 10th International Workshop on Software Specification and Design (IWWSSD-10), San Diego, CA, 2000, pp. 11–22. [19] D.L. Goodhue, Development and measurement validity of a tasktechnology fit instrument for user evaluations of information systems, Decision Sciences 29 (1) (1998) 105–138. [20] D.L. Goodhue, R.L. Thompson, Task-technology fit and individual performance, MIS Quarterly 19 (2) (1995) 213–236. [21] M. Grossman, R.V. McCarthy, J.E. Aronson, Factors influencing Unified Modeling Language (UML) usage in the global software development community, Fourth Annual Global Information
M. Grossman et al. / Information and Software Technology 47 (2005) 383–397
[22]
[23]
[24]
[25]
[26] [27]
[28] [29]
[30]
[31]
[32]
[33]
Technology Management (GITM) World Conference, Calgary, Canada, 2003, pp. 294–297. T. Halpern, Augmenting UML with fact orientation, Proceedings of the 34th Hawaii International Conference on System Sciences, Maui, HI, 2001, pp. 1–10. B.C. Hardgrave, Adopting object-oriented development: one company’s experience, Proceedings of the Sixth Americas Conference on Information Systems, Milwaukee, WI, 1999, pp. 568–570. M. Hitz, G. Kappel, Developing with UML: some pitfalls and workarounds, The Unified Modeling Language, {UML}’98—Beyond the Notation, First International Workshop, Mulhouse, France, 1998. I. Jacobson, P. Jonsson, G. Overgaard, Object-Oriented Software Engineering, A Use Case Driven Approach, ACM Press/AddisonWesley, Reading, 1992. R.A. Johnson, The ups and downs of object oriented systems, Communications of the ACM 43 (10) (2000) 68. R.A. Johnson, B.C. Hardgrave, Object-oriented methods: current practices and attitudes, The Journal of Systems and Software 48 (1999) 5–12. C. Kobryn, Will UML 2.0 be agile or awkward? Communications of the ACM 45 (1) (2002) 107–110. C. Larman, Applying UML and Patterns: An Introduction to ObjectOriented Analysis and Design and the Unified Process, second ed., Prentice Hall, Upper Saddle River, 2002. R.V. McCarthy, J.E. Aronson, G. Claffey, Task-technology fit in data warehousing environments: analyzing the factors that affect utilization, Proceedings of the Eighth Americas Conference on Information Systems, Dallas, TX, 2002, pp. 40–46. R.V. McCarthy, J.E. Aronson, K. Mazouz, Measuring the validity of task technology fit for knowledge management systems, Proceedings of the Seventh Americas Conference on Information Systems, Boston, MA, 2001. U.S. Murthy, D.S. Kerr, Task/technology fit and the effectiveness of Group Support Systems: evidence in the context of tasks requiring domain specific knowledge, Proceedings of the 33rd Hawaii International Conference on System Sciences, Maui, HI, 2000. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorenson, Object-Oriented Modeling and Design, Prentice-Hall, Englewood Cliffs, 1991.
397
[34] A.I. Shirani, M.H.A. Tafti, J.F. Affisco, Task and technology fit: a comparison of two technologies for synchronous and asynchronous group communication, Information & Management 36 (1999) 139– 150. [35] K. Siau, Q. Cao, Unified Modeling Language (UML): a complexity analysis, Journal of Database Management 12 (1) (2001) 26. [36] A.J.H. Simons, I. Graham, 30 things that go wrong in object modeling with UML 1.3, in: H. Kilov, B. Rumpe, I. Simmonds (Eds.), Precise Behavioral Specification of Businesses and Systems, Kluwer Academic Publishers, Boston, 1999. [37] R. Smyth, Challenges to successful ERP use (Research in Progress), The 9th European Conference on Information Systems, Bled, Slovenia, 2001. [38] A. Srivihok, R. Ho, F. Burstein, An instrument for web measurement: end user evaluation of Web application effectiveness, Proceedings of the Australian Conference on Information Systems, Brisbane, Australia, 2000. [39] R.L. Thompson, C.A. Higgins, J.M. Howell, Towards a conceptual model of utilization, MIS Quarterly 15 (1) (1991) 125–143. [40] B. Tjahjono, D. Fakun, R. Greenough, J. Kay, Evaluation of a manufacturing task support system using the task technology fit model, Proceedings of the Twelfth Annual Conference of the Production and Operations Management Society, Orlando, FL, 2001. [41] I.B. Ushakov, Experience based approach to OO technology adoption: key success factors, OOPSLA’98 Mid-year Workshop on Applied Object Technology, Denver, CO, 1998. [42] S. Wang, Experiences with the Unified Modeling Language (UML), Proceedings of the Seventh Americas Conference on Information Systems, Boston, MA, 2001, pp. 1289–1293. [43] J.D. Wells, S. Sarker, A. Urbaczewski, S. Sarker, Studying customer evaluations of electronic commerce applications: a review and adaptation of the task-technology fit perspective, Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03), Maui, HI, 2003. [44] E. Yourdon, Rise & Resurrection of the American Programmer, Yourdon Press, Upper Saddle River, 1996. [45] I. Zigurs, B.K. Buckland, J.R. Connolly, E.V. Wilson, A test of tasktechnology fit theory for group support systems, The DATA BASE for Advances in Information Systems 30 (3) (1999) 34–50.
