- Email: [email protected]
Object-oriented methods: current practices and attitudes
The Journal of Systems and Software 48 (1999) 5±12
www.elsevier.com/locate/jss
Object-oriented methods: current practices and attitudes Richard A. Johnson a b
a,1
, Bill C. Hardgrave
b,*
Computer Information Systems Department, College of Business Administration, Southwest Missouri State University, Spring®eld, MO 65804, USA Computer Information Systems and Quantitative Analysis, College of Business Administration, University of Arkansas, Fayetteville, AR 72701, USA Received 13 June 1997; received in revised form 20 August 1997; accepted 10 January 1998
Abstract A total of 160 experienced object-oriented (OO) developers and OO trainees responded to a survey covering current practices and attitudes toward various OO methods, in particular and some aspects of OO systems development, in general. The survey probed into developers' training in OO analysis and design (OOAD) methods; familiarity, preference and use of OOAD methods; the use of OO tools; and attitudes toward OOAD methods. The purpose of this paper is to report the ®ndings in these areas. Overall, (1) trainees are relying more on universities and less on self-instruction compared to existing developers; (2) the Booch, OMT and Jacobson methods are known by, preferred by, and used by developers more than other methods; (3) automated tools are used regularly by less than 50% of developers; and (4) attitudes toward OOAD methods by developers and trainees are favorable, although some dierences do exist. The results are important for understanding the current state of, and attitudes toward, OOAD methods as interest in this area continues to grow and mature. Ó 1999 Elsevier Science Inc. All rights reserved.
1. Introduction Since the 1960s, systems development has evolved in an attempt to address the demands of today's organizations. Many of the traditional methods, such as structured development, have improved with the addition of tools, such as CASE and the incorporation of other methods, such as prototyping. New development approaches, such as information engineering and the spiral model, have been introduced to alleviate some of the shortcomings in traditional methods. While each new approach has had a positive impact on system development, the demands continue to increase for the quicker development of more complex systems (Booch, 1994; Fayad et al., 1996; Pressman, 1992; Weinberg et al., 1990). Although object-oriented (OO) technology has existed more than 30 years, it is only in the past decade that OO analysis and design methods have appeared as a viable alternative in developing organizational systems. OO systems development (OOSD) has gained acceptance partially due to claims of signi®cant increases in * Corresponding author. Tel.: +1 501 575 6099; fax: +1 501 575 7687. E-mail address: [email protected] (B.C. Hardgrave) 1 Tel.: +1-417-836-6685. E-mail address: [email protected] (R.A. Johnson)
both developer productivity and software quality (Booch, 1994; Fayad et al., 1996; Fayad and Tsai, 1995; Garceau et al., 1993; Weinberg et al., 1990; Yau and Tsai, 1986). The improvements in software development resulting from OOSD are attributed essentially to more understandable modeling of system requirements and improved reusability of software (Booch, 1994; Fayad et al., 1996; Fayad and Tsai, 1995; Garceau et al., 1993; Weinberg et al., 1990). While there are many published claims to the bene®ts of OOSD, perhaps the best evidence can be found among those who are using it on a regular basis. Also, the attitudes of current OO developers and those currently learning OO have an impact on its immediate and future use. The purpose of this paper is to report the results of an extensive survey of software developers who are being trained in OOSD or who have practical experience in developing applications using OOSD. While some of the survey deals with OOSD in general, most of it is concerned with OO analysis and design (OOAD) methods, a critical aspect of OOSD. The emphasis on OOAD is justi®ed since analysis and design of systems represents the backbone of the entire development eort (Byrd et al., 1992). The results of this survey should be able to shed much light on how OOAD is used and the perceptions of those using it.
0164-1212/99/$ ± see front matter Ó 1999 Elsevier Science Inc. All rights reserved. PII: S 0 1 6 4 - 1 2 1 2 ( 9 9 ) 0 0 0 4 1 - 2
6
R.A. Johnson, B.C. Hardgrave / The Journal of Systems and Software 48 (1999) 5±12
2. Methodology 2.1. Instrument development After a review of much of the existing literature on OOSD, a survey instrument was developed to facilitate investigation of relevant issues. The survey addressed (1) the respondents' general experience with OOSD, including training, tools and OOAD methods; (2) an evaluation of a speci®c OOAD method of the respondents' choosing; and (3) information about speci®c software development projects. Because a theory explaining attitudes and behavior toward, and use of OOAD methods does not currently exist, this study is using an inductive approach (i.e., using facts to develop general conclusions) as an attempt to move toward such a theory. Two separate versions of the survey accommodate two distinct groups of potential respondents: (1) those experienced at using OOSD on an actual production system (hereafter, `developer'), and (2) those who were trained in OOSD but who have no experience developing actual OO production systems (hereafter, `trainee'). The version for trainees does not include questions on a speci®c development project. The version for trainees also has many of the questions worded in the future tense in order to determine the trainees' expectations of OO development. 2.2. Sampling technique In order to achieve broad coverage of the OO development community, the survey was placed on the World Wide Web. This allowed developers across the US and around the world, in both small and large organizations, to access the survey in a relatively short period of time. A uniform resource locator for the survey was established so that potential respondents could access it using their favorite web browser. The homepage for the survey provided general instructions and links to the two dierent surveys (one for experienced OO developers, one for OO trainees). Once a respondent accessed the appropriate survey, additional brief instructions were provided and the survey process could begin. In most cases, the questions involved making a selection from among several alternative answers using checkboxes. In other cases, the respondent provided open-ended answers by typing in a textbox or text area on the survey form. In several cases, respondents who were noti®ed about the survey, but did not have access to the Web, requested an e-mail text version of the survey. Potential respondents were contacted in a variety of ways. Practitioners were contacted primarily via Internet newsgroups or lists associated with either general
software development technology or object technology. University faculty in the US were contacted by e-mail using computer science and MIS faculty directories. Potential respondents contacted over the Internet or by e-mail were encouraged to contact other OO developers/ trainees about the survey. 3. Results 3.1. Respondent characteristics A total of 160 respondents from widely diverse backgrounds participated in the survey. Several participants work for very large multinational corporations and universities, while others work in relatively small software production houses. Table 1 provides a breakdown of respondents by geographical area; Tables 2 and 3 indicate work experience and positions, respectively. Of the 160 respondents, 102 are experienced developers; 58 are trainees (i.e., no experience on an actual OO project). About two-thirds of the respondents are from the US; almost 20% of the respondents are from European countries. Three out of four developers have more than three years of non-OO experience; 90% have more than 12 months of OO experience. Over half the trainees have four or more years of non-OO experience. By de®nition, OO trainees have no OO experience in the development of an actual system utilizing OO technologies. Over 70% of all respondents (developers and trainees) are either project leaders, analysts or programmers. Overall, the respondents represent a large and geographically diverse group of both seasoned developers and trainees holding various positions in organizations.
Table 1 Survey respondents by geographical area Area
Experienced Developers
Trainees
Combined
n
n
n
(%)
(%)
(%)
US
68
67
43
74
111
69
Non-US Europe Canada Africa Australia Asia South America
23 4 3 2 1 1
22 4 3 2 1 1
8 2 1 0 2 2
14 3 2 0 3 3
31 6 4 2 3 3
19 4 3 1 2 2
Subtotal, Non-US
34
33
15
25
49
31
102
100
58
100
160
100
Total
R.A. Johnson, B.C. Hardgrave / The Journal of Systems and Software 48 (1999) 5±12 Table 2 Non-OO and OO development experience of respondents
<3 months 4±6 months 7±12 months 1±3 years 4±6 years >6 years Total
Non-OO experience
OO experience
Developers (n 102) (%)
Developers (n 102) (%)
Trainees (n 58) (%)
2 0 0 23 22 53
8 8 8 22 8 46
2 2 6 51 27 12
100
100
100
7
The fact that almost half the trainees have been selfinstructed may indicate that formal training from universities and seminars, while playing a larger role, is not yet capable of providing the level of expertise necessary to be a pro®cient OO developer. Mentoring does not seem to provide a major role in training for either experienced developers or trainees. This number may increase in the future as more developers gain experience with OO and can provide mentoring for newer developers. 3.3. OOAD methods ± familiarity, preferences and use
Table 3 Positions of survey respondents (n 160) Position
(%)
Analyst/Programmer Project leader Analyst Manager Student Programmer Instructor Engineer Consultant Other
40 16 10 8 8 5 4 2 2 5
3.2. Training in OOAD methods Table 4 provides a breakdown of the various types of training received by experienced developers and trainees. The percentages do not total to 100% since respondents could select more than one type of training received. Of the experienced developers, three out of four indicated that at least some of the training was selfinstructed, compared to less than half of the trainees. Only 12% of the developers received university training, compared to 36% for trainees. These results are intuitively what one would expect. Universities have only recently begun to provide, on a consistent basis, courses in OO technology (Douglas and Hardgrave, 1997). Thus, the percentage of those receiving training at an institute of higher learning would be expected to increase in the near future. Table 4 Type of training in OO methods for developers and trainees Type of Training
Developers (%)
Trainees (%)
Combined (%)
University Seminar Mentoring Self-instructed Other
12 29 10 76 5
36 18 9 45 9
17 26 10 68 6
The literature indicates several available OOAD methods from which to choose, including (in alphabetical order): Booch, Coad and Yourdon, Fusion, Jacobson, OMT, OOIE and Shlaer±Mellor. Respondents were asked to indicate their familiarity with (i.e., working knowledge of) OOAD methods and their method preferences for OO analysis and OO design. Respondents were allowed to select more than one method since, in many cases, developers are familiar with several methods. Table 5 provides the distribution of the ``Familiar'' OOAD methods by type of respondent. The three most familiar methods (Table 5) among experienced developers are OMT, Booch and Jacobson. These three methods are now combined in the Uni®ed Modeling Language (UML). Trainees are most familiar with OMT, Booch and Coad and Yourdon. Lower percentages of trainees are familiar with Booch, OMT and Jacobson compared to experienced developers. This is due primarily to the fact that most trainees generally know only one method while many experienced developers know more than one method. Also, trainees show a higher level of familiarity with Coad and Yourdon's method, compared to experienced developers. This is probably due to training received in university settings where Coad and Yourdon is the second most popular method (Douglas and Hardgrave, 1997). Table 5 OOAD methods familiar to OO developers OOAD method
Experienced Developers
Trainees
Combined
Booch Coad and Yourdon Fusion (Coleman) Jacobson OMT (Rumbaugh) OOIE (Martin) Shlaer±Mellor Other
41% 9% 8% 18% 52% 0% 12% 18%
24% 16% 10% 7% 40% 2% 5% 9%
35% 11% 9% 14% 48% 1% 9% 14%
Number of methods per respondent
1.5
1.1
1.3
Percentages do not add to 100% since respondents were allowed to select more than one method.
8
R.A. Johnson, B.C. Hardgrave / The Journal of Systems and Software 48 (1999) 5±12
Experienced developers were also asked to indicate their preferences for the various methods for the separate phases of analysis and design (as shown in Table 6). Note that Booch is preferred much more for design than analysis while OMT is preferred equally for both. The Jacobson method is as popular for analysis as Booch. The preference of developers in using OMT, Booch and Jacobson has fueled the need to combine the strengths of each to form the UML. The recent adoption (November 1997) of UML by the Object Management Group (OMG) as the standard notation set should solidify the notation and method used in industry, although it will probably take a few years to see an impact (due to lack of training, books and other materials about UML). Fusion makes a respectable showing for both analysis and design. Coad and Yourdon, although familiar to many developers, is only preferred by a few for analysis and none for design. The ®nal area of methods investigation involves the actual use of OOAD methods as determined by information supplied on 100 actual projects developed using OOAD methods. Table 7 shows the methods used for OO analysis and design. OMT is the most popular method for analysis and design, which is consistent with an earlier study by the Gartner Group which shows OMT as the most popular OOAD method among OO developers (Jones, 1995). OMT was also the method most preferred by developers (Table 6). Booch is the second most used method for analysis and design; Ja-
cobson is the third most used method for analysis. The current use of Booch, OMT and Jacobson suggests the natural progression to UML by many companies. Note from Table 7 that some of the methods identi®ed earlier as familiar to the developers (Table 5) or preferred by the developers (Table 6) are not actually used widely in industry (for example, Fusion). Table 8 provides information on the functional areas served by the projects reported. While R&D and Engineering account for 45% of the projects, business areas (i.e., accounting, customer service, ®nance, human resources, marketing, materials management, production/ operations) account for an even greater 48% of all projects reported. This fact is somewhat surprising since many feel that OOSD is not currently accepted well within the business community (Pancake, 1995). Table 9 provides a breakdown of the average percentages of time spent in the various phases of the development life cycle for the sample of 100 projects. Roughly one-fourth of the time is spent in each of the areas of planning/analysis, design and coding. Contrary to common suggestions of a 40±40±20 breakdown in the areas of analysis, design and coding/testing (Pressman, 1992), OO developers are spending about 29% on planning/analysis, 25% on design and 38% of their time on coding/testing/integration. Developers may be spending more time coding/testing/integrating for a variety of reasons related to the young age of OO. First, with any new language comes a new learning curve. As
Table 6 OOAD methods preferred by experienced developers (n 41)
Table 8 Functional areas of actual OO projects reported
Preferred for
OOAD method Booch Coad and Yourdon Fusion Jacobson OMT OOIE (Martin) Shlaer±Mellor Other
Analysis (%)
Design (%)
29 5 12 29 49 0 10 10
45 0 15 8 48 0 5 8
Respondents could indicate more than one preference.
Functional area
Projects (%)
1. Accounting 2. Customer service 3. Engineering 4. Finance 5. Human resources 6. Marketing 7. Materials management 8. Production/operations 9. R&D 10. Education 11. Other
2 7 19 10 2 6 4 17 26 5 2
Table 7 Methods used for OOA and OOD in actual projects Method Booch Coad and Yourdon Fusion Jacobson OOIE OMT Shlaer±Mellor Other
Percent of developers who used method for: Analysis (%)
Design (%)
23 5 2 8 0 36 7 16
30 3 2 2 2 39 7 11
Table 9 Average percentage of time spent by phase for OO projects OO project phase Planning Analysis Design Coding Testing Integration Maintenance
9% 20% 25% 25% 7% 6% 8%
R.A. Johnson, B.C. Hardgrave / The Journal of Systems and Software 48 (1999) 5±12 Table 10 Use of automated tools in OO analysis and/or design Developers
Never
Seldom
Sometimes
Often
Always
12%
20%
20%
32%
16%
developers become more familiar with OO programming languages, the overall percentage spent in coding/ testing/integrating should decrease. Second, and perhaps more importantly, the ®rst time an object is created takes longer than comparable coding with traditional development (Topper, 1995). It is estimated that a reusable object costs twice as much in time and eort as traditional software (Topper, 1995). As companies develop libraries of objects for reuse, the percentage of time spent on coding/testing/integrating should decrease. 3.4. Tools ± current practices An important part of any type of systems analysis and design eort is the availability and use of automated tools (i.e., CASE tools of varying abilities). Table 10 gives the breakdown of the use of automated tools in OO analysis and/or design. A total of 88% of developers report using such tools, but less than half use tools either often or always. This could indicate that OO tools are available but may not be used often due to their relative lack of sophistication. Also, a lack of standardization of OOAD methods may hinder the emergence of a `standard' OO CASE tool. The ®ndings here are consistent with previous studies which indicate the percentage of companies that use CASE tools regularly for structured analysis and design to be around 50% (Stickel, 1993). 3.5. Advantages and disadvantages of OOAD ± attitudes Proponents of OOSD claim that the methods as a whole promote developer productivity and software quality through more understandable modeling of sys-
9
tem requirements and reuse of software components (classes and objects). However, OOAD methods are viewed by some as somewhat dicult to learn (Fayad et al., 1996; Fayad and Tsai, 1995; Pancake, 1995). This diculty may tend to discourage the use of OOAD methods. To gather perceptions of productivity, quality, reuse, learning and understanding regarding various OOAD methods, respondents were asked to indicate the speci®c OOAD method with which they are most familiar (shown earlier in Table 5) and to respond to certain statements (based on Davis' perceived usefulness and perceived ease-of-use instrument; Davis, 1989) with that particular method in mind. Table 11 illustrates the statements and the respective mean responses for trainees and experienced developers. Trainee questions were phrased to represent their expectations of the future (e.g., ``Using this OOAD method will increase my productivity''). Respondents were asked to mentally compare their OOAD method to a conventional software development method (e.g., structured development) for which they are familiar (i.e., ``Using this OOAD method to model a system helps to reduce the total time required to implement an application'' requires the respondent to compare an OOAD method to a conventional method such as structured development). Most of the ratings are in the 5±6 (`slightly agree' to `agree') range, indicating that, on average, OOAD methods produce high levels of productivity, quality and reuse, and are easy to learn and understand. In every case but one (Item 6), developers provide higher ratings than trainees. The reason for higher developer ratings may be attributed to the experience they have gained developing systems which provides the realization of higher levels of productivity and quality. In contrast, trainees base their opinions on only what they have seen or heard, or on their ability to learn the methods. In fact, Item 3 demonstrates the trainees' level of diculty in learning the methods.
Table 11 Comparison of trainees' and developers' attitudes toward OOAD methods OO survey items
All OOAD methods Trainees (n 58)
1. 2. 3. 4. 5. 6. 7. 8. 9.
Using this OOAD method increases my productivity Overall, I ®nd this OOAD method useful in my job Learning to use this OOAD method is easy for me I ®nd this OOAD method easy to use Using this OOAD method to model a system helps to reduce the total time required to implement an application Using this OOAD method and its models allows me to reuse program code more eectively Using this OOAD method and its models is an eective way of capturing system requirements Using this OOAD method and its models makes the system more understandable to me I ®nd that using this OOAD method improves communication between users and developers
Scale: 1 Strongly disagree, 7 Strongly agree. Dierences in ratings signi®cant at the 0.05 level.
a
5.21 5.50 4.84 4.93 4.84 5.60 5.47 5.95 5.24
a a a a a a
Developers (n 102) 5.62 6.02 5.48 5.52 5.22 5.03 5.43 6.15 5.40
a a a a a a
10
R.A. Johnson, B.C. Hardgrave / The Journal of Systems and Software 48 (1999) 5±12
Item 6, the issue of reuse, is the only one for which the experienced developers' mean score is lower than the trainees' mean score. This could indicate that while training programs may emphasize this point, it has not been realized by experienced developers to a great degree. This conclusion could be explained by the relative immaturity of OO development eorts that have as yet not yielded many opportunities for reuse of software components. 3.6. OOAD methods ± attitudes and satisfaction Respondents were asked to indicate their overall satisfaction with the OOAD method they used most frequently. Again, respondents were asked to mentally compare OOAD methods to a conventional software development method (e.g., structured development) for which they are familiar. Table 12 gives the average overall satisfaction for all respondents, trainees, experienced developers, US developers and non-US developers. The mean level of satisfaction for all respondents and for all groups is roughly between the Somewhat Satis®ed ( 5) and Satis®ed ( 6) categories. Experienced developers generally have signi®cantly higher levels of satisfaction with OOAD methods than do trainees. This may indicate the possibility that while OOAD methods are dicult to learn, they are very useful once learned. While there is a statistically signi®cant dierence in satisfaction between US and non-US developers, the amount of the dierence is rather small. There are no signi®cant dierences in levels of satisfaction between US and non-US trainees. 4. Implications for practice and research The results presented herein have several implications for practice and future research. Primarily, issues related to training, use of OOAD methods and attitude are raised. Current trainees are relying more on universities and less on self-instruction compared to existing developers. Institutions of higher education have been increasing their OO course oerings during the past few years Table 12 Average overall satisfaction with OOAD methods Developer group
All methods
All respondents Trainees only Experienced developers only US developers only Non-US developers only US trainees only Non-US trainees only
5.64 5.16 5.91 5.78 6.18 5.02 5.53
a a a a
Scale: 1 Extremely dissatis®ed, 7 Extremely satis®ed. a Dierences in ratings signi®cant at the 0.05 level.
(Douglas and Hardgrave, 1997); these oerings are clearly beginning to make a dierence. Of course, this also indicates that higher education must pay close attention to the actual demands of industry regarding OOAD methods (i.e., UML) rather than teaching the most simple methods. For example, Coad and Yourdon is familiar to several trainees, but is only preferred and used by a few. UML should now be the choice in the classroom by universities. As OO continues to mature and grow in use, industry will look to universities to provide the background necessary to become a successful developer. Researchers can provide assistance in this area by exploring the proper approaches to teaching OO technology. This study, and others (e.g., Fayad et al., 1996), indicate that OO is not easy to learn. How should OO be taught? For example, should one start with OO concepts, then OOAD, then OOP; or start with OOP, then OOAD? What is the best approach to move seasoned developers (i.e., those that have been using conventional development methods for years) to object development? Signi®cant re-training of the existing development workforce may be necessary if OOSD grows as expected in the next few years. One of the important discoveries from this study is the familiarity, preference and use of Booch, OMT and Jacobson methods. Apparently, industry has settled on three good methods which have now collectively become UML. This ®nding implies that many companies can make a smooth transition to UML. Companies currently using the methods of Booch, OMT and Jacobson should have an easier time adopting UML compared to those companies that are using Shlaer±Mellor, for example. Also, trainees are very familiar with Booch, OMT and Jacobson, which will prove valuable to companies hiring these trainees (or training them) as they move to UML. These trainees, and companies, should have an advantage over those that have learned other methods. Future research should address issues related to the adoption of OOAD methods. With the standardization of UML, research can focus on two adoption issues: (1) for those companies wishing to move to OOSD, how do they make the transition from conventional methods to OOSD? (2) for those companies currently using an OOAD method, such as Booch, how do they make the transition to UML? Although developers and trainees tend to view OOAD methods favorably compared to conventional development methods, the opinions of trainees and developers dier in several key areas. For example, developers rated OOAD methods higher in productivity, usefulness, ease of use, ease of learning and speed of development, but lower in ability to reuse code. These dierences could be cause for concern. Trainee opinions are based on their training and the expectations they have concerning OO. Because most of the trainees in this study are experienced developers (in conventional
R.A. Johnson, B.C. Hardgrave / The Journal of Systems and Software 48 (1999) 5±12
methods), they may be skeptical concerning some of the claims of productivity and usefulness, thus resulting in lower opinion scores. This implies that we need to do a better job of training developers with conventional development experience in the use of OOAD methods. One particular area of concern is the anticipated bene®ts of reuse by trainees and the actual reuse experienced by developers. One of the most advertised bene®ts of OO is reuse, yet developers rated this lower than trainees. This is perhaps a case of trainees believing the hype about reuse, and developers actually realizing the diculty in creating reusable code. In the past few years, many claims have been made concerning the superiority of OO over conventional methods, especially in the areas of reuse, with little or no empirical support for such claims. Such unfounded claims may cause trainees, developers and companies to raise expectations to a level that can never be achieved. Overall, the purported bene®ts of OO should be bridled until research and practice have time to either prove or disprove them. Many previous technologies, such as CASE tools and expert systems, have been considered failures by many because they never lived up to the hype; OOSD could face the same situation. It is up to researchers and industry to explore and discover bene®ts and disadvantages of OOSD. A special emphasis should be placed on the issue of reuse; for example: (1) Why are immediate bene®ts of reuse not being realized? (2) Are companies providing the proper incentives for developers to produce reusable components? Developers and trainees expressed high levels of satisfaction with OOAD methods. This is a good indicator of the future of OOSD. Research in other areas has shown that a positive attitude (i.e., satisfaction) with a technology impacts one's intention to use the technology (Ajzen, 1991). Due to the favorable attitude and high level of satisfaction expressed by the respondents to this study, one would expect the use of OOSD to continue to climb. Many variables impacting a developer's intention can be studied by researchers, thus helping companies make the move to OOSD. Interestingly, non-US developers expressed a higher level of satisfaction than US developers. Non-US developers, especially European developers, have been using OOAD methods much longer than US developers. Does this explain their higher levels of satisfaction? Or, does something other than longevity of use explain their satisfaction? In addition to the above implications, other more practical issues are raised: (1) Why are automated tools not used frequently, and will the adoption of UML increase the use of tools? (2) What type of projects are experiencing the most bene®ts from OOSD (i.e., complex business systems, simple business systems, complex engineering systems, etc.)? The answer to these questions and many others can be addressed in time. Longitudinal
11
studies would be helpful in monitoring the progress of OOSD along many of the dimensions presented in this research. 4.1. Limitations of the study Two limitations of this study should be noted. First, most surveys suer from the problem of self selection. In this case, it is possible that only those developers and trainees with a positive attitude toward OO responded to the survey. This, obviously, would tend to bias the results. Unfortunately, given the random nature of data collection used in this study, it is impossible to assess the representativeness of the sample. The second limitation involves the lack of a theory to guide the research. As mentioned earlier, this study took an inductive approach to data collection. That is, facts were gathered in hopes of drawing some general conclusions. In this case, the results provided some insight into developing a theory of OOAD attitude, behavior and use. For example, the ®ndings lend themselves nicely to the theory of planned behavior (Ajzen, 1991) which suggests that attitudes impact behaviors (speci®cally, one's attitude about OO may lead one to use/not use OO). Of course, organizational goals must be considered in an investigation of behavior (Hollenbeck and Klein, 1987). 5. Conclusion This study surveyed OO developers and trainees throughout the world. Data concerning respondent backgrounds, training, attitudes, behaviors and OO projects were collected from 160 respondents. Booch, OMT and Jacobson are familiar to, preferred by, and used by, many of the respondents. This ®nding is particularly interesting given that UML has received recent adoption by OMG. UML contains elements of the three aforementioned methods, thus the transition to UML should be smooth for many developers. Current trainees are receiving more training from universities and less self-instruction compared to existing developers. Hopefully, the availability of useful automated tools will increase, which can facilitate training and actual development (this study found that automated tools are used regularly by less than 50% of developers). The adoption of UML should help fuel the growth of automated tools because toolmakers will have a standard notation as a basis for the tools. Overall, results indicate that developers and trainees view OOAD methods favorably and expressed high levels of satisfaction, although dierences did exist between developers and trainees. For example, developers feel less strongly about OOAD's capability to foster reuse of code. Positive attitudes and high levels of satisfaction are favorable indicators of the future of OOSD.
12
R.A. Johnson, B.C. Hardgrave / The Journal of Systems and Software 48 (1999) 5±12
References Ajzen, I., 1991. The theory of planned behavior. Organizational Behavior and Human Decision Processes 50, 179±211. Booch, G., 1994. Object-Oriented Analysis and Design With Applications, 2nd ed. Benjamin/Cummings, Redwood City, CA. Byrd, T.A., Cossick, K.L., Zmud, R.W., 1992. A synthesis of research on requirements analysis and knowledge acquisition techniques. MIS Quarterly 16 (1), 117±138. Davis, F.D., 1989. Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Quarterly 13 (3), 319±340. Douglas, D.E., Hardgrave, B.C., 1997. Object-Oriented Trends: information systems degree programs. AIS Americas Conference on Information Systems, August, 754±755. Fayad, M.E., Tsai, W., 1995. Object-Oriented experiences. Communications of the ACM 38 (10), 51±53. Fayad, M.E., Tsai, W., Fulghum, M.L., 1996. Transition to objectoriented software development. Communications of the ACM 39 (2), 108±121. Garceau, L., Jancura, E., Kneiss, J., 1993. Object-Oriented Analysis and Design: a new approach to systems development. Journal of Systems Management, January, 25±32. Hollenbeck, J., Klein, H., 1987. Goal Commitment and the GoalSetting Process: problems, prospects and proposals for future research. Journal of Applied Psychology 72, 204±211. Jones, N., 1995. Results of a survey on object orientation. The Gartner Group, Research Note T-700-1192, July 12.
Pancake, C.M., 1995. The Promise and the Cost of Object Technology: a ®ve year forecast. Communications of the ACM 38 (10), 33±49. Pressman, R.S., 1992. Software Engineering ± A Practitioner's Approach, 3rd ed. McGraw-Hill, New York, NY. Stickel, E.U., 1993. An experience with CASE tool support for ®nancial product design. Data Base 24 (4), 31±35. Topper, A., 1995. Object-Oriented Development in COBOL, McGraw-Hill, New York, NY. Weinberg, R., Guimaraes, T., Heath, R., 1990. Object-oriented systems development. Journal of Information Systems Management 7 (4), 18±26. Yau, S.S., Tsai, J.J.-P., 1986. A survey of software design techniques. IEEE Transactions on Software Engineering 12 (6), 716±721. Richard A. Johnson is an Assistant Professor in the Computer Information Systems Department at Southwest Missouri State University. He received his Ph.D. in CIS from the University of Arkansas. His current research interests include software development and adoption of software development processes. Bill C. Hardgrave is an Associate Professor in the Computer Information Systems and Quantitative Analysis Department at the University of Arkansas. He received his Ph.D. in MIS from Oklahoma State University. Dr. Hardgrave has published in journals such as Communications of the ACM, Journal of Systems and Software, Information and Software Technology, Journal of Database Management, Computers and Operations Research among others. His current research interests include software development, object-oriented technology and prototyping.
www.elsevier.com/locate/jss
Object-oriented methods: current practices and attitudes Richard A. Johnson a b
a,1
, Bill C. Hardgrave
b,*
Computer Information Systems Department, College of Business Administration, Southwest Missouri State University, Spring®eld, MO 65804, USA Computer Information Systems and Quantitative Analysis, College of Business Administration, University of Arkansas, Fayetteville, AR 72701, USA Received 13 June 1997; received in revised form 20 August 1997; accepted 10 January 1998
Abstract A total of 160 experienced object-oriented (OO) developers and OO trainees responded to a survey covering current practices and attitudes toward various OO methods, in particular and some aspects of OO systems development, in general. The survey probed into developers' training in OO analysis and design (OOAD) methods; familiarity, preference and use of OOAD methods; the use of OO tools; and attitudes toward OOAD methods. The purpose of this paper is to report the ®ndings in these areas. Overall, (1) trainees are relying more on universities and less on self-instruction compared to existing developers; (2) the Booch, OMT and Jacobson methods are known by, preferred by, and used by developers more than other methods; (3) automated tools are used regularly by less than 50% of developers; and (4) attitudes toward OOAD methods by developers and trainees are favorable, although some dierences do exist. The results are important for understanding the current state of, and attitudes toward, OOAD methods as interest in this area continues to grow and mature. Ó 1999 Elsevier Science Inc. All rights reserved.
1. Introduction Since the 1960s, systems development has evolved in an attempt to address the demands of today's organizations. Many of the traditional methods, such as structured development, have improved with the addition of tools, such as CASE and the incorporation of other methods, such as prototyping. New development approaches, such as information engineering and the spiral model, have been introduced to alleviate some of the shortcomings in traditional methods. While each new approach has had a positive impact on system development, the demands continue to increase for the quicker development of more complex systems (Booch, 1994; Fayad et al., 1996; Pressman, 1992; Weinberg et al., 1990). Although object-oriented (OO) technology has existed more than 30 years, it is only in the past decade that OO analysis and design methods have appeared as a viable alternative in developing organizational systems. OO systems development (OOSD) has gained acceptance partially due to claims of signi®cant increases in * Corresponding author. Tel.: +1 501 575 6099; fax: +1 501 575 7687. E-mail address: [email protected] (B.C. Hardgrave) 1 Tel.: +1-417-836-6685. E-mail address: [email protected] (R.A. Johnson)
both developer productivity and software quality (Booch, 1994; Fayad et al., 1996; Fayad and Tsai, 1995; Garceau et al., 1993; Weinberg et al., 1990; Yau and Tsai, 1986). The improvements in software development resulting from OOSD are attributed essentially to more understandable modeling of system requirements and improved reusability of software (Booch, 1994; Fayad et al., 1996; Fayad and Tsai, 1995; Garceau et al., 1993; Weinberg et al., 1990). While there are many published claims to the bene®ts of OOSD, perhaps the best evidence can be found among those who are using it on a regular basis. Also, the attitudes of current OO developers and those currently learning OO have an impact on its immediate and future use. The purpose of this paper is to report the results of an extensive survey of software developers who are being trained in OOSD or who have practical experience in developing applications using OOSD. While some of the survey deals with OOSD in general, most of it is concerned with OO analysis and design (OOAD) methods, a critical aspect of OOSD. The emphasis on OOAD is justi®ed since analysis and design of systems represents the backbone of the entire development eort (Byrd et al., 1992). The results of this survey should be able to shed much light on how OOAD is used and the perceptions of those using it.
0164-1212/99/$ ± see front matter Ó 1999 Elsevier Science Inc. All rights reserved. PII: S 0 1 6 4 - 1 2 1 2 ( 9 9 ) 0 0 0 4 1 - 2
6
R.A. Johnson, B.C. Hardgrave / The Journal of Systems and Software 48 (1999) 5±12
2. Methodology 2.1. Instrument development After a review of much of the existing literature on OOSD, a survey instrument was developed to facilitate investigation of relevant issues. The survey addressed (1) the respondents' general experience with OOSD, including training, tools and OOAD methods; (2) an evaluation of a speci®c OOAD method of the respondents' choosing; and (3) information about speci®c software development projects. Because a theory explaining attitudes and behavior toward, and use of OOAD methods does not currently exist, this study is using an inductive approach (i.e., using facts to develop general conclusions) as an attempt to move toward such a theory. Two separate versions of the survey accommodate two distinct groups of potential respondents: (1) those experienced at using OOSD on an actual production system (hereafter, `developer'), and (2) those who were trained in OOSD but who have no experience developing actual OO production systems (hereafter, `trainee'). The version for trainees does not include questions on a speci®c development project. The version for trainees also has many of the questions worded in the future tense in order to determine the trainees' expectations of OO development. 2.2. Sampling technique In order to achieve broad coverage of the OO development community, the survey was placed on the World Wide Web. This allowed developers across the US and around the world, in both small and large organizations, to access the survey in a relatively short period of time. A uniform resource locator for the survey was established so that potential respondents could access it using their favorite web browser. The homepage for the survey provided general instructions and links to the two dierent surveys (one for experienced OO developers, one for OO trainees). Once a respondent accessed the appropriate survey, additional brief instructions were provided and the survey process could begin. In most cases, the questions involved making a selection from among several alternative answers using checkboxes. In other cases, the respondent provided open-ended answers by typing in a textbox or text area on the survey form. In several cases, respondents who were noti®ed about the survey, but did not have access to the Web, requested an e-mail text version of the survey. Potential respondents were contacted in a variety of ways. Practitioners were contacted primarily via Internet newsgroups or lists associated with either general
software development technology or object technology. University faculty in the US were contacted by e-mail using computer science and MIS faculty directories. Potential respondents contacted over the Internet or by e-mail were encouraged to contact other OO developers/ trainees about the survey. 3. Results 3.1. Respondent characteristics A total of 160 respondents from widely diverse backgrounds participated in the survey. Several participants work for very large multinational corporations and universities, while others work in relatively small software production houses. Table 1 provides a breakdown of respondents by geographical area; Tables 2 and 3 indicate work experience and positions, respectively. Of the 160 respondents, 102 are experienced developers; 58 are trainees (i.e., no experience on an actual OO project). About two-thirds of the respondents are from the US; almost 20% of the respondents are from European countries. Three out of four developers have more than three years of non-OO experience; 90% have more than 12 months of OO experience. Over half the trainees have four or more years of non-OO experience. By de®nition, OO trainees have no OO experience in the development of an actual system utilizing OO technologies. Over 70% of all respondents (developers and trainees) are either project leaders, analysts or programmers. Overall, the respondents represent a large and geographically diverse group of both seasoned developers and trainees holding various positions in organizations.
Table 1 Survey respondents by geographical area Area
Experienced Developers
Trainees
Combined
n
n
n
(%)
(%)
(%)
US
68
67
43
74
111
69
Non-US Europe Canada Africa Australia Asia South America
23 4 3 2 1 1
22 4 3 2 1 1
8 2 1 0 2 2
14 3 2 0 3 3
31 6 4 2 3 3
19 4 3 1 2 2
Subtotal, Non-US
34
33
15
25
49
31
102
100
58
100
160
100
Total
R.A. Johnson, B.C. Hardgrave / The Journal of Systems and Software 48 (1999) 5±12 Table 2 Non-OO and OO development experience of respondents
<3 months 4±6 months 7±12 months 1±3 years 4±6 years >6 years Total
Non-OO experience
OO experience
Developers (n 102) (%)
Developers (n 102) (%)
Trainees (n 58) (%)
2 0 0 23 22 53
8 8 8 22 8 46
2 2 6 51 27 12
100
100
100
7
The fact that almost half the trainees have been selfinstructed may indicate that formal training from universities and seminars, while playing a larger role, is not yet capable of providing the level of expertise necessary to be a pro®cient OO developer. Mentoring does not seem to provide a major role in training for either experienced developers or trainees. This number may increase in the future as more developers gain experience with OO and can provide mentoring for newer developers. 3.3. OOAD methods ± familiarity, preferences and use
Table 3 Positions of survey respondents (n 160) Position
(%)
Analyst/Programmer Project leader Analyst Manager Student Programmer Instructor Engineer Consultant Other
40 16 10 8 8 5 4 2 2 5
3.2. Training in OOAD methods Table 4 provides a breakdown of the various types of training received by experienced developers and trainees. The percentages do not total to 100% since respondents could select more than one type of training received. Of the experienced developers, three out of four indicated that at least some of the training was selfinstructed, compared to less than half of the trainees. Only 12% of the developers received university training, compared to 36% for trainees. These results are intuitively what one would expect. Universities have only recently begun to provide, on a consistent basis, courses in OO technology (Douglas and Hardgrave, 1997). Thus, the percentage of those receiving training at an institute of higher learning would be expected to increase in the near future. Table 4 Type of training in OO methods for developers and trainees Type of Training
Developers (%)
Trainees (%)
Combined (%)
University Seminar Mentoring Self-instructed Other
12 29 10 76 5
36 18 9 45 9
17 26 10 68 6
The literature indicates several available OOAD methods from which to choose, including (in alphabetical order): Booch, Coad and Yourdon, Fusion, Jacobson, OMT, OOIE and Shlaer±Mellor. Respondents were asked to indicate their familiarity with (i.e., working knowledge of) OOAD methods and their method preferences for OO analysis and OO design. Respondents were allowed to select more than one method since, in many cases, developers are familiar with several methods. Table 5 provides the distribution of the ``Familiar'' OOAD methods by type of respondent. The three most familiar methods (Table 5) among experienced developers are OMT, Booch and Jacobson. These three methods are now combined in the Uni®ed Modeling Language (UML). Trainees are most familiar with OMT, Booch and Coad and Yourdon. Lower percentages of trainees are familiar with Booch, OMT and Jacobson compared to experienced developers. This is due primarily to the fact that most trainees generally know only one method while many experienced developers know more than one method. Also, trainees show a higher level of familiarity with Coad and Yourdon's method, compared to experienced developers. This is probably due to training received in university settings where Coad and Yourdon is the second most popular method (Douglas and Hardgrave, 1997). Table 5 OOAD methods familiar to OO developers OOAD method
Experienced Developers
Trainees
Combined
Booch Coad and Yourdon Fusion (Coleman) Jacobson OMT (Rumbaugh) OOIE (Martin) Shlaer±Mellor Other
41% 9% 8% 18% 52% 0% 12% 18%
24% 16% 10% 7% 40% 2% 5% 9%
35% 11% 9% 14% 48% 1% 9% 14%
Number of methods per respondent
1.5
1.1
1.3
Percentages do not add to 100% since respondents were allowed to select more than one method.
8
R.A. Johnson, B.C. Hardgrave / The Journal of Systems and Software 48 (1999) 5±12
Experienced developers were also asked to indicate their preferences for the various methods for the separate phases of analysis and design (as shown in Table 6). Note that Booch is preferred much more for design than analysis while OMT is preferred equally for both. The Jacobson method is as popular for analysis as Booch. The preference of developers in using OMT, Booch and Jacobson has fueled the need to combine the strengths of each to form the UML. The recent adoption (November 1997) of UML by the Object Management Group (OMG) as the standard notation set should solidify the notation and method used in industry, although it will probably take a few years to see an impact (due to lack of training, books and other materials about UML). Fusion makes a respectable showing for both analysis and design. Coad and Yourdon, although familiar to many developers, is only preferred by a few for analysis and none for design. The ®nal area of methods investigation involves the actual use of OOAD methods as determined by information supplied on 100 actual projects developed using OOAD methods. Table 7 shows the methods used for OO analysis and design. OMT is the most popular method for analysis and design, which is consistent with an earlier study by the Gartner Group which shows OMT as the most popular OOAD method among OO developers (Jones, 1995). OMT was also the method most preferred by developers (Table 6). Booch is the second most used method for analysis and design; Ja-
cobson is the third most used method for analysis. The current use of Booch, OMT and Jacobson suggests the natural progression to UML by many companies. Note from Table 7 that some of the methods identi®ed earlier as familiar to the developers (Table 5) or preferred by the developers (Table 6) are not actually used widely in industry (for example, Fusion). Table 8 provides information on the functional areas served by the projects reported. While R&D and Engineering account for 45% of the projects, business areas (i.e., accounting, customer service, ®nance, human resources, marketing, materials management, production/ operations) account for an even greater 48% of all projects reported. This fact is somewhat surprising since many feel that OOSD is not currently accepted well within the business community (Pancake, 1995). Table 9 provides a breakdown of the average percentages of time spent in the various phases of the development life cycle for the sample of 100 projects. Roughly one-fourth of the time is spent in each of the areas of planning/analysis, design and coding. Contrary to common suggestions of a 40±40±20 breakdown in the areas of analysis, design and coding/testing (Pressman, 1992), OO developers are spending about 29% on planning/analysis, 25% on design and 38% of their time on coding/testing/integration. Developers may be spending more time coding/testing/integrating for a variety of reasons related to the young age of OO. First, with any new language comes a new learning curve. As
Table 6 OOAD methods preferred by experienced developers (n 41)
Table 8 Functional areas of actual OO projects reported
Preferred for
OOAD method Booch Coad and Yourdon Fusion Jacobson OMT OOIE (Martin) Shlaer±Mellor Other
Analysis (%)
Design (%)
29 5 12 29 49 0 10 10
45 0 15 8 48 0 5 8
Respondents could indicate more than one preference.
Functional area
Projects (%)
1. Accounting 2. Customer service 3. Engineering 4. Finance 5. Human resources 6. Marketing 7. Materials management 8. Production/operations 9. R&D 10. Education 11. Other
2 7 19 10 2 6 4 17 26 5 2
Table 7 Methods used for OOA and OOD in actual projects Method Booch Coad and Yourdon Fusion Jacobson OOIE OMT Shlaer±Mellor Other
Percent of developers who used method for: Analysis (%)
Design (%)
23 5 2 8 0 36 7 16
30 3 2 2 2 39 7 11
Table 9 Average percentage of time spent by phase for OO projects OO project phase Planning Analysis Design Coding Testing Integration Maintenance
9% 20% 25% 25% 7% 6% 8%
R.A. Johnson, B.C. Hardgrave / The Journal of Systems and Software 48 (1999) 5±12 Table 10 Use of automated tools in OO analysis and/or design Developers
Never
Seldom
Sometimes
Often
Always
12%
20%
20%
32%
16%
developers become more familiar with OO programming languages, the overall percentage spent in coding/ testing/integrating should decrease. Second, and perhaps more importantly, the ®rst time an object is created takes longer than comparable coding with traditional development (Topper, 1995). It is estimated that a reusable object costs twice as much in time and eort as traditional software (Topper, 1995). As companies develop libraries of objects for reuse, the percentage of time spent on coding/testing/integrating should decrease. 3.4. Tools ± current practices An important part of any type of systems analysis and design eort is the availability and use of automated tools (i.e., CASE tools of varying abilities). Table 10 gives the breakdown of the use of automated tools in OO analysis and/or design. A total of 88% of developers report using such tools, but less than half use tools either often or always. This could indicate that OO tools are available but may not be used often due to their relative lack of sophistication. Also, a lack of standardization of OOAD methods may hinder the emergence of a `standard' OO CASE tool. The ®ndings here are consistent with previous studies which indicate the percentage of companies that use CASE tools regularly for structured analysis and design to be around 50% (Stickel, 1993). 3.5. Advantages and disadvantages of OOAD ± attitudes Proponents of OOSD claim that the methods as a whole promote developer productivity and software quality through more understandable modeling of sys-
9
tem requirements and reuse of software components (classes and objects). However, OOAD methods are viewed by some as somewhat dicult to learn (Fayad et al., 1996; Fayad and Tsai, 1995; Pancake, 1995). This diculty may tend to discourage the use of OOAD methods. To gather perceptions of productivity, quality, reuse, learning and understanding regarding various OOAD methods, respondents were asked to indicate the speci®c OOAD method with which they are most familiar (shown earlier in Table 5) and to respond to certain statements (based on Davis' perceived usefulness and perceived ease-of-use instrument; Davis, 1989) with that particular method in mind. Table 11 illustrates the statements and the respective mean responses for trainees and experienced developers. Trainee questions were phrased to represent their expectations of the future (e.g., ``Using this OOAD method will increase my productivity''). Respondents were asked to mentally compare their OOAD method to a conventional software development method (e.g., structured development) for which they are familiar (i.e., ``Using this OOAD method to model a system helps to reduce the total time required to implement an application'' requires the respondent to compare an OOAD method to a conventional method such as structured development). Most of the ratings are in the 5±6 (`slightly agree' to `agree') range, indicating that, on average, OOAD methods produce high levels of productivity, quality and reuse, and are easy to learn and understand. In every case but one (Item 6), developers provide higher ratings than trainees. The reason for higher developer ratings may be attributed to the experience they have gained developing systems which provides the realization of higher levels of productivity and quality. In contrast, trainees base their opinions on only what they have seen or heard, or on their ability to learn the methods. In fact, Item 3 demonstrates the trainees' level of diculty in learning the methods.
Table 11 Comparison of trainees' and developers' attitudes toward OOAD methods OO survey items
All OOAD methods Trainees (n 58)
1. 2. 3. 4. 5. 6. 7. 8. 9.
Using this OOAD method increases my productivity Overall, I ®nd this OOAD method useful in my job Learning to use this OOAD method is easy for me I ®nd this OOAD method easy to use Using this OOAD method to model a system helps to reduce the total time required to implement an application Using this OOAD method and its models allows me to reuse program code more eectively Using this OOAD method and its models is an eective way of capturing system requirements Using this OOAD method and its models makes the system more understandable to me I ®nd that using this OOAD method improves communication between users and developers
Scale: 1 Strongly disagree, 7 Strongly agree. Dierences in ratings signi®cant at the 0.05 level.
a
5.21 5.50 4.84 4.93 4.84 5.60 5.47 5.95 5.24
a a a a a a
Developers (n 102) 5.62 6.02 5.48 5.52 5.22 5.03 5.43 6.15 5.40
a a a a a a
10
R.A. Johnson, B.C. Hardgrave / The Journal of Systems and Software 48 (1999) 5±12
Item 6, the issue of reuse, is the only one for which the experienced developers' mean score is lower than the trainees' mean score. This could indicate that while training programs may emphasize this point, it has not been realized by experienced developers to a great degree. This conclusion could be explained by the relative immaturity of OO development eorts that have as yet not yielded many opportunities for reuse of software components. 3.6. OOAD methods ± attitudes and satisfaction Respondents were asked to indicate their overall satisfaction with the OOAD method they used most frequently. Again, respondents were asked to mentally compare OOAD methods to a conventional software development method (e.g., structured development) for which they are familiar. Table 12 gives the average overall satisfaction for all respondents, trainees, experienced developers, US developers and non-US developers. The mean level of satisfaction for all respondents and for all groups is roughly between the Somewhat Satis®ed ( 5) and Satis®ed ( 6) categories. Experienced developers generally have signi®cantly higher levels of satisfaction with OOAD methods than do trainees. This may indicate the possibility that while OOAD methods are dicult to learn, they are very useful once learned. While there is a statistically signi®cant dierence in satisfaction between US and non-US developers, the amount of the dierence is rather small. There are no signi®cant dierences in levels of satisfaction between US and non-US trainees. 4. Implications for practice and research The results presented herein have several implications for practice and future research. Primarily, issues related to training, use of OOAD methods and attitude are raised. Current trainees are relying more on universities and less on self-instruction compared to existing developers. Institutions of higher education have been increasing their OO course oerings during the past few years Table 12 Average overall satisfaction with OOAD methods Developer group
All methods
All respondents Trainees only Experienced developers only US developers only Non-US developers only US trainees only Non-US trainees only
5.64 5.16 5.91 5.78 6.18 5.02 5.53
a a a a
Scale: 1 Extremely dissatis®ed, 7 Extremely satis®ed. a Dierences in ratings signi®cant at the 0.05 level.
(Douglas and Hardgrave, 1997); these oerings are clearly beginning to make a dierence. Of course, this also indicates that higher education must pay close attention to the actual demands of industry regarding OOAD methods (i.e., UML) rather than teaching the most simple methods. For example, Coad and Yourdon is familiar to several trainees, but is only preferred and used by a few. UML should now be the choice in the classroom by universities. As OO continues to mature and grow in use, industry will look to universities to provide the background necessary to become a successful developer. Researchers can provide assistance in this area by exploring the proper approaches to teaching OO technology. This study, and others (e.g., Fayad et al., 1996), indicate that OO is not easy to learn. How should OO be taught? For example, should one start with OO concepts, then OOAD, then OOP; or start with OOP, then OOAD? What is the best approach to move seasoned developers (i.e., those that have been using conventional development methods for years) to object development? Signi®cant re-training of the existing development workforce may be necessary if OOSD grows as expected in the next few years. One of the important discoveries from this study is the familiarity, preference and use of Booch, OMT and Jacobson methods. Apparently, industry has settled on three good methods which have now collectively become UML. This ®nding implies that many companies can make a smooth transition to UML. Companies currently using the methods of Booch, OMT and Jacobson should have an easier time adopting UML compared to those companies that are using Shlaer±Mellor, for example. Also, trainees are very familiar with Booch, OMT and Jacobson, which will prove valuable to companies hiring these trainees (or training them) as they move to UML. These trainees, and companies, should have an advantage over those that have learned other methods. Future research should address issues related to the adoption of OOAD methods. With the standardization of UML, research can focus on two adoption issues: (1) for those companies wishing to move to OOSD, how do they make the transition from conventional methods to OOSD? (2) for those companies currently using an OOAD method, such as Booch, how do they make the transition to UML? Although developers and trainees tend to view OOAD methods favorably compared to conventional development methods, the opinions of trainees and developers dier in several key areas. For example, developers rated OOAD methods higher in productivity, usefulness, ease of use, ease of learning and speed of development, but lower in ability to reuse code. These dierences could be cause for concern. Trainee opinions are based on their training and the expectations they have concerning OO. Because most of the trainees in this study are experienced developers (in conventional
R.A. Johnson, B.C. Hardgrave / The Journal of Systems and Software 48 (1999) 5±12
methods), they may be skeptical concerning some of the claims of productivity and usefulness, thus resulting in lower opinion scores. This implies that we need to do a better job of training developers with conventional development experience in the use of OOAD methods. One particular area of concern is the anticipated bene®ts of reuse by trainees and the actual reuse experienced by developers. One of the most advertised bene®ts of OO is reuse, yet developers rated this lower than trainees. This is perhaps a case of trainees believing the hype about reuse, and developers actually realizing the diculty in creating reusable code. In the past few years, many claims have been made concerning the superiority of OO over conventional methods, especially in the areas of reuse, with little or no empirical support for such claims. Such unfounded claims may cause trainees, developers and companies to raise expectations to a level that can never be achieved. Overall, the purported bene®ts of OO should be bridled until research and practice have time to either prove or disprove them. Many previous technologies, such as CASE tools and expert systems, have been considered failures by many because they never lived up to the hype; OOSD could face the same situation. It is up to researchers and industry to explore and discover bene®ts and disadvantages of OOSD. A special emphasis should be placed on the issue of reuse; for example: (1) Why are immediate bene®ts of reuse not being realized? (2) Are companies providing the proper incentives for developers to produce reusable components? Developers and trainees expressed high levels of satisfaction with OOAD methods. This is a good indicator of the future of OOSD. Research in other areas has shown that a positive attitude (i.e., satisfaction) with a technology impacts one's intention to use the technology (Ajzen, 1991). Due to the favorable attitude and high level of satisfaction expressed by the respondents to this study, one would expect the use of OOSD to continue to climb. Many variables impacting a developer's intention can be studied by researchers, thus helping companies make the move to OOSD. Interestingly, non-US developers expressed a higher level of satisfaction than US developers. Non-US developers, especially European developers, have been using OOAD methods much longer than US developers. Does this explain their higher levels of satisfaction? Or, does something other than longevity of use explain their satisfaction? In addition to the above implications, other more practical issues are raised: (1) Why are automated tools not used frequently, and will the adoption of UML increase the use of tools? (2) What type of projects are experiencing the most bene®ts from OOSD (i.e., complex business systems, simple business systems, complex engineering systems, etc.)? The answer to these questions and many others can be addressed in time. Longitudinal
11
studies would be helpful in monitoring the progress of OOSD along many of the dimensions presented in this research. 4.1. Limitations of the study Two limitations of this study should be noted. First, most surveys suer from the problem of self selection. In this case, it is possible that only those developers and trainees with a positive attitude toward OO responded to the survey. This, obviously, would tend to bias the results. Unfortunately, given the random nature of data collection used in this study, it is impossible to assess the representativeness of the sample. The second limitation involves the lack of a theory to guide the research. As mentioned earlier, this study took an inductive approach to data collection. That is, facts were gathered in hopes of drawing some general conclusions. In this case, the results provided some insight into developing a theory of OOAD attitude, behavior and use. For example, the ®ndings lend themselves nicely to the theory of planned behavior (Ajzen, 1991) which suggests that attitudes impact behaviors (speci®cally, one's attitude about OO may lead one to use/not use OO). Of course, organizational goals must be considered in an investigation of behavior (Hollenbeck and Klein, 1987). 5. Conclusion This study surveyed OO developers and trainees throughout the world. Data concerning respondent backgrounds, training, attitudes, behaviors and OO projects were collected from 160 respondents. Booch, OMT and Jacobson are familiar to, preferred by, and used by, many of the respondents. This ®nding is particularly interesting given that UML has received recent adoption by OMG. UML contains elements of the three aforementioned methods, thus the transition to UML should be smooth for many developers. Current trainees are receiving more training from universities and less self-instruction compared to existing developers. Hopefully, the availability of useful automated tools will increase, which can facilitate training and actual development (this study found that automated tools are used regularly by less than 50% of developers). The adoption of UML should help fuel the growth of automated tools because toolmakers will have a standard notation as a basis for the tools. Overall, results indicate that developers and trainees view OOAD methods favorably and expressed high levels of satisfaction, although dierences did exist between developers and trainees. For example, developers feel less strongly about OOAD's capability to foster reuse of code. Positive attitudes and high levels of satisfaction are favorable indicators of the future of OOSD.
12
R.A. Johnson, B.C. Hardgrave / The Journal of Systems and Software 48 (1999) 5±12
References Ajzen, I., 1991. The theory of planned behavior. Organizational Behavior and Human Decision Processes 50, 179±211. Booch, G., 1994. Object-Oriented Analysis and Design With Applications, 2nd ed. Benjamin/Cummings, Redwood City, CA. Byrd, T.A., Cossick, K.L., Zmud, R.W., 1992. A synthesis of research on requirements analysis and knowledge acquisition techniques. MIS Quarterly 16 (1), 117±138. Davis, F.D., 1989. Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Quarterly 13 (3), 319±340. Douglas, D.E., Hardgrave, B.C., 1997. Object-Oriented Trends: information systems degree programs. AIS Americas Conference on Information Systems, August, 754±755. Fayad, M.E., Tsai, W., 1995. Object-Oriented experiences. Communications of the ACM 38 (10), 51±53. Fayad, M.E., Tsai, W., Fulghum, M.L., 1996. Transition to objectoriented software development. Communications of the ACM 39 (2), 108±121. Garceau, L., Jancura, E., Kneiss, J., 1993. Object-Oriented Analysis and Design: a new approach to systems development. Journal of Systems Management, January, 25±32. Hollenbeck, J., Klein, H., 1987. Goal Commitment and the GoalSetting Process: problems, prospects and proposals for future research. Journal of Applied Psychology 72, 204±211. Jones, N., 1995. Results of a survey on object orientation. The Gartner Group, Research Note T-700-1192, July 12.
Pancake, C.M., 1995. The Promise and the Cost of Object Technology: a ®ve year forecast. Communications of the ACM 38 (10), 33±49. Pressman, R.S., 1992. Software Engineering ± A Practitioner's Approach, 3rd ed. McGraw-Hill, New York, NY. Stickel, E.U., 1993. An experience with CASE tool support for ®nancial product design. Data Base 24 (4), 31±35. Topper, A., 1995. Object-Oriented Development in COBOL, McGraw-Hill, New York, NY. Weinberg, R., Guimaraes, T., Heath, R., 1990. Object-oriented systems development. Journal of Information Systems Management 7 (4), 18±26. Yau, S.S., Tsai, J.J.-P., 1986. A survey of software design techniques. IEEE Transactions on Software Engineering 12 (6), 716±721. Richard A. Johnson is an Assistant Professor in the Computer Information Systems Department at Southwest Missouri State University. He received his Ph.D. in CIS from the University of Arkansas. His current research interests include software development and adoption of software development processes. Bill C. Hardgrave is an Associate Professor in the Computer Information Systems and Quantitative Analysis Department at the University of Arkansas. He received his Ph.D. in MIS from Oklahoma State University. Dr. Hardgrave has published in journals such as Communications of the ACM, Journal of Systems and Software, Information and Software Technology, Journal of Database Management, Computers and Operations Research among others. His current research interests include software development, object-oriented technology and prototyping.