Distributed Computing Environment Software Maintenance: Problems ...

Proceedings of the 29th Annual Hawaii International Conference on System Sciences - 1996

Distributed Computing Environment Software Maintenance: Problems of Measurement and Research Scott L. Schneberger Ephraim R. McLean Georgia State University

ABSTRACT Historically, the largest single life cycle computer vstem cost has been for maintaining information system software. More recently, the computing world has begun to undergo a significant transformation porn centralized computer architectures to non-centralized or distributed computer architectures. This paper discusses a new area of research on sojiivare maintenance (and development in generat), focusing on the issue of whether and to what extent the emerging technology of distributed computer operating environments directly affects software maintenance. Based on trade journal articles, the issue appears to depend on two diametrics of information system architectures: component simplicity and system complexity. The smaller (but more numerous) the vstem components, the easier they are to deal with individually (i.e., lower software maintenance costs) but the more d+ult it is to deal with the overall system (i.e., higher software maintenance costs). This research was based on a new conceptual model for information systems complexity based on component number and variety, interaction number and variety, and the overall rate of change. By applying this complexity model to distributed computing environments, this research sought empirical data j?om to determine whether the complexity of a distributed computer system has a greater effect on sojtware maintenance than component simplicity, and what the related explanatory factors are. Secondary source data such as accounting cost data on distributed sojtware maintenance was unattainable for reasons discussed in this paper; a$eld study was performed of IS system and application software analysts, designers, programmers, testers, and customer service representatives. The field study indicated (among other things) that the overall complexity of the studied distributed systems overwhelmed the ease-of-use and simplicity of their components--thus increasing the overall diflculty of software maintenance in distributed environments. Implications were discussed for IS managers to lower the cost of distributed computing environment software maintenance costs by adjusting the level of system distribution and minimizing component and system dif$culties. Finally, this paper oglers a perspective on measuring and researching the emerging technology of distributed computing, including recommended areas of specific research needed based on the conclusions and implicationsjrom the authors’ research.

The problem In the 1980s corporate computing began a shift to distributed architectures--collections of autonomous computers interconnected through a communications network (Umar [l]). Variously described as decentralized processing, distributed processing, distributed cooperative processing, network computing, and client/server computing, this movement accelerated with the proliferation of desktop or personal computers in the late 1980s. By 1993, over 400 Information Systems (IS) executives in large U.S. and European companies ranked “client/server” technology as the most important emerging IS technology (McPartlin [2]).

1060-3425/96$5.00 0 1996 IEEE

Perhaps the most often stated benefit from a distributed system such as client/server is the adaptability and scalability of these architectures to meet rapidly changing business information technology needs (Crowley [3]). But there are also indications from trade journals that distributed computing environments are leading to significant problems in such areas as installation, personnel, training, and infrastructure costs. Of the wide range of managerial and technical issuesbusinessesface in adopting distributed architectures, however, one of the most significant may be software maintenance. Software maintenance--correcting coding mistakes, adding or improving software functionality, and perfecting software to make it more maintainable--is particularly crucial to industry. Software maintenance has been

129

Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29) 1060-3425/96 $10.00 © 1996 IEEE


identified repeatedly as the single greatest cost of computer software and systems (Canning 141;Boehm [S]; Lientz and Swanson [6]). U.S. corporations spend over $100 billion annually on software maintenance (Haber [7]) and many have been projected to spend upwards of 90% of their IS budgets on maintenance by 1995 (Mead [S]). There is a perception in some trade journals that distributed systems with smaller, cheaper computers should have correspondingly lower software maintenance costs (Bozman [9] and Ricciuti [lo], for example). Distributed systems should also reduce software maintenance by allowing firms to build the right software the first time and allow greater software re-use (Comaford [I 11). But other authors express an opposite view. Some trade journal authors fear that distributed computing factors should increase software maintenance costs due to the complexity of overall system. Dealing with autonomous, hetergeneous processors--it is reasoned--is much more difficult to program for than one controlling processor. Indeed, a survey of InformationWeek 500 IS executives revealed that 45% believed that client/server computing environments would save their company money, while 32% said they would not (Caldwell [ 121). This paradox has some theoretical bases. Organizational theory, for one, suggests that the costs of planning and managing grow rapidly as the number of active variables increases (Thompson 113])--variables such as the number processors and operating systems. One would expect that maintaining software for a computing environment of multiple processors, operating systems, vendor applications, and network protocols would be more difficult than for a computing environment of one centralized processor, operating system, and application vendor. But by splitting up a centralized system into many smaller components, each component would become simpler to deal with--and therefore could result in reduced software maintenance costs. There is almost no published research on software maintenance in distributed computing environments like client/server. Out of over 1,000 published IS journal articles from 1983-1992, only 23 focused on software maintenance--l4 of which described some form of empirical research on software maintenance. Of those 14, none addressed the issue in terms of distributed computing environments (Schneberger [ 141). Articles continue to describe software maintenance and its impact on businesses in terms of the results of field survey work done during 1977-1980 (Lientz and Swanson [6])--in spite of considerable computing environmental technology changes since then from centralized to distributed architectures. There is a cue from trade journal articles, however. The issue of software maintenance difficulty in distributed environments may revolve around the characteristics of two key diametrics of information system architectures:

and system complexity. As a system (such as a centralized, mainframe system) is divided into smaller and more autonomous components, each component becomes smaller in scope and relatively simpler. At the same time, the complexity of the overall system becomes greater due to the increased number of components and their interactions. In this case, if the simplicity (and therefore, ease of use) of components like PCs and PC operating systems has a greater effect on software maintenance than the overall complexity of the system, then it is reasonableto assumethat overall software maintenance costs will be reduced with increased componentization and simplification. If, on the other hand, the complexity of a system architecture has ascendancy over component simplicity, then software maintenance costs should increase with increasesin system distribution. How to measure system complexity and component simplicity--and their effects--can be difficult, however. There is evidence that IS managers are not measuring and collecting metric data on distributed systems as they do or would for centralized systems (Schneberger [15]). Many managers feel uncertain about what data to collect in a system of autonomous components--especially in a relatively new environment. Distributed system costs are likewise distributed and can be harder to identify. Organizational change often accompanies computer system architectural change, complicating data consistency. Moreover, comparing data across many organizations with widely different distributed computing and organizational architectures can be daunting. This paper addresses previous research in software maintenance and system complexity, discusses the authors’ research on software maintenance in distributed computing environments, and presents implications for further research. component simplicity

Previous research Few people agree on what software maintenance is (Schueidewind [16]; Kim and Westin [17]). Of 23 information systems articles written between 1983 and 1992 and scrutinized for a definition of “software maintenance” (Schneberger [14]), about half used totally unique combinations of terms to classi software maintenance activity. Those who did use the same terms often defined them differently. More than one author on software maintenance has noted how great the problem of varying software maintenance definitions is--and how varying definitions, especially with empirical research, can change the whole nature of what we collectively “know” about software maintenance and how business leaders manage it (Edwards [ 181; Schneidewind [ 161).

130


Proceedings of the 29th Annual Hawaii International Conference on System Sciences -

suggesting computing environments affect programmer productivity (which directly affects software maintenance expenditures) and FPA has been shown to be a fairly accuratepredictor of so&are maintenance efforts (Halstead [22]; McCabe [23]). A model of software maintenance factors including the highlighted operational computing environment is shown in Figure 1.

Swanson ([19]) provided the terms most often found in literature on software maintenance: correction (of faults), adaptation (to changes in the processing environment) and perfection (enhancing performance, efficiency and maintainability). These terms are very close to the official ANSI/IEEE Standard 729 which defines software maintenance as the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a changed environment (Schneidewind [ 16])--in other words, correction, improvement, and adaptation.

Perhaps the first significant published research on software maintenance was in 1969 in a study citing the range of effort that goes into software maintenance as 4060% of total systems and programming resources (Riggs [20]). Given the apparent enormity of those percentages,a munber of studies followed on the magnitude of software maintenance expenditures and some of the factors involved (a synopsis on eight studies up until 1977 is contained in Lientz, Swanson, and Tompkins [Zl]). By the early 199Os, software maintenance research had mainly concentrated on specific relationships between software maintenance expenditures and . characteristics of the software itself (primarily concerning software size, complexity, understandability, age, and language) . the development environment (people productivity, ability, experience, methodology, and organizational management--andtheir tools) . user needs (e.g., enhancements due to changing requirements). In addition to software characteristics, development environment, and user needs, other related research suggests a fourth key factor in software maintenance--the operational or computing environment. There is data from work on function point analysis (FPA), for example,

I996

KEY: ,entity , p= Figure 1. Software maintenance factor model There is ample literature in textbooks, journals, and professional periodicals revealing the range of possible computing components that make up a computing environment--including processors, input and output devices, storage devices, telecommunications devices, and application and system software. In general, common IS textbooks (Davis and Olson [24], for example) categorize these information system components into hardware, software, information, and procedures as shown in Table 1.

Table 1. Information system components HARDWARE

SOFTWARE

INFORMATION

PROCEDURES

processors storage devices input/output devices telecommunications devices

systems applications

systems applications

data preparation operations user

Application software, as noted earlier, can be by itself inherently complex due to its own features and structure with attendant effects on software development. Computing environment complexity is likely also to be a significant factor, most likely independent of application software complexity. Complexity--and its obverse, simplicity--is a word and concept used in everyday life but difficult to define (Bunge

[25]). Complexity is often simply defined as an attribute of the scope and number of different, but related, parts of a whole; the greater the scope or number, the more difficult it is to deal with the system as a whole. But philosophers generally agree that one must also consider the interrelations among the parts, since a group of unrelated and non-interacting parts does not by itself convey complexity. In this sense,complexity is a function not only of the number of system components, but also the respective

131



number of interrelations. The higher the combined munber, the higher the level of complexity (Bunge [25]). Perhaps the earliest writings about computing environment complexity describe it in terms of the number of components and the number of interactions among those components (Langefors [26]). The scope or variety of the components, however, has also been cited as a complexity factor (Welke [27]). In this case, differences among components require a more complex system to accommodate those differences. In the same vein, it is logical that the variety of interactions among the components would also be a factor of complexity. The system complexity characteristics mentioned so far are static; another type of system complexity is dynamic. It stands to reason that the rate of complexity change in time and spacewould be an additional factor (Cramer [28]). The faster the computing environment changes, the harder it is for users, analysts, and programmers to understand the new technology and its operating constraints. Putting these concepts together, computing environment complexity could be characterized by the number and variety of components and their interactions, and their rate of change. This definition is graphically

shown by Figure 2. rate of change computing components

component interactions

1 computing environment complexity

I

-

J

Figure 2. Computing environment complexity

Authors’ research The authors sought to study the characteristics of distributed computing environment complexity (as previously defined) and their effects on software maintenance dif%ulty. Using the model for computing environment complexity shown in Figure 2, four, basic hypotheses were formulated from previous research and theories in related subjects, from anecdotal information published in professional literature, and from logical deduction: * software maintenance is more diEcult the more complex the computing environment

the variety of computing components has a greater effect on software maintenance difliculty than the nwnber of computing components l the variety of computing interactions has a greater effect on software maintenance difticulty than the variety of computing components l the rate of technological change has a greater effect on software maintenance difficulty than either the variety of computing componentsor the variety of interactions. Since software maintenance research in the context of computing environment complexity is a new field of research,the research was exploratory in nature yet specific in view of the conceptual model. Because this topic is so significant economically to organizations in light of the magnitude of software maintenance expenditures and the current technological trend toward distributed computing environments, the authors first sought to collect accounting cost data on software maintenance projects in both centralized and distributed environments for comparison. Nine large corporations--BellSouth, The Home Depot, Georgia-Pacific, Compass America, Household Finance Company, AT&T Network Systems,DMR Canada, SAIC, and MITRE&-were contacted for accessto their data. Most collected software maintenance project data on their centralized software programs, but not one indicated they collected the necessary cost data on their distributed software maintenance projects.l Their reasons for not collecting metric data on distributed system software maintenance projects were: They didn’t know what data to collect. The operations director of one of the large firms in this study did not have a set of performance measuresfor his distributed systemsas he did for his centralized systems; he could not point to data and say whether or not his distributed systemswere meeting his or his company’s operational computing goals or standards. He thought that once the systems “settle down,” they will have a better idea about what to measure. They did not know how to collect the data. Collecting data on a centralized system is relatively easy, one company IS director said--every computation cycle and every transaction is directly managed by one computer which can be monitored. Collecting data on a distributed system with many computers acting autonomously on many networks, however, &ords no such single point of data collection. Furthermore, “How does one collect data on the use of a client l

132


Proceedings of the 29th Annual Hawaii International Conference on System Sciences- 1996 computer when it is not signed-on to a network and is being used independently?” l Moving to distributed system architectures is often accomplished in parallel with organizational realignments and ad hoc groupings of technologists and users. They found it too difficult to collect uniform data over meaningfnl time periods due to shifting responsibilities, maintenance target systems, programmers, and users. “As soon as we collect data on a system, it becomes irrelevant.” . They believed that tools to assist data collection were too immature. “Like the early days of mainframes,” said one director. l They felt there were too few resources left for data collection afler signtficant efforts to build, implement, and maintain distributed systems. Many said implementation expenses were much higher than they anticipated, comments supported by many trade journal articles (Crowley [29], for example). A longitudinal study--comparing the software maintenance costs for a program running in a centralized environment with the costs for maintaining the same (tinctional) program in a distributed environment--might be ideal for researching the concepts and models put forth in this paper if cost data and the necessarycontrol variable data are available. They were not found by the authors. Moreover, the wide range of conceptual definitions for software maintenance mentioned previously was evident in the firms interviewed as possible data sources. Software maintenance to some meant only fixing program errors; to others it meant only perfecting it to make it more maintainable. These conceptual differences further compound scientific comparisons of software maintenance cost data. Given the exploratory nature of the research issue, the authors then turned to field examination through surveys and interviews. An experimental approach was deemed infeasible due to the lack of established theory concerning software maintenance and computing complexity, directly manipulating actual computing environment conditions in possible real world organizations--and controlling intervening variables--was considered impractical. An exploratory examination of individuals conducting or involved with software maintenance, however, would allow for a wider range of independent variables to be considered for developing or extending theories--while strengthening external validity. The field work had two complementary parts. Part I was a cross-sectional field survey, examining the perceptions of software maintainers with regards to software maintenance in light of increasing computing environment complexity. Part II was a cross-sectional field study, interviewing information system analysts, designers, programmers, testers, and operators for qualitative

information to compare and contrast with the Part I survey data. Part I data were collected using a formal survey questionnaire given directly by the researcher or by supervisors to 155 software maintenance professionals in four organizations: IBM Rochester (MN), IBM Austin, BellSouth Information Systems, Atlanta, and AT&T Network Systems, Atlanta. These four companies were chosen for sample breadth for a mostly exploratory study yet would have sufficient technical and managerial depth to provide reliable data. Part II interviews were non-rigid, exploratory interviews seeking perceptions and reasoning in answer to the following fundamental question: Is programming or maintaining software for distributed systems harder or easier than for centralized systems, and why? Discussions moved sequentially from problem and system analysis to system design, development, testing, implementation, and then support. Extensive notes were taken, then comments were characterized and summarized manually. Data from the interviews conducted during the pilot studies were also included with those from Part II. Research data and analysis The summarized effects of increases in distributed computing complexity factors on software maintenance (based on the survey data) are shown in Figure 3. Taking into consideration the system complexity and the environmental component factors, survey respondents indicated through a separate, summarizing survey question that software maintenance for distributed system architectures like client/server is harder overaIl than for centralized system architectures--with a mean score of 1.61 on a scale of -4 (much easier) to +4 (much harder). Univariate analysis was performed on each survey variable, and standard univariate t-tests of individual variables and Hotelling’s multivariate T2 tests on groups of variables were performed for testing null hypotheses. All hypotheses conclusions were statistically supported at a =.05. Qualitative data was analyzed by initially dissecting and re-grouping written interview comments manually into a framework based on the hypotheses. The statements within each group were then compared and contrasted while noting significant inter- and intra-interview trends, reasoning, or experiences. Summarized research conclusions 1. Sofhare for distributed systems appears harder to maintain than for centralized systems. The survey data, as shown in Figure 3, support this conclusion which was also consistently supported by the

133


Proceedings of the 29th Annual Hawaii International Conference on System Sciences - I996 interviews, as well. Virtually all interviewees concluded that maintaining software for distributed systems is more difbcult overall than maintaining software for centralized systems due to greater numbers, variety, and faster rates of change. A point many interviewees made was that distributed systems are not just mainframes “broken up” into connected

pieces--but a new paradigm where computing is accomplished by many autonomous components in an environment that is event-driven rather than simply logic-driven, and therefore more difficult to work with and control.

COMPUTING COMPLEXITY FACTOR

much harder

different

Al. number of processors

1

2

7

A2. variety of processors

1

2

7

A3. number of secondary storage devices

1

7

ii

A4. variety of secondary storage devices

I

A5. number of input/output devices

1

7

1

7

1

7

1

7

A6. variety of input/output devices A7. number of telecommunications A8. variety of telecommunications

devices devices

A8. number of (unique) systems sofhvare

1

AIO. number of transactions

1

All. variety of transactions

1

A12. amount of stored data

1

A13. variety of data storage formak

1

A14. rate of change in technology used

123496

2

7

:::::< 4@5 “’

3

6

7 7

Figure 3. Summarized computing complexity factor survey data The effects on software maintenance of individual components are summarized in Figure 4. COMPUTING

ENVIRONMENT

81. PC vs. mainframe

FACTORS

much less difficnit -3 -2

computers


operating

B3. PC vs. mainframe

programming

systems


packaged


development


interfaces

languages

software tools

dif%ence -1 ml +1

much more difficult +2 +3

-3

-2

-1

a

+1

+2

+3

-3

-2

-1

eo

+1

+2

+3

-3

-2

-1 00

+1

+2

+3

-3

-2

-10

0

+1

+2

+3

-3

-2

-10

0

+1

+2

+3


telecommunications

devices

-3

-2

-1

0

+1

+2

+3


telecommunications

protocols

-3

-2

-1

0

+1

+2

+3

BY. PC vs. mainframe

channels

-3

-2

-1

a

+1

+2

+3

-3

-2

-1

60

Cl

+2

+3

-3

-2

-1

a0

+1

+2

+3

-3

-2

-1

+le

+2

+3

or controllers

BlO.

PC vs. mainframe

databases

Bll.

PC vs. mainframe

input

812.

PC rate of technological

and output change

devices

vs. mainframes

0

Figure 4. Summarized computing environment component survey data 2.

perception by those software maintenance professionals surveyed that increases in those factors make software maintenance more dBicult. Distributed architectures are more complex--with at least greater component

The complexity ofa computing environment appears to affect software maintenance dtJ?culfy. The survey data on system complexity factors showed an explicit

134


Proceedings of the 29th Annual Hawaii International Conference on System Sciences- 1996

3.

4.

5.

6.

numbers or variety if not number and variety of interactions and rate of change--and should, therefore, be more difficult for software maintenance than with centralized architectures. Interviews revealed analysts, programmers, operators, and end-users that felt, at times, overwhelmed by computing environment complexity--and resorting, among other remedies, to increased technical specialization to deal with this complexity. All computing environment complexity factors appear to affect sofiare maintenance d@culty. The survey data supported the proposed complexity factors; the greater the complexity factor, the greater the difficulty maintaining software. Some system complexity factors apparently have greater effects than others. In particular, the computing environment complexity factors that make software maintenance the most difficult, based on the survey data, appear to be the variety of processors, the number (variety) of systems so&are programs, the rate of technological change, the variety of telecommunications protocols, and the variety of data storage formats. This conclusion, too, was supported by the qualitative interviews--especially concerning component variety and the rate of component change. Interviews highlighted programmers who found it difficult to understand widely different platforms, let alone keep up with changing documentation for each platform. Testers told of having to allot twice as much time to set up for testing distributed software and interpreting the results. Customer-support personnel said they were dealing with about four times the number of problem calls (per deployed system) with distributed software than with centralized software. Some individual distributed computing environment factors seem to make sojtware maintenance easier. The top four distributed computing environment factors that made software maintenance the easiest according to survey data were PC development tools, PC graphical interfaces, PC packaged sojlware, and PC programming languages. These four factors were likewise touted as productivity enhancers by those interviewed. Virtually all agreed, moreover, that software maintenance for centralized, mainframe systems would have been much easier if these tools had been available for those computing environments. Distributed architectures appear to be more complex and difficult for sofhare maintenance than centralized architectures even though distributed architectures involve components that may be individually easier to work with. This is a combination of conclusions 1, 3, and 5 above, supporting the argument that there are two competing forces at play--the complexity of a distributed system, and the simplicity of certain

components of a distributed system. The overall difficulty in maintaining a system appears to depend on which factor has supremacy. If system complexity is low and the presence of certain “maintenance-friendly” components high, software maintenance will likely be relatively easier, Under converse conditions, software maintenance will be relatively harder. System architects and designers pointed out that to deal with the complexity of a distributed hardware architecture, the software is “broken up into manageable pieces” and while those pieces “may be smaller individually, they are harder to work with in the aggregate.” For example, they said, programmers are more likely to work in specialized teams that require more in-depth knowledge and more inter-team One director noted that while coordination. programmers are becoming increasingly specialized, project managers are becoming increasingly generalized. Program design appears to be affected by increased complexity of an overall distributed system. “The burden on individual programmers has eased,” designers, tool developers, and programmers said, but “the burden has increased on designers”--due to the difficulty of mentally coping with more and a wider variety of components, with asynchronous computing, with more layers of abstraction, and with increased application modularity. A designer voiced an interesting observation: the more distributed a system is, the smaller the software modules and the easier it is for application software programmers, but the harder it is for systems software programmers. Testing personnel raised other facets of the issue of component simplicity versus system complexity. A tester pointed out that “The higher the level of abstraction, the easier it is to write code, but the harder it is to track down problems.” “We saved a lot of money buying client/server MIPS,” a test director said, “but the configuration problems--getting it all to work together--was really costly.” Moreover, he said, “The equipment may be cheaper per item, but to test all the most likely scenarios, we have to buy a lot more of every brand.” This conflict between system complexity and individual component simplicity also appears to show up with distributed system operational support. “More clients [the user’s computer in a client/server arrangement] give greater flexibility for adapting to user needs,” a system performance technician noted, “but the greater system complexity also increases the cost of managing the system.” Version control is more difficult,

it is harder to distribute

releases, and it is

harder to keep end-users from “freelancing” with client configurations. Performance suffers as well; client 135


Proceedings of the 29th Annual Hawaii International Conference on SystemSciences- 1996 software has to be “tuned” to a “generic” hardware configuration in light of the wide range of different configurations possible--instead of finely tuning software to a single, centralized configuration. This conclusion suggests a new model (represented graphically in Figure 5) for managing and researching distributed computing environment software maintenance As computing (and, by extension, development). environments become more distributed, individual system components become “smaller,” less complex, and easier to manage--but the system as a whole becomes more complex and harder to manage. The paradox of opinions on distributed computing noted in the introduction at the beginning of this paper could be due to a person’s perspective; those focusing on distributed computing pieces see less difficulty and decreasing software maintenance costs, while those thinking of the system as a whole see increasing difftculty and costs. Even though the shapesand slopes of the two curves are conjectural, these “stylized” curves represent the two diametric forces of system component simplicity and overall system complexity.

degree of system

centralized

Figure 6. Implied software maintenance complexity curves Software maintenance

distributed distribution

Figure 5. System complexity versus component simplicity model There is, however, some evidence from the analyzed survey data to suggest caricatured curves more closely resembling those in Figure 6. Here, the effects of easier components (like PC tools) have a lesser effect (shallower slope) on software maintenance difficulty than overall system complexity.

Implications The conclusions expressed above can lead to implications about software maintenance for distributed computing environments as well as for doing research on software maintenance and the emerging technology of distributed computing environments.

136


distributed degree of system distribution

overall system complexity

system component complexity

centralized

software maintenance difficulty

Systems life cycle planning--and particularly software maintenance planning--should take into account a system’s number and variety of computing components and their rate of change. Development and maintenance methodologies--and the tools used with those methodologies (such as CASE)--need to take into account computing environment factors along with the user needs, the characteristics of the software, and the development environment. Research into software maintenance issues should consider the degree to which the operating computing environment is centralized or distributed. Research in software maintenance should consider the proposed model for information systems complexity shown in Figures 1 and 5. The proposed computing environment complexity factors should be included when modeling software maintenance, particularly software maintenance cost models. The top five complexity factors that make software maintenance more difficult --the variety of processors, the number (variety) of systems somare programs, the rate of technological change, the variety of telecommunications protocols, and the variety of data storage formats can be reduced by managerial or technical means. Maximizing PC-based development tools, graphic interfaces, packaged software, and operating systems can also reduce software maintenance difficulty. Since software maintenance has historically been the largest single life cycle cost of an information system, reduced software maintenance costs from optimizing these factors may be substantial. The models proposed in Figures 5 and 6 suggest that managers who want the benefits of distributed computing (such as architectural flexibility and scalability with many “smaller,” cheaper, and readily available components) but who also want to minimize

Proceedings of the 29th Annual Hawaii International Conferenceon System Sciences- 1996 overall system costs have two basic choices: lower the system component and overall system cost curves, and adjust the degree of system distribution. This research suggests specifically that a manager can lower the component difficulty or cost curve through minimizing component change rates and by taking advantage of PC-based development tools, graphical interfaces for applications, operating systems, and packaged software. Managers can likely lower the system difficulty or cost curve through increased system standardization by minimizing component variety-especially processors, system software, telecommunications devices, and data storage formats--and by decreasing the rate of system change. Researching the effects of distributed computing With relatively immature technology, standards, and development methodologies, information system managers attempting to build and field distributed systems are finding it very difficult. As one manager put it, “We’re in a free-fall just trying to get the system up; I don’t know what to expect down the road.” Researching this “road” can be just as difficult but important. The conclusions and implications noted above are based on professional perceptions, but “hard” data is also needed to confirm them. For the reasons noted early in this paper, secondary source data like accounting costs and system usage will likely be problematic with a rapidly changing technology and immature tools. Longitudinal studies will be difficult unless variables are available to standardize centralized and distributed applications. More exploratory field work is needed and can be done--as well as some experimental research--basedon the conclusions and implications stated above. Researcherscould determine the relative effects of the factors of software maintenance (shown in figure 1); for example, compared to the characteristics of the software, does computing environment system complexity have a greater or lesser effect on software maintenance than software complexity? Relationships between distributed software maintenance and other characteristics of software could be investigated--characteristics such as the size or age of an application. Software development and maintenance estimating models and techniques (such as Function Point Analysis) could be re-examined for possible revision based on the effects of the computing environment and system complexity factors, in particular. Observed data is needed to confirm and refine the concluding management model (Figure 5) based on the proposed complexity model. The curves implied in Figure 6 need to be quantified in relation to the degree of distribution for accurate shapes, locations, and slopes. Whether the combined software maintenance difficulty levels are

additive or’ multiplicative should be clarified. Empirical data on managerial and technical attempts to lower the component and system cost curves--and the resulting effects on overall costs--are also needed. Finally, distributed system complexity could be examined in terms of other theory. Chaos theory, for example, could be used to guide research to identify information system “detractors” and “attractors” that affect the stability of distributed architectures--and whether they could be used to manage software maintenance costs. Some authors suggest that one cannot understand the complexity of a system without understanding the rules behind the system (Long and Denning [30]). This research could be extended to study the effects of computing environment complexity in view of organizational and system rules or procedures.

References [l] Umar, Amjad. Distributed Computing. Englewood Cliffs, NJ: Prentice-Hall, 1993. [2] McPartlin, John P. “Worrying the Bough Will Break.” InformationWeek (January 11, 1994): 32. [3] Crowley, Aileen. “Get Out Your Wallet.” PC Week (September 12, 1994): 21, 24. [4] Canning, R. G. (ed.). “That Maintenance Iceberg.” EDPAnalyzer 10 (October 1972): 1-14. [5] Boehm, Barry W. “Software Engineering.” IEEE Transactions on Computers (December 1976): 12261241. [6] Lien& Bennet P. and E. Burton Swanson. Software Maintenance Management. Reading, MA: AddisonWesley, 1980. “Tooling Around the Desktop.” [7] Haber, Lynn. Information Week (July 26, 1993): 42,44. [S] Moad, Jeffrey. “Maintaining the Competitive Edge.” Datamation 36:4 (February 15, 1990): 61-66. [9] Bozman, Jean S. “Grocer Buys Into Open Systems.” Computerworld 27: 12 (March 22, 1993): 57, 59. [lo] Ricciuti, Mike. “PCs Break Into the OLTP Ranks.” Datamation 39:16 (August 15, 1993): 32-36. [ 1 l] Comaford, Christine. “Perceived and Actual Risks of Client/Server.” PC Week (September 12, 1994): 37. “Looking Beyond the Costs.” [ 121Caldwell, Bruce. Information Week (January 3, 1994): 50-56. [13]Thompson, James D. Organizations In Action. New York: McGraw-Hill, 1967. [ 141Schneberger, Scott L. “Software Maintenance: An Update on the Problems and the Issues.” Proceedings of the ACM 31st Annual Southeast Conference, George T. Cracker and Susan T. Dean (eds.). Birmingham, AL. (April 14-16, 1993): 226-234.

137


Proceedings of the 29th Annual Hawaii International Conference on System Sciences- 1996 “Distributed Computing [ 151Schneberger, Scott L. Environments: Effects on Software Maintenance Difficulty. ” Ph.D. diss., Georgia State University, 1995. [16] Schneidewind, Norman F. “The State of Software IEEE Transactions on Software Maintenance. ” Engineering 13:3 (March 1987): 303-310. [17]Kim, Chai and Stu Westin. “Software Maintainability: Perceptions of EDP Professionals.” MIS Quarterly (June 1988): 167-179. [ 181Edwards, Chris. “Information Systems Maintenance: An Integrated Perspective.” MIS Quarterly (December 1984): 237-256. “The Dimensions of [ 191Swanson, E. Burton. Proceedings, 2nd International Maintenance.” Conference on Software Maintenance. San Francisco, October 13-15, 1976.: 492-497. “Computer System Maintenance.” [2O]Riggs, R. Datamation 15 (November 1969): 227-235. [21]Lientz, Bennet P., E. Burton Swanson, and G. E. Tompkins. “Characteristics of Application Software Maintenance. ” Communications of the ACM 2116 (June 1978): 466-471. [22]Halstead, M. H. Elements of Software Science. New York: Elsevier North-Holland. 1977.

[23]McCabe, T. H. “A Complexity Measure.” IEEE Transactions on Softiare Engineering SE-2, 6 (December, 1976): 308-320. [24]Davis, Gordon B. and Margrethe H. Olson. Management Information Systems (2nd ed.). New York: McGraw-Hill, 1985. [25]Bunge, Mario. The Myth of Simplicity. Englewood Cliffs, NJ: Prentice-Hall, 1963. [26 ] Langefors, B. Theoretical Analysis of Information Systems. Sweden: Auerbach, 1973. [27] Welke, Richard. “IS/DSS: DBMS Support for Information Systems Development.” In C.W. Holsapple and A. B. Whinston (eds.), Proceedings of the NATO Advanced Study Institute Estoril, Portugal (June 1-14, 1981). Holland: D. Reidel, 1983. [28]Cramer, F. (translated by D.I. Loewus). Chaos and Order: The Complex Structure of Living Systems. Weinheim: VCH, 1993. [29] Crowley, Aileen. “Master of Many Games.” PC Week (April IO, 1995): 17. [30] Long, Jetfrey G, and Dorothy E. Denning. “UltraStructure: A Design Theory for Complex Systems and Processes.”Communications of the ACM 38: 1 (January, 1995): 103-120.

138
