Information and Software Technology 47 (2005) 383397 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 Unied 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 difcult 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, reecting 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: Unied Modeling Language; UML; Object-oriented analysis and design; OOAD; Task-technology t

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 Unied 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: mgrossman@bridgew.edu (M. Grossman), jaronson @uga.edu (J.E. Aronson), richard.mccarthy@quinnipiac.edu (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 specication, 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) 383397

too difcult to use and that it is not fullling 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 t (TTF) theory [19,20] which links performance with the t 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 t 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 Goodhues task-technology t 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 modied to reect that the technology in question is UML and not information systems in general. The rst part of the survey consists of UML usage questions mapped directly to the task-technology t constructs as described by Goodhue [19] with some modications to make it UML specic. 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 ve 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 rst 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 specically relating to UML and how it is being utilized in the specic 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 benecial? 2. Does UML provide a task-technology t 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 , Objects by Design Forum, UML Forum, UML Cafe Zone, The Precise UML Newsgroup, Rational Unied 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) 383397

385

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 nal sample size used in this study at 131.

Table 2 Pearsons correlation coefcients for task variables Variable Flexibility Right data Understandability Training Ambiguity Correlation coefcient 0.888** 0.902** 0.664** 0.712** K0.174*

**Correlation is signicant at the 0.01 level (2-tailed). *Correlation is signicant at the 0.05 level (2-tailed).

signicance were exhibited for exibility, 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 signicant because it indicates that our sample population is well qualied to assess the task-technology t 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 reective 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

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 t study of Goodhue and Thompson [20], with some minor modications to reect UML usage. Cronbachs alphas were computed for each of the eight variables. Reliability coefcients for each of the variables are shown in Table 1. Three of the constructs (accuracy, compatibility and level of detail) exhibited Cronbachs 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 Cronbachs alpha reliability analysis Variable Right data Accuracy Compatibility Flexibility Understandability Level of detail Training Ambiguity Number of items 4 4 4 4 4 4 4 4 Reliability 0.7732 0.4446 0.6003 0.8175 0.7427 0.6280 0.7517 0.7584

Educational level No response Bachelors degree High school graduate Masters degree or above Some college Total

Frequency 1 57 3 57 13 131

Percent 0.8 43.5 2.3 43.5 9.9 100.0

Cumulative percent 0.8 44.3 46.6 90.1 100.0

386

M. Grossman et al. / Information and Software Technology 47 (2005) 383397 Table 6 Location of organization Country 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 Frequency 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 Percent 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 Cumulative percent 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

Table 4 Number of years experience with object-oriented technology Years experience 01 23 45 6C Total Frequency 6 24 26 75 131 Percent 4.6 18.3 19.8 57.3 100.0 Cumulative percent 4.6 22.9 42.7 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 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 Frequency 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 Percent 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 Cumulative percent 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 No response IT manager or supervisor Systems analyst Software developer Other Total Frequency 3 19 23 39 47 131 Percent 2.3 14.5 17.6 29.8 35.9 100.0 Cumulative percent 2.3 16.8 34.4 64.0 100.0

M. Grossman et al. / Information and Software Technology 47 (2005) 383397 Table 8 Industry Industry Wholesale/retail Aerospace Insurance Government No response Healthcare Industrial/manufacturing Telecommunications Education Banking/nancial services Other Information technology Total Frequency 3 3 5 5 6 7 7 7 9 10 18 51 131 Percent 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 Cumulative percent 2.3 4.6 8.4 12.2 16.8 22.1 27.5 32.8 39.7 47.3 61.1 100.0

387

TTF indices. In addition, other project and technology characteristics are examined. 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 916. 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 exibility categories (Tables 9 and 11) reect somewhat favorable perceptions on the part of most respondents. UML does not appear to be deemed overly inexible 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 insufciently specied 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 sufciently detailed diagrammatic constructs), while others were cast in a negative format (e.g. I nd UML to be too complex and difcult 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

did not see themselves tting 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 reected 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 ndings 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 benecial. A positive perception underlies task-technology t [20] and can be analyzed further by examining all of the individual items originally included in the survey as well as aggregate
Table 9 Right dataresponse frequencies Survey item

Strongly disagree 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 difcult 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 12 (9.2%) 4 (3.1%) 28 (21.4%)

Somewhat disagree 30 (22.9%) 17 (13.0%) 41 (31.3%)

Neither agree nor disagree 16 (12.2%) 16 (12.2%) 26 (19.8%)

Somewhat agree 52 (39.7%) 61 (46.6%) 22 (16.8%)

Strongly agree 21 (16.0%) 33 (25.2%) 14 (10.7%)

The right data

16 (12.2%)

32 (24.4%)

18 (13.7%)

45 (34.4%)

20 (15.3%)

388 Table 10 Accuracyresponse frequencies Survey item

M. Grossman et al. / Information and Software Technology 47 (2005) 383397

Strongly disagree 2. UMLs 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 4 (3.1%) 14 (10.7%) 3 (2.3%) 18 (13.7%)

Somewhat disagree 21 (16.0%) 47 (35.9%) 18 (13.7%) 53 (40.5%)

Neither agree nor disagree 9 (6.9%) 35 (26.7%) 42 (32.1%) 24 (18.3%)

Somewhat agree 62 (47.3%) 28 (21.4%) 32 (24.4%) 32 (24.4%)

Strongly agree 35 (26.7%) 7 (5.3%) 36 (27.5%) 4 (3.1%)

Accuracy

Table 11 Compatibilityresponse frequencies Survey item Strongly disagree 3. When it is necessary to compare or aggregate data from two or more different UML diagrams, there may be unexpected or difcult inconsistencies 11. There are times when supposedly equivalent information from two different UML diagrams is inconsistent 19. Sometimes it is difcult or impossible to compare or aggregate data from two different UML diagram sources because the data is dened differently 27. UML notations consistently mean the same thing regardless of where they are used 3 (2.3%) Somewhat disagree 18 (13.7%) Neither agree nor disagree 39 (29.8%) Somewhat agree 57 (43.5%) Strongly agree

Compatibility

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%)

Table 12 Flexibilityresponse frequencies Survey item Strongly disagree 4. UML is too inexible 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 difcult to change UML models. 28. UML provides enough exibility to model any system 28 (21.4%) 7 (5.3%) 35 (26.7%) 6 (4.6%) Somewhat disagree 65 (49.6%) 32 (24.4%) 48 (36.6%) 24 (18.3%) Neither agree nor disagree 16 (12.2%) 25 (19.1%) 21 (16.0%) 21 (16.0%) Somewhat agree 17 (13.0%) 58 (44.3%) 22 (16.8%) 54 (41.2%) Strongly agree 5 (3.8%) 9 (6.9%) 5 (3.8%) 26 (19.8%)

Flexibility

Table 13 Understandabilityresponse frequencies Survey item 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 nd UML to be too complex and difcult to understand 29. UML adequately conveys the meaning and intent of the underlying system 3 (2.3%) Somewhat disagree 12 (9.2%) Neither agree nor disagree 7 (5.3%) Somewhat agree 56 (42.7%) Strongly agree 53 (40.5%)

Understandability

2 (1.5%) 54 (41.2%) 5 (3.8%)

6 (4.6%) 40 (30.5%) 24 (18.3%)

11 (8.4%) 17 (13.0%) 29 (22.1%)

67 (51.1%) 13 (9.9%) 56 (42.7%)

45 (34.4%) 7 (5.3%) 17 (13.0%)

M. Grossman et al. / Information and Software Technology 47 (2005) 383397 Table 14 Level of detailresponse frequencies Survey item Strongly disagree 6. On the models that I deal with, the exact meaning of UMLs notational elements is either obvious, or easy to nd out 14. The exact denition of UML notational elements related to my tasks is easy to nd out 22. UML provides sufciently detailed diagrammatic constructs 30. UML contains too many notations and diagrams to be used effectively 6 (4.6%) Somewhat disagree 26 (19.8%) Neither agree nor disagree 19 (14.5%) Somewhat agree 50 (38.2%) Strongly agree

389

Level of detail

30 (22.9%)

2 (1.5%) 3 (2.3%) 33 (25.2%)

22 (16.8%) 16 (12.2%) 45 (34.4%)

22 (16.8%) 21 (16.0%) 26 (19.8%)

58 (44.3%) 67 (51.1%) 19 (14.5%)

27 (20.6%) 24 (18.3%) 8 (6.1%)

Table 15 Trainingresponse frequencies Survey item Strongly disagree 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 18 (13.7%) 19 (14.5%) 27 (20.6%) 12 (9.2%) Somewhat disagree 30 (22.9%) 21 (16.0%) 36 (27.5%) 25 (19.1%) Neither agree nor disagree 25 (19.1%) 37 (28.2%) 20 (15.3%) 28 (21.4%) Somewhat agree 36 (27.5%) 32 (24.4%) 35 (26.7%) 38 (29.0%) Strongly agree 22 (16.8%) 22 (16.8%) 13 (9.9%) 28 (21.4%)

Training

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.
Table 16 Ambiguityresponse frequencies Survey item

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%

Strongly disagree 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 insufciently specied, allowing developers to interpret them in more than one way 32. It is not always clear how to use UMLs notations across the different diagram types 23 (17.6%)

Somewhat disagree 49 (37.4%)

Neither agree nor disagree 17 (13.0%)

Somewhat agree 34 (26.0%)

Strongly agree 8 (6.1%)

Ambiguity

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 N TTF 131 Min. 2.10 Max. 4.35 Mean 3.3481 Std. dev. 0.4668

390

M. Grossman et al. / Information and Software Technology 47 (2005) 383397

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 reect usage of a smaller subset of UML, which is less complex and easier to work with.
Table 18 TTF indices by dimension Right data 3.17 Flexibility 3.53 Understandability 3.89

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 reect 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 reects 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 eld and to determine which factors might inuence 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

Training 3.15

Ambiguity 3

General TTF index 3.35

Table 19 TTF indices by geographic location of company Geographic region USA and Canada Europe Asia/Middle East Australia/New Zealand Africa South America Total Frequency 52 52 17 5 3 2 131 Percent 40 40 13 3.8 2.3 1.5 100.0 Cumulative percent 40 80 93 97 99 100 TTF index 3.24 3.39 3.52 3.15 3.77 3.40

M. Grossman et al. / Information and Software Technology 47 (2005) 383397 Table 20 Type of UML training Frequency Formal course Mentor Online tutorial Other 51 37 71 55 Percent 41.2 28.2 54.2 42.0 Table 22 Project development costs Project cost 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 Frequency 4 18 1 1 5 4 4 6 10 10 7 41 20 131 Percent 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 Cumulative percent 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

391

(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 certication 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 specication, 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 benet 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 nancial data. It is interesting to note that 30% of the respondents did not seem to have knowledge of the benet of the project they were working on. Table 23 shows the breakdown for the respondents. The results seem to reect 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 Frequency Capture and communicate requirements Guide development of code Reverse engineering Other 74 39 13 5 Percent 56.5 29.8 9.9 3.8 Cumulative percent 56.5 86.3 96.2 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 reected 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 individuals 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 renement [19].
Table 23 Project expected/realized benet Project benet 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 Frequency 14 21 1 1 5 2 1 9 2 6 3 28 38 131 Percent 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 Cumulative percent 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 Table 24 Management involvement Management involvement 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

M. Grossman et al. / Information and Software Technology 47 (2005) 383397

Frequency 2 39

Percent 1.5 29.8

Cumulative percent 1.5 31.3

40

30.5

61.8

36 14 131

27.5 10.7 100.0

89.3 100

Table 25 Use of UML in organization UML usage No response Other Used consistently on all development projects Used for large projects only Used sporadically with no mandate from management Total Frequency 1 14 36 22 58 131 Percent 0.8 10.7 27.5 16.8 44.3 100.0 Cumulative percent 0.8 10.7 27.5 16.8 44.3 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 Right data Management involvement (adjusted R2Z0.088) Extent of usage (adjusted R2Z0.074) Full endorsement Moderate endorsement Indifferent Used consistently Large projects only Sporadically 3.76 3.17 2.92 3.36 3.18 2.99

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 Unied Process [29] is the recommended approach, UML is meant to be independent of any specic 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, modied Objectory approach, Catalysis, Contextual Design, Feature Driven Design, DOD specic 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 Fowlers designation of the three types of UML usage (i.e. as sketch, blueprint or programming language) as a way to explain users selection of specic diagram types [16]. Depending on the specic 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 specication 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 ve projects in UML, reecting the relative immaturity of the modeling language. But, about 40% have done ve 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.

Flexibility 4.08 3.47 3.38 3.83 3.51 3.4

Understandability 3.88 3.94 3.67 4.04 4.18 3.72

Training 2.74 3.06 2.96 3.49 3.44 2.93

Ambiguity 3.47 2.95 3.28 2.99 2.73 3.13

TTF index 3.57 3.32 3.24 3.54 3.41 3.23

M. Grossman et al. / Information and Software Technology 47 (2005) 383397 Table 27 Methodology used in conjunction with UML Methodology No response Agile methodology None Structured approach Unied process Other Total Frequency 2 20 21 21 39 28 131 Percent 1.5 15.3 16.0 16.0 29.8 21.4 100.0 Cumulative percent 1.5 16.8 32.8 48.8 78.6 100.0

393

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 ipcharts. 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 communicatingand to many, I think it is. But to me, it is a way of communicating, and

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 dening 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 reect 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 efcient, thought provoking and on the contrary help in *simplifying* overly complex designs or concepts. In that UML can add signicant shareholder

Fig. 2. UML diagrams in order of use.

394

M. Grossman et al. / Information and Software Technology 47 (2005) 383397

Table 28 Number of UML projects completed by respondent UML projects completed No response 0 1 2 3 4 5 6 7 8 9 10 12 15 17 18 27 30 50 500 Total Frequency 11 8 12 20 17 10 14 6 2 2 1 15 2 3 1 1 1 3 1 1 131 Percent 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 Valid percent 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

nd 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 There are a number of managerial implications that arise as we study UML in the context of task-technology t. As UMLs 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 rst to ask a number of important questions to determine how well the usage of UML will t 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 t 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 t. 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

value. In being wrongly used, it can for sure be subtracting value. And yet other comments shed light on the difculties 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 students knowledge. A few practitioners will be convinced enough of the potential benets of the technique to work through these issues to

Fig. 3. UML tool usage.

M. Grossman et al. / Information and Software Technology 47 (2005) 383397

395

dened to allow its users to perceive its benet. As UML matures, it is tempting to conjecture that this situation will change and that a task-technology t will be more denitively 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 inuence task-technology t of UML usage. Specically, 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 specic 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 solidication 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 t 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 ne 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 Unied Modeling Language (UML) has become the de facto standard for object-oriented systems development and will soon be an international standard. Promoted as a unied 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, difculty to learn, incompleteness). This study used task-technology t theory as a theoretical backdrop to examine UML. Task-technology t theory

suggests that for an information technology to impact performance, it must rst meet the needs of the user, i.e. there must be a t between the task requirements of the user and the functionality of the system. This study extended prior task-technology t 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 identied 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 nal 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 exible enough to use on development projects. Further analysis is needed to determine which factors might have inuenced 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 denite effect was observed, supporting the idea that TTF is positively related to both the extent of UML use and to managements 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 identied in this study were right data, accuracy, compatibility, exibility, 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 Goodhues original constructs [20], accuracy was meant to measure the correctness of the data. In the present study, accuracy was altered slightly to reect the correctness of UMLs 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) 383397

mislead the developer, as Simons and Grahams cognicognitive misdirection concept suggests [36]. The questions in this category, although intuitively consistent, fail to hold together as evidenced by the low Chronbachs 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 rm enough grasp of the object-oriented paradigm. The level of detail construct was also included in Goodhues 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 gure 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 denition 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. Unied 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 t 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 ts with the tasks they are trying to perform. The fact that respondents to this survey failed to express strong opinions may reect the fact that UML is an immature standard that is still undergoing codication. 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 benecial effects. Much of the literature points to a technology that is complex, poorly understood, and used inconsistently. Perhaps, the results of this survey reect 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 HumanComputer Studies 45 (1996) 639 667. [2] D.H. Akehurst, A.G. Waters, UML deciencies from the perspective of automatic performance model generation, OOPSLA99 Workshop on Rigorous Modeling and Analysis with the UML: Challenges and Limitations, 1999. [3] S.W. Ambler, The Object Primer: The Application Developers 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 t: perspectives on achieving prototyping effectiveness, Journal of Management Information Systems 7 (3) (1991) 6787. [7] J. DAmbra, 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) 9821003. [9] M.T. Dishaw, D.M. Strong, Supporting software maintenance with software engineering tools: a computed task-technology t analysis, The Journal of Systems and Software 44 (1998) 107120. [10] M.T. Dishaw, D.M. Strong, D.B. Brandy, Assessing task-technology t 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) 414. [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, Unied Modeling Language: theoretical and practical complexity, Proceedings of the Ninth Americas Conference on Information Systems, Tampa, FL, 2003, pp. 13231327. [14] J. Fedorowicz, A.O. Villeneuve, Surveying object technology usage and benets: a test of conventional wisdom, Information & Management 35 (1999) 331344. [15] T.W. Ferratt, G.E. Vlahos, An investigation of task-technology t for managers in Greece and the U.S., European Journal of Information Systems 7 (1998) 123136. [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) 2533. [18] M. Glinz, Problems and deciencies of UML as a requirements specication language, Proceedings of the 10th International Workshop on Software Specication and Design (IWWSSD-10), San Diego, CA, 2000, pp. 1122. [19] D.L. Goodhue, Development and measurement validity of a tasktechnology t instrument for user evaluations of information systems, Decision Sciences 29 (1) (1998) 105138. [20] D.L. Goodhue, R.L. Thompson, Task-technology t and individual performance, MIS Quarterly 19 (2) (1995) 213236. [21] M. Grossman, R.V. McCarthy, J.E. Aronson, Factors inuencing Unied Modeling Language (UML) usage in the global software development community, Fourth Annual Global Information

M. Grossman et al. / Information and Software Technology 47 (2005) 383397 Technology Management (GITM) World Conference, Calgary, Canada, 2003, pp. 294297. T. Halpern, Augmenting UML with fact orientation, Proceedings of the 34th Hawaii International Conference on System Sciences, Maui, HI, 2001, pp. 110. B.C. Hardgrave, Adopting object-oriented development: one companys experience, Proceedings of the Sixth Americas Conference on Information Systems, Milwaukee, WI, 1999, pp. 568570. M. Hitz, G. Kappel, Developing with UML: some pitfalls and workarounds, The Unied Modeling Language, {UML}98Beyond 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) 512. C. Kobryn, Will UML 2.0 be agile or awkward? Communications of the ACM 45 (1) (2002) 107110. C. Larman, Applying UML and Patterns: An Introduction to ObjectOriented Analysis and Design and the Unied Process, second ed., Prentice Hall, Upper Saddle River, 2002. R.V. McCarthy, J.E. Aronson, G. Claffey, Task-technology t in data warehousing environments: analyzing the factors that affect utilization, Proceedings of the Eighth Americas Conference on Information Systems, Dallas, TX, 2002, pp. 4046. R.V. McCarthy, J.E. Aronson, K. Mazouz, Measuring the validity of task technology t for knowledge management systems, Proceedings of the Seventh Americas Conference on Information Systems, Boston, MA, 2001. U.S. Murthy, D.S. Kerr, Task/technology t and the effectiveness of Group Support Systems: evidence in the context of tasks requiring domain specic 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

[22]

[23]

[24]

[25]

[26] [27]

[28] [29]

[30]

[31]

[32]

[33]

[34] A.I. Shirani, M.H.A. Tafti, J.F. Afsco, Task and technology t: a comparison of two technologies for synchronous and asynchronous group communication, Information & Management 36 (1999) 139 150. [35] K. Siau, Q. Cao, Unied 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 Specication 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) 125143. [40] B. Tjahjono, D. Fakun, R. Greenough, J. Kay, Evaluation of a manufacturing task support system using the task technology t 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, OOPSLA98 Mid-year Workshop on Applied Object Technology, Denver, CO, 1998. [42] S. Wang, Experiences with the Unied Modeling Language (UML), Proceedings of the Seventh Americas Conference on Information Systems, Boston, MA, 2001, pp. 12891293. [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 t perspective, Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS03), 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 t theory for group support systems, The DATA BASE for Advances in Information Systems 30 (3) (1999) 3450.