The maintenance problem of application software: An ... · develops a comprehensive conceptual framework to describe the nature of maintenance activities and to explain the underlying

SOFTWARE MAINTENANCE: RESEARCH AND PRACTICE, VOL. 4, 83-104 (1992)

The Maintenance Problem of Application Software: An Empirical Analysis

GHAZI ALKHATIB Department of ManagementlMIS Group, Kogod College of Business Administration, The American Universiry, 4400 Massachusetts Avenue, NW Washington, DC 20016-8044, U.S.A.

SUMMARY

This paper presents findings from the analysis of data contained in reports and documents maintained by an MIS department of a major pharmaceutical and nutritional manufacturer. To guide data collection, the paper develops a conceptual framework consisting of a descriptive scheme and an explanation model. The descriptive scheme classifies maintenance activities into four categories: adaptive, corrective, perfective, and ongoing support. The explanation model identifies meta-factors that affect maintenance activity. The meta-factors are age, size, programming language, processing environment, structured programming, modularization, analysis and design methodologies, end-user involvement, documentation generation, and maintenance management. The paper analyses three business functions with high, middle, and low average time per repair maintenance project (ATM) measured in person-hours over a period of one year. Each function has several systems, and each system consists of modules. The analysis of available data for all functions maintained shows that maintenance (both repair and update) consumed 49% of data processing (DP) resources. For the three functions, the majority of these resources are devoted to perfective maintenance and corrective maintenance. Guided by the explanation model, several variables belonging to the meta-factors are identified, The following variables have the most significant influence over maintenance: real-time processing, database processing, end-user ongoing support, module size, number of runs and run- time per module, and number of reports and number of copies per function.

KEY WORDS

INTRODUCTION During the past two decades, DP professionals have recognized maintenance of application software as a critical and important activity of the software development life cycle (SDLC). An article in E D P Analyzer marked the first attempt at highlighting the importance of maintenance (Canning, 1972). Since then, several surveys have appeared in the literature. In one survey, maintenance consumed 50% of DP resources (Lientz et a l . , 1978). More recently, an article stated that maintenance may consume up to 80% of DP resources (Glass, 1990). Another survey reported that maintenance consumed 64.6% of DP resources (Doke el al., 1991). These findings may have some support internationally. A survey conducted by the author of 20 major government computer installation in a Middle Eastern country, found that maintenance consumes about 48% of DP resources (Alkhatib, 1985).

In addition, there is the psychological factor. From the author’s interviews with several

Received 25 January I991 Revised 15 Augusr I991

1040-550X/92/020083-22$11 .OO 0 I992 by John Wiley & Sons, Ltd.

84 G . ALKHATIB

D P directors, system analysts, and programmers, it may be concluded that maintenance programmers may experience negative attitudes, such as lack of motivation, and persistent frustration over the possible unfavourable consequences of unsuccessful maintenance. These attitudes may impede productivity and trivialize the usefulness of their activities.

Therefore, increasing the ‘maintainability’ of application software continues to be a major objective for software developers. To accomplish such an objective, the paper develops a comprehensive conceptual framework to describe the nature of maintenance activities and to explain the underlying meta-factors that affect maintenance, from incep- tion to ongoing operation of application software. In addition, the conceptual framework is used as a foundation for empirical analysis. Documents and reports generated by the MIS department (management information services) at a major manufacturer of pharmaceutical and nutritional products contained data for the empirical analysis.

The following sections present the conceptual framework, the empirical analysis, and the conclusions.

THE CONCEPTUAL FRAMEWORK Current research on software maintenance is fragmented in nature. On the conceptual side, articles and books contain expositions of the effects of certain practices on the development and maintenance of software, such as structured analysis and design methodologies, structured programming, and maintenance management. On the empirical side, surveys collect data primarily consisting of program characteristics that affect maintenance and the distribution of maintenance hours among different types of maintenance activities.

No standards yet exist to serve as guidelines for data processing (DP) departments for their data collection on, and documentation of, maintenance activities. At the time of writing, IEEE Working Group P1219 - Software Maintenance Standard, is drafting a set of guidelines that ‘describes the process of managing and executing software maintenance (Standard f u r Software Maintenance, 1991). Therefore, managers and D P professionals need a comprehensive framework to alleviate the impact of maintenance on the DP organization, and to find methods of producing maintainable software. Data collection for empirical analysis may also use such a framework. The next subsection desribes the research methodology of this study, and the following two subsections present the two components of the conceptual framework.

Methodology The research methodology of this study had two major stages: concept formulation and

empirical analysis. In addition, a preliminary stage preceded the first stage as an explana- tory endeavour. In this preliminary stage, the author conducted over 20 interviews with DP managers of large, medium, and small businesses concerning their maintenance activities. Among those companies, interviews with five major corporations had the most significant impact on shaping the direction of this research. The author selected one of those companies as a subject for detailed empirical analysis. The discussions on the conceptual framework incorporate, as appropriate, findings from the other four interviews.

The first stage develops a conceptual framework that consists of a descriptive scheme and an explanation model. This conceptual framework serves as a foundation for the second stage: data collection and empirical analysis.

MAINTENANCE PROBLEM OF APPLICATION SOFTWARE 85

With four dimensions, the descriptive scheme assists in understanding the nature of maintenance activity (MA), who initiates it, and why. On the other hand, the explanation model identifies ten meta-factors that influence MA, such as analysis and design methodologies, structured programming, and maintenance management techniques.

At the empirical stage, one or more specific variables define or measure each of the meta-factors. To explore the nature and type of data and information kept on MAS and functions maintained, the author conducted further detailed interviews with DP managers of the five major companies. In addition, the author reviewed sample documents generated by each D P department. No consistent and coherent set of data and information on their maintenance activities and maintained functions existed. Consequently, performing a cross- company comparative analysis was difficult. To obtain a comparable and consistent set of data for this study, the author selected the single manufacturer with the most comprehensive and extensive set of records and documents kept on maintenance activities and on functions maintained by the DP department. In the selected company, the author conducted further interviews with a member of the technical staff concerning the operations of application software on the company’s IMS DBMS and two functional managers in the DP department. Therefore, the nature of the variables in this study is bounded by existing records and documents kept by the manufacturer under study.

The paper uses two types of data and information:

(1) Aggregate data on all functions maintained that spanned over 10 years. This type of data provides general statistics on the distribution of DP resources measured in person-hours between new development and maintenance.

(2) Data that belong to the three selected functions only. The data in this case spanned a period of five years, 1979-1983, unless otherwise specified. Such data provided the statistics used in the empirical analysis for both the descriptive scheme and explanation model.

The descriptive scheme Several authors have attempted to classify maintenance activities into dimensions. One

study identifies three dimensions as defined below (Swanson, 1976) with specific examples (Martin and McClure, 1983):

(1) Corrective maintenance - basically encompasses the debugging of errors after delivery of the system to end-users. DP professionals perform this maintenance to identify and correct software failures, performance software failures, and implementation failures. Corrections made to programs as a result of failure to reset a switch, failure to test all possible conditions, and failure to process the last record in a file are examples of this dimension.

(2) Adaptive maintenance - dictated by changes in process environment in which the software operates. It is performed to adapt software to changes in the data requirements of the processing environments. Examples for this dimension are: tuning a system to reduce response time, adjusting two programs to make them use the same record structure, and modification of a program to make it use a different terminal.

86 G . ALKHATIB

(3) Perfective maintenance - dictated by end-user’s requests for enhancement and improvement in processing efficiency. It is performed to enhance performance, improve cost-effectiveness, improve processing efficiency, improve maintainability, or respond to end-user requests for changes and additions to the system. Examples for this dimension are: modification of the payroll program to incorporated a new union settlement, addition of a new report in the sales analysis system, and adding facilities required by auditors.

A more detailed set of dimensions is given in another study (Reutter, 1981). This study identifies seven categories: emergency repair, corrective coding, upgrades, changes in external business conditions, growth in software requirements, enhancements by end- users, and support for system utilization.

The two classification schemes are similar, except for the final category of the latter: support for system utilization. An initial review of available documents for the empirical analysis revealed that such a category is kept separate under a heading ‘on-going support’. The last maintenance activity, on going support, is performed to increase effectiveness of communication between D P and end-user personnel, such as explaining system capabilities and planning for future support, measuring performance, and training.

Therefore, the descriptive scheme of this study identifies four dimensions of maintenance: corrective, adaptive, perfective, and ongoing support.

The explanation model Several studies identify program characteristics that affect maintenance, as summarized

in Table 1. Some of the characteristics in Table 1 relate to program descriptions at the micro level, such as number of output fields, number of edits, and switches and flags. Such characteristics may be difficult to define and measure for all programs, especially the large ones. Rather than restrict the explanation model at the conceptual level with micro-program characteristics, this study defines meta-factors that affect maintenance activity (MA). This paper borrows some of the meta-factors from Table 1, while others are based on other literature reviews and surveys.

At the empirical level, each of the meta-factors is transformed into one or more variables, as determined by available data on maintenance activity. Throughout the discussion in this section, variables used by other researchers are mentioned. A later section, titled ‘Discussions of the variables’, includes detailed presentation of the specific variables used in this study. The explanation model identifies 10 meta-factors, treated as independent variables, that affect the single meta-factor of maintenance activity, treated as the dependent variable.

Detailed discussion on the justification and classification of the 11 meta-factors that form the basis and foundation for the model is provided below.

1. Maintenance acriviry ( M A ) : Maintenance activity is affected by several meta-factors with intricate and complex relationships. Data processing (DP) managers may view the problem of maintenance activity from different perspectives, such as the share of MA, in absolute totals or percentages, of all DP resources, expressed in dollar amounts or person- hours, and the person-hours per a unit of measurement such as loo0 lines of code.

Another perspective evolved from the author’s interviews with DP managers of the five


Table 1. Program characteristics found to affect maintenance activity

Program characteristics Lientz Chrysler Chapin“

System age X System size X

Number of output files Number of output fields Number of report control breaks

Number of input fields Number of input edits Number of predefined user reports

Structuredness Modularity Hierarchical organization System documentation Naming conventions Complexity

Application type Programming language Mathematics Difficulty of task

Switches and flags Levels of nested IFs Number of indexes and subscripts Use of numeric literals

Number of input files X

x

Use of database techniques X

“c ’ , controllable by system developedmaintainer, ‘u’, not controllable by system developer/maintainer. Source: Martin and McClure (1983), p. 26.

major companies: the number of hours it takes to perform a maintenance project. Other supporting arguments for this perspective may include:

(a) Effective control and serious consideration of the meta-factors that affect maintenance should reduce the total share of maintenance of total D P resources as well as increase the effectiveness and efficiency when performing maintenance activities. This aspect is critical since lengthy interruptions in the operation of software may create end-user dissatisfaction and a feeling of dissonance towards the use of computers.

(b) Length of time consumed by a maintenance project may have a psychological impact on the DP personnel conducting maintenance activities.

2. Age (A): The logical assumption, as supported by the surveys, is that older programs require more maintenance than younger ones. Programs tend to operate for longer periods of time than expected. In an interview with the author, a senior systems analyst at a major utility company stated that some of the COBOL programs have been in operation for more than 15 years. Programmer and analyst turnover and changing methods of program development adversely affect maintenance activity. Current methods of program develop-

G . ALKHATIB 88

ment, such as re-engineering tools, and fourth generation languages (4GL) may make the retirement of older programs more feasible than before.

3. Size (S): Larger programs perform more functions and as such are more difficult to maintain. Modular design and top-down functional decomposition of program requirements and capabilities may alleviate the negative effect of size on maintenance activity. Following standards of structured programming may also assist in making larger programs easier to maintain. Those methods that affect size are discussed as separate meta-factors. Prior studies measured program size by total lines of code (LOC), number of programs, number of input/output files, and number of user reports.

4. Programming language (L) : Programs may be developed using high-level languages (i.e. COBOL, RPG, and FORTRAN), 4GLs, and application generators. Some high- level languages use statements that can be understood easily be programmers, i.e. COBOL versus RPG. Even though no empirical support yet exists, programs developed using 4GLs are supposed to be easier to maintain (Tinnerello, 1985). The use of application generators increases programmers’ productivity (Ferguson and Flaatten, 1986). This may lead to increasing the effectiveness of maintenance activities.

5 . Processing environment (E) : Two aspects of processing environment are considered: database management systems (DBMS) versus file processing and real-time versus batch processing. As supported by prior research, DBMS capabilities and features permit the development of maintainable software and the efficient use of maintenance time. In an interview with the author, the director of a DP department at a major manufacturing company said that maintenance projects in the department’s UNIVAC DBMS-1100 DBMS environment take on the average 8 person-hours to perform.

6. Analysis and design methodologies ( A D ) : Analysis and design methodologies allow formal treatment of the front-end phase in the software development life-cycle. Two aspects are relevant in this respect: the importance of this front-end phase, and the match of the methodology to the nature of the system under development.

As to the importance of this phase, Boehm reported several examples where lack of proper attention to the front-end phase resulted in disastrous consequences (Boehm, 1981):

In two large common-control systems, the software had to be 67% and 95% rewritten after delivery because of mismatch to user requirements.

Lack of appropriate requirement and early feasibility analysis have led to total cancel- lation of many projects whose successful completion was found to be totally infeasible. Two expensive examples are the $56 million Univac-United Airlines reservation system, and the $217 million Advanced Logistic System.

In another study, he reports that fixing an error discovered after operation normally costs approximately 100% more than the effort that would have been needed to correct the same error if it had been discovered before operation (Boehm, 1981).

Other surveys and studies also support the importance of this front-end phase. A study concluded that 28% of total errors occurred because of incomplete or erroneous design specifications, and an additional 12% resulted from intentional deviation from such specifications (Rubey, 1976). Studies of error analysis by IBM and TRW revealed that the ratio of design to coding errors generally exceeded 60:40 (Boehm, 1976). As to the maintenance problems encountered by DP professionals in 69 organizations, findings of


the survey revealed that among 24 problem categories, quality of system documentation, quality of original program, and adequacy of system design specifications were ranked second, fourth, and eighth, respectively (Lientz et al., 1978).

As to the effect of using a specific analysis and design methodology, a study by IBM found that top-down design improved the productivity of programming by a factor of 1.6 (Yourdon, 1979). This may lead to increasing the productivity of maintenance activity. In an unpublished survey by Yourdon, Inc., covering 32 companies, findings indicate that users of some form of structured analysis and design methodologies averaged 27.1 maintenance hours per 100 lines of code as compared to 72.7 maintenance hours per 100 lines of code for users of other methodologies (De Marco, 1981).

7. Structured Programming (SP): Professor Edsger W. Dijkstra, of the University of Eindhoven, The Netherlands, first introduced the idea of structured programming at the 1969 NATO Conference on Software Engineering (Dijkstra, 1976). Employing structured programming principles generates programs that are relatively easy to change and modify (Yourdon, 1979). In addition, the use of structured programming increases the productivity of programmers by a factor of 1.5-2.0 (Watson and Felix, 1977).

8. Modularization (MD) : In applying modularization, large software development projects are divided into logically related, small, manageable units called modules. The word ‘module’ is generally associated with program implementation in terms of a subroutine or a collection of lines of codes to be executed together. This is a limited view of modularization, however. The process of modularization should start at the design phase by employing some form of top-down or structured chart techniques. A design modules may be a function or a subfunction that later transforms into one or more program modules depending on the level of their detail.

The size of program modules, according to one author, should not exceed 50 executable lines of codes, which will fit in one page of computer printout, or should not exceed an upper limit of memory bytes, such as 1024 bytes (Yourdon, 1975). As to the effect of modularization on maintenance, one survey stated that 89% of users of modular programming reported improved maintainability of their programs (Hoskyns, 1973).

9. Documentation Generation (DG) : The study identifies four schemes of documentation generation and use:

Form of documentation: Graphical documentation is preferable to narrative English-like documentation. Graphics are better at representing specifications and are used as a communication tool with end-users. Structured methodologies are graphics-based and, as such, are used as a means of communicating ideas between DP professionals and end-users (Ross, 1977). Location of documentation: Documentation may be an external, separate compon- ent of programs, or certain levels of documentation may be incorporated in the source of program listings. Since few people read documentation, the challenge facing the IS specialist is to generate information systems that provide their own documentation (Rettig, 1991). The preceding reference includes other interesting ideas concerning documentation. Who uses documentation: Documentation is used by either the programmers and systems analysts, such as systems manuals, or by end-users, such as end-user manuals. Method of generation and update: Manually generated documentation normally

90 G. ALKHATIB

consumes many person-hours. Unless a company has a designated person or organizational unit as librarian, such documentation is not complete and is difficult to maintain and update. With the development of CASE tools, however, documentation is generated automatically throughout the system development life-cycle phases, especially at the front-end analysis and design phase.

As mentioned earlier, the quality of documentation is one of the major problem areas encountered when conducting maintenance activities. Information systems quality also includes good maintenance documentation, states William E. Perry (Maglitta, 1990).

10. End-user involvement (EU) : One article stated that ‘since organization behavior researchers have begun to study the determinants of effective computer use in organizations, a leading theme has been: the overwhelming influence of user participation on successful computer use . . . practioners also seem to stress the primary importance of user involvement’ (De Brabander and Thiers, 1984).

In two interviews, DP managers expressed unexpected attitudes towards end-user participation. Both stated that increased end-user literacy and sophistication may lead to more complex and smarter requests, increasing, in turn, the burden on DP staff. However, since end-user enhancements in the perfective dimension consume 42% of total maintenance resources (Lientz and Swanson, 1980), increased end-user involvement will eventually result in less maintenance during the ongoing operation of software.

11. Maintenance management (MM): MM may involve three relevant aspects: DP organizational form, method of conducting maintenance activities, and behavioural implications of maintenance.

D P organization may be departmentalized, based on one of three dimensions: (1) work type, i.e. systems analysis versus programming, (2) application domain, i.e. application group A versus application group B, and (3) life-cycle phase, i.e. development versus maintenance. A combination of more than one dimension is possible, such as an organization that has, at the first level, departments based on application domain, and within that domain, personnel further divided at the second level based on life-cycle phase. A study concluded that when maintenance receives managerial attention in the application domain-life-cycle or life-cycle-application domain form of DP organization, more resources are available to be used for development than in application domain only or application-work type form of DP organization (Swanson and Beath, 1990).

Other references contain further discussions of industry practices in maintenance management (Canning, 1981, 1978a, 1978b). As to the method of conducting maintenance activities, a form of scheduled maintenance minimizes the effect of interruptions of software operation on the overall organization and maximizes the efficiency in utilizing D P resources (Lindhorst, 1973). Finally, the negtive attitudes to maintenance activity held by DP managers, programmers, and end-users is a critical behavioural issue in DP organizations (Tinnerello, 1983). D P managers must make special efforts to motivate maintenance programmers (Cougar and Colter, 1983), use the right language (Duncan, 1987) and training methods (Duncan, 1989) to build respect for maintenance activities.

MAINTENANCE PROBLEM OF APPLICATION SOITWARE 91

EMPIRICAL ANALYSIS

Company background

History Founded in 1895, the company is a manufacturer of nutritional and pharmaceutical

products. With two divisions, nutritional and pharmaceutical, the company operates as a subsidiary of a holding company. Nationally, the nutritional division has seven regional sales offices, and the pharmaceutical has six. At the time of data collection, the company has 4200 employees with two manufacturing facilities, and contributed 38% of the profits of the parent company.

Organizational structure The director of MIS has two associate directors and a manager under him for applied

systems, information centre, and MIS operations, respectively. Applied Systems (AS), the object of this study, has three managers each responsible for a subset of the functional areas. In addition, AS employs ten programmers, eight systems analysts, and twelve programmer/analysts.

Data capture and classijication Applied Systems maintains the following functions: pharmaceutical marketing, distri-

bution, materials management, engineering, production, quality control, nutritional marketing, finance, personnel, research and development. Every funtion has several systems, and every system has many modules. For example, the production function has six systems, one of which is ‘inventory control’, which has 51 modules.

AS allocates systems and programming person-hours (DP resources) to three different types of projects: major, minor, and maintenance. Major projects include new development requests. Minor projects cover maintenance requests with more than 40 hours of work (maintenance update). Maintenance includes maintenance requests with 40 hours or less (maintenance repair).

Maintenance repair is classified into one of three categories: corrective, perfective, and ongoing support. Only a few projects are classified as adaptive maintenance. To explain this finding, the author provides the following explanations:

(1) Other adaptive maintenance activities may have been conducted but were classified as maintenance update rather than maintenance repair.

(2) Adaptive maintenance may have been conducted in the company’s other applications that run on IBM’s IMS DBMS, while keeping COBOL-oriented troublesome applications, which are the study of this research, with minimum adjustment to the environment. In fact the company does not keep any records on maintenance activities or other types of activities of the applications that run on DBMS. Based on the interviews with the Associate Director of Applied Systems (ADAS) and a member of the technical staff, those applications do not generate any problems and do operate smoothly.

(3) Adaptive maintenance is not conducted in the environment of this company.

G . ALKHATIB 92

Types of reports used The study used the following types of reports and documents:

(1) A summary report by functional areas of total hours for the three types of projects completed, comparing actual to planned hours.

(2) A list of the number of projects and average size of each project according to the three types of projects.

(3) A summary report of total hours by the three project types spent on productive project and non-project activities.

(4) A report that lists functions, systems, and modules with data on number of runs, CPU time, tape and disk access in Kbytes (K = 1024), and cost charges.

( 5 ) A list of modules in every function with date of module addition, latest date of module update, number of lines of codes, language used in module, and name of progammer.

(6) A list of modules with number of output reports and number of copies of each report.

Case selection The author, in cooperation with ADAS, selected three functions out of the total 11

functions. The functions had low, medium, and high average time per repair maintenance projects in person-hours (ATM). ATM is a variable defining and measuring the MA meta- factor. The functions and their respective total number of hours, total projects, and ATMs are as follows: quality assurance (QA), 1065, 108, and 9.9; production (PR), 1475, 98, and 15.1; nutritional marketing (NM), 2628, 123, and 21.4. Throughout the analysis, the paper lists the three functions in the same order of their respective ATMs from low to high: QA, PR, and NM.

General statistics Over a period of 10 years in which aggregate data are available, maintenance, both

update and repair, consumed 49% of DP resources of all functions. The percentage becomes 66 if non-project hours are not included. Figure l(a) delineates percentage distributions of all DP resources in hours (both update and repair) among new development, maintenance, and non-project activities. Part (b) of Figure 1 further divides mainten-

Update Non-project 37

Mantenance 26

New Develop Repar

63 25

a: All Activities b: Maintenance Figure 1. Average percentages of D P resources in person-hour by type of activity


ance hours into repair and update. Data show that maintenance repair consumes about two-thirds of maintenance resources.

The above statistics support the findings of other studies mentioned in the introduction.

The descriptive scheme

Importance of maintenance in the three functions Over a period of five years, the average percentages for maintenance, both repair and

update, for the three functions are higher than the average of 49% reported for all functions? as shown in Figure 2. Therefore? maintenance is a critical activity for each of the selected functions. The total hours spent on all projects, for the three functions (QA, PR, NM) are 9579, 7716, 15888, respectively.

Distribution among maintenance dimensions Since adaptive maintenance did not consume a major part of maintenance, all mainten-

ance hours are distributed among corrective, perfective, and ongoing support. The bar graph in Figure 3 shows the percentages of DP resources spent on the three dimensions by the three functions. For all three functions, the order of the percentages for the three dimensions are perfective, corrective, and ongoing support.

The explanation model Guided by the meta-factors in the model, the author scrutinized available documentation

and reports on maintenance activities and the three functions in search of variables that could represent the meta-factors. Since the three functions are selected from the same organization, the author in cooperation with ADAS decided, before actual data collection started, that the meta-factors could be classified into three groups, as discussed in the following subsections.

o".Illy*u"n"c. PmdvctlO" Nulrltiond M*rkcting

Figure 2. Percentage of maintenance hours of total project hours

94 G . ALKHATIB

Percentages 8 0 ,

60

40

20

n " Oudlty Assunnco Production Nutrltlonal Mktlng

H ~ o ~ o c t i v o El ~ o m c t i v o H Ongoing support

Figure 3. The distribuiion of repair maintenance hours among maintenance dimensions

Neutral meta-factors

effect on ATM. include: The meta-factors that are the same for the same three functions, and as such have no

(1) Maintenance management (MM): Scheduled maintenance is practised. AS structures its organization based on application domain and work type. No programmers are designated as maintenance programmers.

(2) Documentation generation and use (DG): Documentation is generated manually. Both external and internal documentation is included. No individual or organizational unit is assigned as librarian.

(3) Analysis and design methodology (AD): IBM H I P 0 is an optional methodology. The author reviewed sample documentation from all three functions looking for any variation in the degree of adherence to such methodology but could not find any clear differences among the three functions.

(4) Structured programming (SP): Structured programming practices are not strictly enforced. Some restriction on backward branching is followed.

Meta-Factors combining neutrality and expected variation

that may have affected ATM. Common aspects are discussed below. The following meta-factors have overall neutral effect on ATM but with specific variables

(1) Processing environment (E): All functions used traditional file processing. However, modules are written in every function that will interface with the organization's DBMS, an IBM IMS hierarchical database management system.

(2) Programming language (L): COBOL is the main language used in all functions. However, NM has a number of modules that are written in RPG and SAS. Discussion on this meta-factor elaborates on such variation.

(3) End-user involvement (EU): All three functions have a designated individual(s) to act as a liaison between end-user departments and Applied Systems personnel. Other common characteristics included:


(a) Develop a five-year plan for their requirements. (b) Decide priority of projects. (c) Know their area of specialty. (d) Participate in all aspects of systems development activities in general and detailed

design in particular.

Meta-factors with expected variation

Those meta-factors include age, size, and modularization. The following section discusses specific variables related to the latter two groups of

meta-factors.

Discussions of the variables

Tables 2, 3 and 4 list specific variables that are considered for comparative analysis among the three functions. The tables list variables with corresponding meta-factors that have negative, positive, and no impact on ATM, respectively.

Table 2. Meta-factors and associated variables that have negative impact on average time/maint-

enance request (ATM)

Processing environment ( E ) Percentage of modules in accessing tape Total of Kbyte tape/module Average Kbytes of disk access/module Average Kbytes of tape access/module

Programming language (L) Number of SAS modules Number of RPG modules

Age (A) Average age of modules/function

Number of modules per function

Total number of reports/function Percentage of module generating reports Total number of copieslfunction

Size (S)

End-user participation (EU)

Note. A ‘negative’ impact of a particular variable is concluded when the magnitudes of the ATMs of the three functions and the variable statistics are in the same order.

96 G. ALKHATIB

Table 3. Meta-factors and associated variables that have positive impact on average time/maint-

enance request (ATM)

Processing environment ( E ) Percentage of DBMS modules Number of real-time modules Percentage of modules accessing disk Total of Kbytes disklmodule

Percentage of updated modules

Average size of modules Average number of runs per module Average run-time per module

End-user participation (EU) Number of copiedmodule Percentage of end-user ongoing support

Age (A)

Modularization (MD)

Note. A ‘positive impact’ of a particular variable is concluded when the magnitudes of the ATMs of the three functions and the variable statistics are in reverse order.

Table 4. Meta-factors and associated variables that have no impact on average time/maintenance request (ATM)

Size (S) Total number of lines of codes Maintenance hours per 1000 LOC

End-user participation (EU) Number of reports/module Number of copiedreport

Total run-time in minutes Total number of runs

Modularization

Note. A ‘no impact’ of a particular variable is concluded when the order of the magnitudes of the ATMs of the three functions and the variable statistics are not in any specific order.

Average age of all modules. The same number of modules were created in 1976, 1976, and 1974 for QA, PR, and NM, respectively. Modules have been created yearly since


then. For the three functions, Figure 4(a) depicts the average ages for all modules. Here higher ATM is associated with older average age per module, indicating that age negatively impacted ATM.

Percentage of modules updated. Figure 4(b) shows the percentages of modules updated. Since the percentages are not in any specific order in relation to ATM, any conclusion regarding the effect of this variable is inconclusive.

Size (S)

Total number of lines of code (LOC) and number of modules. The total LOC for QA, PR and NM and total number of modules are 238002, 224; 228666, 201; and 413011, 471. Since the magnitude of the above two variables is not in any specific order in relation to ATM, no conclusion could be reached as to the effect of size on ATM. However, the big difference between QA and PR on one side and NM on the other side may suggest a weak positive relationship of size to ATM.

Average maintenance hours per thousand lines of code. This is another statistics that relates total number of maintenance hours to total lines of code. The computed figures are as follows: 3.25, 6.45, and 6.36 for QA, PR, and NM, respectively. As in the previous variable, this may also support a weak positive relationship between size and ATM.

The discussions on the EU meta-factor include other related variables to size, such as total number of copies and reports.

Programming language (L)

Number of modules written in programming languages. COBOL is the main language in all functions. However, NM has 9% of modules written in RPG and 21% of modules written in SAS. RPG, not being a self-documented language, may have contributed to the high ATM in NM. Furthermore, the use of SAS for statistical analysis and as an end-

Average Age % of module of Modules Updates

I ,

(3 (b) ~ u a i ~ t y ~ u u n n w ~r~ductlon NuWlonal Ywkotlng

Figure 4. Age statistics (age in years)

98 G . ALKHATIB

user tool may indicate a higher level of complexity of the NM function and increased sophistication of end-users. This in turn may explain the high ATM for NM.

Processing environment (E)

Number of DBMS module interfaces. File processing is the main processing environment for all functions. However, each function is capable of interfacing to the IMS DBMS through a module interface.

Number of real-time teleprocessing (TP) modules. Each function contains TP modules that control real-time screen interaction with the data of the organization.

Figure 5 (a) and (b) contain statistics on the percentage of the above two types of modules to total number of modules, respectively.

Percentage of modules accessing diskltape. Q A has the highest percentage of modules accessing disk followed by PR and NM. NM has the highest percentage of modules accessing tape followed by QA and PR.

Totallaverage number of Kbytes of disk and tape access. Over a period of two years, QA has the highest total and average per module of Kbytes access to disk, while NM has the highest total and average per module of Kbytes access to tape.

Figure 6 shows disk and tape access statistics. Parts (a) and (b) give average Kbytes of disk and tape access per module. Parts (c) and (d) have total bytes of disk and tape access.

All the above variables support the idea expressed in the literature that the use of DBMS and real-time interactive processing reduce ATM.

Modularization

Module size and number of modules. The average module size in LOC for the three functions are in reverse order of ATM, as shown in Figure 7(a), indicating that larger module sizes are associated with lower ATMs. As to the total number of modules, Figure 7(b) shows that lower ATMs have smaller number of modules. This conclusion may sound contrary to the reported relationship in the literature that the smaller the module size the more maintainable the software is. To explain this finding, a distinction should be made

OA 15.8

QA 20.2

m m 7.3 17.4

a. DBMS b. TP DBYS: Data Base Management System, TP: Teleprocessing Q A Quality Assurance, PR: Production, NM: Nutritional Mrkt.

Figure 5. D B M S interface and TP module statistics in percentages


Average of Average of Disk Access Tape Access

(0) (b) Total Disk Total Tape

Access ACCeSS

(a (d) nutmftlona~ ua~ketlnp oual~ty*uunnu Pmductlon

Figure 6 . Diskltape access statistics (averages per module in bytes, totals in 1000 bytes)

Module Size in LOC

I

Number of Modules

. .

~uat t ty~uurance Praductron Nutrttional Yarketlng

Figure 7. Modularization statistics (LOC: lines of code)

between the two definitions of the word ‘module’. The literature defines a ‘module’ as a segment of a program, as presented in the conceptual discussions. While in AS, the word ‘module’ is a program by itself with a specific objective. Examples of modules in QA are ‘printing item descriptions by number’, and ‘sorting by item descriptions’. Those modules may be further divided into submodules. No data or standards is available on the decornpo- sition of modules into program submodules.

100 G. ALKHATIB

Regardless of module composition in AS, this finding is important in the context of this

Run-time and number of run statistics. Figure 8 shows run-time and number of run statistics; parts (a) and (b) show totals and parts (c) and (d) show averages, for the two variables respectively. Data was collected over two years. Average run-time in minutes and average number of runs per module are both inversely related to ATM. This relationship indicates that functions with modules running for longer times and more frequently have lower ATMs.

Further analysis of the relationships among the statistics of modularization, as depicted in Figure 7, to the run-time and number of runs, as depicted in Figure 8, reveals that functions with fewer modules, with larger sizes, and with more frequent runs, and with longer run-time will lower ATM.

-study and is related to other variables in the ensuing discussions.

End-user involvement

Total number of reportsltotal number of copies. Total number of reports and total number of copies may be used as a measure of end-user association with the functions and size. Other related statistics are computed based on the above two variables. Figure 9 shows statistics pertinent to output reports and copies: totals in parts (a) and (b), averages in parts (c) and (d), and copies per report and percentage of modules with reports in parts ( e ) and (f).

The positive relationships between the number of reports and number of copies and

Total Runtime

'-

Total Runs

'-

(a) Runtime

Per Module

(b) Runs

Per Module

Figure 8. Run-time and number of runs statistics (run-time in minutes, two-year period)


Total Report.

-'-I 1

(*) % of Yodulr Wlth Report.

"7 ."L - -

Idl . . Quality Assurance Production Nutritional Marketing

Figure 9. Number of reports and copies statistics

1 oa

80

60

4c

2c

C ~usi i ty Assurance Production Nutrltional Marketing

Figure 10. Percentage of end-user support of total on-going support

Tabl

e 5

.Non

-par

amet

ric s

tatis

tics

usin

g th

e K

enda

ll co

effic

ient

of

conc

orda

nce

Ran

king

s V

alue

s

Var

iabl

es l

ist

QA

PR

N

M

QA

PR

N

M

1. A

vera

ge t

ime

of m

aint

enan

ce/p

roje

ct

2. A

vera

ge h

ours

per

100

0 LO

C r

epai

r m

aint

enan

ce

3. A

vera

ge a

ge p

er m

odul

e 4.

Per

cent

age

of u

pdat

ed m

odul

es

5. N

umbe

r of

lin

es o

f co

de in

100

0s

6. N

umbe

r of

mod

ules

7.

Ave

rage

siz

e of

mod

ules

8.

Num

ber

of D

BMS

inte

rfac

e m

odul

es

9. N

umbe

r of

TP

mod

ules

10

. A

vera

ge K

byte

s of

dis

k ac

cess

/mod

ule

11.

Ave

rage

Kby

tes

of t

ape

acce

ss/m

odul

e 12

. R

un-t

imeh

odul

e in

min

utes

13

. To

tal

num

ber

of c

opie

s 14

. Pe

rcen

tage

of

end-

user

ong

oing

sup

port

15. P

erce

ntag

e of

mod

ules

in S

AS

and

RPG

9.9

3.3

4.1

49

328

224

1464

43

56

10

38

44

34

388 94 0

15.3

6.

5 4.

3 57

22

9 20

1 11

38

16

40

369 8 11

46

4 74 0

24.1

6.

4 7.

2 39

41

3 47

1

877 23

19

108 52 6

1564

66

30

12

3

13

2

12

3

23

1

21

3

21

3

12

3

13

2

12

3

12

3

21

3

12

3

12

3

12

3

11

3

Sum

of

the

rank

ings

Su

m o

f R

s - A

vera

ge o

f R

s Sq

uare

of

devi

atio

ns o

f R

s fr

om a

vera

ge

The

Ken

dall

coef

ficie

nt o

f co

ncor

danc

e

21

29

39

Tota

l =

89

-8.6

7 -0

.67

9.33

75

.17

0.45

87

.05

s =

162

.67

w =

.3

62

Not

es.

Oth

er r

elat

ed v

aria

bles

bas

ed o

n di

skita

pe a

cces

s, r

un-ti

me,

and

num

ber

of r

epor

ts w

ere

excl

uded

bec

ause

the

y ha

ve s

imila

r ra

nkin

g to

th

ose

incl

uded

in

the

com

puta

tions

. Q

A:

qual

ity a

ssur

ance

; PR

: pro

duct

ion;

NM

: nu

tritio

nal

mar

ketin

g; K

=

1024

.


ATM indicate that functions with smaller number of output reports is associated with lower ATM. Also, the above two variables, when used as a measure of size, reinforce the earlier weak findings of the negative impact of size on ATM. In addition, these two variables may be related to module size (Figure 7(a)), number of modules generating reports (Figure 9(f)), and number of copies per module (Figure 9(a)), indicating that ‘functions’ with larger ‘module’ sizes with more users sharing output from these modules have lower ATMs.

End-user on-going support. The ongoing support maintenance is further classified into end-user support and other types of support. The total number of ongoing support hours for the three functions are as follows: QA, 843; PR, 823; and NM, 601. Figure 10 shows percentages of end-user support to total ongoing support. Such percentages are in reverse order of ATM, indicating that increased end-user ongoing support would reduce ATM.

CONCLUSIONS The analysis of available data showed that maintenance consumed about half of DP resources. The analysis did not find a significant effect of adaptive maintenance. The other three dimensions are ranked as follows: perfective, corrective, and ongoing support. Several variables belonging to a subset of the meta-factors are found to most significantly affect maintenance: real-time processing, database processing, end-user ongoing support, module size, output reports, and number of runs and run-time.

Furthermore, non-parametric statistics to measure the degree of agreement among the variables ranking of the functions is conducted by computing Kendall coefficient of concordance on selected variables (Siegel, 1956). The variables are used to rank the three functions according to their relationship to ATM. The sums of the rankings are in the same order of their respective ATM. The results indicate that the null hypothesis that the rankings are independent is to be rejected, and that the rankings are dependent. The null hypothesis would have been rejected at the 0.01 level of significance if the value of s was equal to or less than 132, as opposed to the computed value of 162.67. Therefore the rankings of the variables for the three functions are consistent and in agreement. Table 5 contains listing of the variables, values, rankings, and results of computations.

Finally, a word of caution is due. The conclusions of the paper are not to be generalized. They are to be interpreted within the limitations of the case selection, data collection, and statistical methods employed by the study.

References Alkhatib, Ghazi I. (1985) ‘Survey and evaluation of the utilization of computer and office automation

equipment in government institutions in Saudi Arabia’, in the Proceedings of the Symposium of Managing and Organizing Information of Modern Technology, Riyadh, Saudi Arabia, March

Boehm, Barry W. (1981) Software Engineering Economics, Prentice-Hall Inc., Englewood Cliffs,

Boehm, Barry W. (1976) Software engineering, IEEE Transactions on Computers, 12, 1226-1241. Canning, Richard G. (1981) ‘Easing the software maintenance burden’, EDP Analyzer, 8, 15. Canning, Richard G. (1978a) ‘Progress in software engineering, Part 1’, EDP Analyzer, 2 , 13. Canning, Richard G. (1978b) ‘Progress in software engineering, Part II’, EDP Analyzer, 3, 13. Canning, Richard, G. (1972) ‘The maintenance iceberg’, EDP Analyzer, 10, 14.

1986, 37-88.

NJ, 767.

104 G . ALKHATIB

Cougar, J. Daniel and Colter, Me1 (1983) Motivation of Maintenance Programmers, Colorado Springs: CYSYS Inc., Box 7345, Colorado 80933.

De Brabander, B. and Thiers, G. (1984) ‘Successful information system development in relation to situational factors which affect effective communication between MIS users and EDP specialists’, Management Science, 2, 137-155.

De Marco, Tom (1981) Yourdon Project Survey, Yourdon Inc., New York, 32. An unpublished survey available from Yourdon Inc.

Dijkstra, E. (1976) ‘Structured programming’, in Software Engineering Concepts and Techniques, J. M. Buston, P. Naur, and B. Randell (Eds.), Van Nostrand Reinhold, New York, 306.

Doke, E. Reed and Swanson, E. Neil (1991) ‘Software maintenance revisited: a product life cycle perspective’, Information Executive, 1, 8-11.

Duncan, Mark (1989) ‘Give maintenance some respect’, Computerworld, (20 November), 132. Duncan, Mark (1987) ‘Use the right language to boost perception of maintenance’, Computerworld,

Ferguson, Glover, T. and Per 0. Flaatten (1986) ‘Application generators: tools can give MIS a

Glass, Robert L. (1990) ‘Help! My software maintenance is out of control’. Computerworld, (12

Hoskyns Systems Research, Inc. (1973) Implications of Using Modular Programming, Article No.

Lientz, B. P., Swanson, E. B. and Tompkins, G . E. (1978) ‘Characteristics of application software

Lientz, B. P. and Swanson, E. B. (1980) Software Maintenance Management, Addison-Wesley

Lindhorst, W. Mike (1973) ‘Scheduled maintenance of application software’, Datamation, 5, 71-83. Martin, J. and McClure, C. (1983) Software Maintenance, Prentice-Hall Inc., Englewood Cliffs,

Maglitta, Joseph (1990) ‘Interview: quality through documentation’, Computerworld, (12 February),

Rettig, Marc (1991) ‘Nobody reads documentation’, Communication of the A C M , 7 , 19-24. Reutter, John (1981) ‘Maintenance is a management problem and a programmer’s opportunity’,

Proceedings, AFIPS Conference on Computers, AFIPS Press, Montvale, NJ, 343-347. Ross, Douglas T. (1977) ‘Structured analysis (SA): a language for communicating ideas’, IEEE

Transactions on Software Engineering, 1, 6 3 4 . Rubey, Raymond, J. (1976) ‘Quantitative aspects of software validation’, Proceedings of the Second

International Conference on Software Engineering, IEEE Computer Society Press, Los Alamitos, CA, 249.

(9 February), 71.

needed productivity boost’, Computerworld, (4 August), 49-51.

February), 87-91.

1, New York: John Hoskyns and Co., Ltd.

maintenance’, Communications of the A C M , 6 , 466-471.

Publishing Co., Reading, MA, 214.

472.

YO.

Siegel, Sidney, (1956) Nonparametric Statistics, McGraw-Hill Book Company, New York, 301. Standard for Software Maintenance (1991). IEEE Computer Society (April), 15. An unpublished

unapproved draft available from IEEE Computer Society. Swanson, E. Burton (1976) ‘The dimensions of maintenance’, Proceedings of the Second International

Conference on Software Engineering, IEEE Computer Society Press, Los Alamitos, CA, 492497. Swanson, E. Burton and Beath, Cynthia Mathis (1990) ‘Departmentalization in software develop-

ment and maintenance’, Communications of the A C M , 6, 6.58-667. Tinnerello, Paul C. (1985) ‘Software maintenance in fourth generation language environments’,

Data Management, 3 , 3 W . Tinnerello, Paul C. (1983) ‘Improving software maintenance attitudes’. A FIPS, Proceedings of the

National Computer Conference, AFIPS Press, Montvale, NJ, 107-112. Walston, C. E. and Felix, C. P. (1977) ‘A method of programming measurement and estimation’,

IBM Systems Journal, 1, 54-73. Yourdon, E. (1979) Managing the Structured Techniques. Yourdon Inc., New York, 266. Yourdon, E. (1975) Techniques of Program Structure and Design, Prentice-Hall Inc., Englewood

Cliffs, NJ, 364.