Overview Of Erp Maintenance And Upgradation

Published Date: 02 Nov 2017

The ERP system needs regular maintenance in order to function properly. The ERP plan needs revision and updating as per the changing situations in the organization. I have already seen that the ERP system should be reviewed regularly.

The review comments and suggestions should be incorporated into the system. Also the ERP system needs fine-turning as the employees become familiar with it. Once the ERP system has reached a stable state necessary action should be taken to improve the performance.

The ERP tools that are implemented are another area that needs maintenance. The project manager should be in regular contact with the vendors to see whether any upgrades or updates are available. All patches and upgrades should be installed to ensure that the tools are working at their maximum efficiency.

Employees should be given refresher courses on the new functionality that gets added with each new upgrade. The training documentation should also be updated so that it is in sync with the procedures and processes.

3.1.1 Importance of Maintenance

In many cases of human activity, when particular activity involves more than a reasonable amount of cost, people start looking for the problems, which contribute to that cost. Maintenance is no exception to this. When year after year, spending on software maintenance has become increasingly dominant in data processing budgets people have realized that problems in software maintenance need to be identified and resolved. The realization of this fact took place as far back as the 1970s, but software maintenance problem still exist.

3.1.2 Importance of Upgradation

Part of an organization’s investment in an ERP system should include the technical enhancements and business process improvements in future release of the software. Even if you already completed your implementation and made some decisions that may compile the upgrade, successful upgrade are still possible. If a pre-defined and comprehensive methodology is followed, then the chances of a successful upgrade are substantially improved.

Upgrade should be treated like a new project. Because the perception of an ERP upgrade initiative Seems more like a technical maintenance effort then a true system development project. Study showed that annual maintenance costs approximate 25% of initial ERP implementation cost and an upgrade costs as much as 25-33% of the initial ERP implementation.

3.1.3 Maintenance and Upgradation Cost and Challenges

It is clear that maintenance accounts for a huge amount of the overall software budget for an ERP system. It is characterized as an "iceberg" to highlight the enormous mass of potential problems and costs that lies under the surface. Although survey says that maintenance consumes 60% to 80% of the total life cycle costs; these surveys also reports that maintenance costs are largely due to enhancements (upgradation) rather that corrections.

Whenever change is made to a piece of software, it is important that the maintenance gains a complete understanding of the structure, behavior and functionality of the system being modified.

One of the major challenges in the maintenance is to determine the effect of the proposed modification on the rest of the system.

3.1.4 Importance of ERP Maintenance and upgradation Model

Enterprise resource planning (ERP) applications were one of the fastest growing and most profitable areas of the software industry during the late1990s (Sprott D) [28] .Companies worldwide have invested billions of dollars in implementing the systems. The adoption of ERP systems has been the focus of substantial research in recent years. Although early research has covered many aspects of ERP implementation, it has focused mainly on the earlier stages of the ERP lifecycle. As with other types of information systems, many maintenance activities must be carried out, a discussed need to be resolved after an ERP system becomes operational. Examples of such activities include enhancements, user support, and system upgrades.

This research focuses on the post-implementation or maintenance stage of ERP. Prior empirical research has shown that many important issues and problems arise during this stage. This research examines ERP maintenance and compares it with maintenance of traditional systems. Specific research questions are:

(i) What are the maintenance activities pertaining to ERP?

(ii) In what ways are these maintenance activities similar to or different from maintenance of in-house developed software?

(iii) To what extent are the maintenance categories identified previously for in-house software applicable to ERP maintenance?

(iv) Do ERP and in-house software exhibit similar patterns of maintenance activity?

Thus, this study addresses maintenance activities that take place after an ERP system goes live, classifies these activities into meaningful maintenance categories, and analyzes the relative frequency of these maintenance categories.

This study is relevant to both the research and practitioner communities. First, it contributes to knowledge on the post-implementation stage of ERP systems—an area where little research has been conducted. Second, the findings increase our understanding of how maintenance of software packages, particularly large software packages, differs from that of custom-built information systems. Such understanding is important and necessary for effective information systems management. Third, with a good understanding of the patterns of ERP maintenance, planning of ERP maintenance can be better facilitated.

Several suggestions have been made as to how the software maintenance model could be approached. The first approach is to apply a software development life cycle (SDLC) model to construct a model for software maintenance. This kind of model considers software maintenance as another task of software development. As per Basili, software maintenance is a continued development, using the same knowledge, methods and tools used for software development. Another approach to modeling software maintenance is to use the process of software maintenance itself as a starting point for the model concerned.

3.1.5 Introduction to Scope of Maintenance

It is important to understand the scope of the maintenance activities and the context in which software maintainer’s work on a daily basis (Figure 3.1).

There are indeed multiple interfaces in a typical software maintenance organizational context:

Customer and users of software maintenance

Infrastructure and operations department

Developers

Suppliers

Upfront maintenance and help desk

Figure 3.1 Software maintenance context diagram

Taking into account these interfaces, each of which require daily services, the maintenance manager must keep the applications running smoothly, react quickly to restore service when there are production problems, meet or exceed the agreed-upon level of service, and keep the user community confident that they have a dedicated and competent support team at their disposal which is acting within the agreed-upon budget. Key characteristics in the nature and handling of small maintenance requests have been highlighted, for example:

Maintenance requests come in more or less randomly and cannot be accounted for individually in the annual budget-planning process;

Maintenance requests are reviewed and assigned priorities, often at the operational level—most do not require senior management involvement;

The maintenance workload is not managed using project-management techniques, but rather queue-management techniques;

The size and complexity of each small maintenance request are such that it can usually be handled by one or two resources;

The maintenance workload is user-services oriented and application-responsibility oriented; and

Priorities can be shifted around at any time, and maintenance requests of application correction can take priority over other work in progress.

Let us examine each of the typical software maintainer’s interfaces (numbered in Figure 3.1). A first important interface deals with customers and users of the software under maintenance. The customer interface operates between the managers of the two organizations. It typically consists of defining and managing the software maintenance services that are offered. It is done by negotiation or discussions about service scope, objectives and priorities, budgeting/pricing, and user satisfaction-related activities.

It may be documented in a contractual (or internal) agreement called a Service Level Agreement (SLA). Once this agreement is in place, the users can have access to support services from the software maintenance personnel on a daily basis.

The interface with users differs from the customer interface, as it is more operational in nature. This interface (represented by 2 in Figure 3.1) can be located in many different organizations according to different organizational models. The Help-Desk service has sometimes been found to be part of the maintenance organization, sometimes part of the operations organization and sometimes located in another independent product support organization (up-front maintenance organizations. What is currently popular is that Information System/Information Technology (IS/IT) organizations tend to offer a centralized help facility to their users. The problem-reporting activities, conducted through this interface, have been well documented as part of a taxonomy of problem management published by Kajko-Mattsson. To be effective, a mechanized problem- reporting process is used that ensures efficient communications for quick resolution of failures and other support requests. A specific user request, sometimes called a ‘ticket’, will typically circulate between the help-desk, software maintenance, and operations in order to isolate a problem.

A third important maintenance interface deals with the computer operations organization. Computer operations are the custodians of the infrastructure supporting the software applications. They typically handle all of the operation, support, and maintenance issues associated with the workstations, networks, and platforms. They conduct activities such as backups, recovery, and systems administration. The user is rarely aware of, or involved in, the internal exchange of information between software maintainers and operations. This interface also includes less-frequent activities such as the coordination of service recovery after failures or disasters in order to help restore access to services, within agreed-upon SLA terms and conditions.

The fourth interface describes the relationship between software developers and maintainers. Some developers retain the maintenance of the software they develop. In this case the interface between software development and software maintenance does not exist. Many organizations choose to have separate organization for development and maintenance. When this interface exists, the root cause of several maintenance problems can be traced to development, and it is recognized that the maintainers need to be involved and exercise some form of control during pre delivery and transition of the software from development to maintenance. Other services are exchanged across this interface. Many contributions are made by maintainers to concurrently support, and sometimes be involved in, a number of large development projects. The maintainer’s knowledge of the software and data portfolios is of great value to the developers who need to replace or interface with legacy software. For example, some of the key activities of maintenance personnel would be: (a) development of transition strategies to replace existing software; (b) design of temporary or new interfaces to legacy software; (c) verification of business rules or assistance in understanding the data of existing legacy software; and (d) assistance in data migration and the cutover of new software.

The last interface (5 in Figure 3.1) addresses relationships with a growing number of suppliers, outsourcers, and Enterprise Resource Planning (ERP) vendors.

3.1.6 Classifications of ERP Maintenance

Traditionally, any software maintenance has been defined as the modification of a software system after delivery to correct faults, improve performance, or adapt to a changed environment [2]. One of the classifications that are most frequently cited in the maintenance literature was proposed by Lientz and Swanson [20], which classifies maintenance activities into three main categories.

(i) Corrective maintenance: work to correct errors in design, coding, and implementation.

(ii) Adaptive maintenance: work carried out to satisfy changes in the processing or data environment and to meet new user requirements.

(iii) Perfective maintenance: work to enhance processing efficiency, performance, or maintainability and to better meet user requirements.

Various authors have introduced additional categories to this classification or have expanded the number of activities that fall under the above-mentioned categories. Burch and Grupe [7] introduced another category termed ‘preventive maintenance’ which refers to periodic inspection of systems to anticipate problems. The maintenance personnel may detect defects that may not require immediate attention, but, if left uncorrected, could significantly affect either the functioning of the system or the maintainability of the system in the future.

User support is another category proposed by Abran and Nguyenkim [1]. Their research shows that user support takes up 24% of the total time spent on systems maintenance. Hirt and Swanson [14] suggest that users play a more important role in maintenance of ERP systems than traditional systems. While user training is also carried out at the early stages of the implementation process, there is always a need for continuous training as new users and new functionality are added to the system [8].

Although the literature recognizes that IS staff, users, and systems are three main parties concerned with the maintenance of custom-built information systems, with ERP, ‘external parties’ become important as well [14]. External parties such as ERP vendors, third-party vendors, consultants, and external user-organizations are likely to be responsible for some part of the maintenance burden. In contrast to in-house developed information systems, ERP systems are developed by outside vendors. Hence, experience and expertise on the software package reside outside the organization.

The findings from the literature are inconsistent with regard to the amount of effort spent on activities in each maintenance category. According to Barry et al. [5], enhancement effort is the largest category in the software maintenance lifecycle. Results from a study by Abran and Nguyenkim [1] suggest that corrective maintenance is the category where the greatest amount of effort is invested (35%). Zvegintzov [30] compared the findings of three different studies concerning the amount of effort spent on each maintenance category. His results suggest that adaptive maintenance is the largest category. Since maintenance has long been recognized as the most costly activity in the software lifecycle, the frequency, distribution, and trend of activities carried out during software maintenance warrant further research and improved understanding.

The following table shows classification of maintenance tasks into maintenance categories as per Nah,F.F.-H., Faja,S., and Cata,T. (2001) [35],

Maintenance categories

Maintenance tasks

(1) Corrective maintenance

Application of hot packs and/or bug fix

Incorporating system patches sent by ERP vendors in cases where the problems could not be resolved by the IT department

Troubleshooting

Resolving of anomalies reported by users

Import new objects from ERP vendors

Incorporating objects (lines of code) sent by ERP vendors to solve some problems (for examples include new database structures, programs, and new reports)

(2) Adaptive maintenance

Configuration change and verification

Verification after adaptation of hot pack application and change of configurations

Improvement and modification

Customization and modification performed to keep adapting to business changes and to fit new business rules

User management

Managing the access permissions when staff arrived, leaved, or changed positions

Tuning of system interfaces

Tuning of system interfaces to link with other vender ’s software or other organization’s systems

(3) Perfective maintenance

Version upgrade

Justification, planning, and implementation of new versions

Addition and enhancement

Adding or developing the new functions, and/or enhancing or expanding the existing functions.

(4) Preventive maintenance

Routine administration and monitoring

Monitoring average system response times and thresholds, file sizes, tape backups, and error logs

(5)User support

User Training

Training users to use the new system and to fit to the new business process

Help desk

Answering for user questions and inquiries about the system use

(6) External party

Coordination and administration

Coordinating work and relation among ERP vendor, consultants, and external user organizations

Creation of online service system notes

Online query or reporting of problems to the vendor

Tracking vendor’s progress towards resolution of problems reported

3.1.7 Introduction to ERP Maintenance Process and its Activities

Different maintenance activities become more or less prevalent across the software lifecycle. For instance, Burch and Kung [6] identified four distinct stages of software maintenance. They found user support to be most demanding in the first stage of maintenance; repairs are most frequent in the second stage; enhancements are the focus of the third stage; and technology replacement is the main activity in the last stage of maintenance. Kung and Hsu [19] further developed this idea and classification by proposing a software maintenance lifecycle model.

This improved model identifies four distinct stages of software maintenance.

Introduction stage: the first few months after the system go live. Usage of the system is usually low during this stage.

Growth stage: during this stage there is growth in system usage. If usage of the system is mandatory, this means increased familiarity and a better understanding of the available functionality of the system. If the usage of the system is voluntary, this stage includes an increase in the number of users because of positive results from the introduction stage or reduced number of users due to negative results.

Maturity stage: during this stage, major enhancement projects occur that test the limits of the technologies and functionality embedded in the application software.

Decline stage: this is the stage wherein the system reaches the limits of the embedded technologies, and users require software renovation. IS managers must choose between continuing with the current version, upgrading to a new version, or abandoning the software.

3.1.8 Distribution of Maintenance Activities

There are two dimensions for the distribution of maintenance activities. The first dimension concerns the different functional categories. Here we use the three intentions-based types of maintenance identified by Swanson: corrective, adaptive, and perfective maintenance. Corrective maintenance is the correction of errors uncovered in software products. Adaptive maintenance adapts the software to changing environments such as hardware, operating systems, etc. Perfective maintenance involves enhancements in the functionality and the performance of a software system. However, such a typology should be refined to provide a deeper understanding of maintenance allocation, such as by recognizing actual activities, since some activities such as supporting users are hard to fit into the three Swanson categories. The following eight functional categories are collected from other maintenance surveys:

• Enhancements,

• Correcting errors,

• Tuning performance,

• Supporting users,

• Adapting environmental changes,

• Reengineering and rewriting,

• Documentation, and

• Other.

3.1.9 Factors of which affecting the maintainability

An attempt is made here to define maintainability as a manifestation of other lower factors. The model describes software related factors affecting maintainability of software components. Factors affecting maintainability are:

Modularization

Readability

Programming language

Standardization

Level of validation and testing

Complexity

Traceability

3.1.9.1 Modularization

Modularization allows one to decompose a system into functional units, to impose hierarchical ordering on functional usage, to implement data abstractions, and to develop independently useful subsystems. In addition, modularization can be used to isolate machine dependencies, to improve the performance of a software product, or to ease debugging, testing, integration, tuning and modifications of the system. A complex system may be divided into simpler pieces called modules. A system that is composed of modules is called modular. High modularity allows the principle of separation of concerns to be applied in two phases:

when dealing with details of each module in isolation and ignoring details of other modules and

When dealing with the overall characteristics of all modules and their relationships in order to integrate them in a coherent system.

The goals of modularity are as follows:

Decompose a complex system

Compose it from existing modules

Understanding the system in pieces

Continuity of modules

Protection of modules

3.1.9.2 Readability

Readability refers to the degree to which a reader can quickly and easily understand source code. This is important as every program is read again and again during its creation, testing, debugging and maintenance. Readability is affected by the quality and quantity of program documentation. If a program is supported by clear, complete yet concise documentation, the task of understanding the program can be relatively straightforward. Consequently, program maintenance costs tend to be less for well-documented systems than systems supplied with poor or incomplete documentation.

Readability is enhanced by its

Internal documentation

External documentation

Self-documentation refers to the source code which provides meaningful description to increase Comprehensibility and legibility of program enabling user to understand the software functionality, operational environment and all other required attributes. A well-documented program should have its interface and design specifications of components too. Comments refer to supplementary text, table, graphs interspersed with source code. Comments could include goals of program, plans which outline the processing steps for achieving program goals.

External documentation includes:

Program unit notebook

Implementation notes

This external documentation comprises material about source code external to the source code file. It helps readers to understand code, and it provides an implementation tracking mechanism, a mechanism for tracing the fulfillment of requirements and helpful summaries of the testing, debugging and change history of code segments. Program unit notebook is a diary of the life of a program unit, written by the unit's programmer. It contains

A synopsis of the requirements fulfilled by the program unit.

A review of the program unit's design

Discussion of difficult, unusual or tricky aspects of implementation.

Implementation milestones and completion dates for the program unit.

The program unit test plan

The modification history for the program unit.

3.1.9.3 Programming Language

Is the code written in the desired language? A code written in a language where the programmers of an organization are not familiar with results in the difficulty in maintaining the reused code. The language used will also affect the readability of the programmer. A standard language for each domain application is highly recommended as an essential strategy in software development. Programs written in a high-level programming language are usually easier to understand than that in a low-level language. The understandability could enhance other qualities like resolvability and verifiability.

3.1.9.4 Standardization A set of programming standards should be available to act as a guide in code writing to avoid idiosyncrasy among programmers.

Project coding standards specifying internal documentation guide where such guidelines list rules for improving code readability should include naming and formatting conventions, practices and the use of types and control structures, practices and templates for writing comments and targets for code size and comment density. Program conventions, programming language, macros, program formats and documents are standardized for better understandability. The system should be consistent in the use of notations, terminologies and symbols. Code should be indented in a homogeneous manner. The programming standards, guidelines and practices used in writing a program clearly contributes to its readability and hence understandability, therefore, directly affecting modifiability and maintenance.

3.1.9.5 Level of Validation and Testing

Generally, more time and effort spent on design validation and program testing, results in fewer errors in program and consequently decreases maintenance cost resulting from error correction. Maintenance costs due to error correction are governed by the type of error to be repaired. Coding errors are relatively cheap to correct, whereas design errors are much more expensive as they may involve the rewriting of one or more program units. Errors in the requirements specification are normally the most expensive to correct because of the drastic redesign which is usually involved.

3.1.9.6 Complexity

The complexity of software affects its maintainability. It is supposed to reflect to a certain extent, the difficulty in comprehending or maintaining codes. It can also be used as guideline for estimating the number of test cases and so forth. Measuring the complexity of a module involves measuring the control flow of the module, data flow and even data structures used. A module's complexity control flow [8] is a general concept relating to the order in which the various instructions of a program are executed and as such any measure indicative of the number and nature of statements that alter the sequential flow can be used as a measure of complexity.

3.1.9.7 Traceability

Traceability refers to the ability to trace a design representation or actual program components back to requirements. It is manifested in the availability of information linking requirements with corresponding design components and to their corresponding code fragments, providing reverse mapping information.

Traceability is best implemented by implementing cross referencing features such as requirements labeling and function indexing across all software development documents.

3.1.10 Cost of Maintenance and upgradation

A substantial proportion of the resources expended within the Information Technology industry go towards the maintenance of ERP systems. Annual ERP software maintenance cost in the United States has been estimated to be more than $70 billion for ten billion lines of existing code (Sutherland [1995]). At company-level, Nokia Inc. used about $90 million for preventive Y2K-bug corrections (Koskinen [2003]).

Many studies were done to investigate the proportional ERP software maintenance cost, i.e. the cost of new development: maintenance ratio. The total cost of system maintenance is estimated to comprise at least 50% of total life cycle costs (van Vliet [2000]). The proportional maintenance costs range from 49 % for a pharmaceutical company to 75% for an automobile company in some studies according to Takang and Grubb [1996].

In their study of 487 data processing organizations, Lientz and Swanson [1980] reported on the proportion of maintenance effort (time) allocated to each category of maintenance. Corrective maintenance accounted for slightly more than 20% of the total, on the average. Adaptive maintenance accounted for slightly less than 25%. Perfective maintenance accounted for over 50%. In particular, enhancements for users accounted for 42% of the total maintenance effort. Only 5% was spent on preventive maintenance activities.

Most companies perform regular upgrades on their ERP software. As the costs of these upgrading procedures can be quite high it can be difficult to decide when it is absolutely imperative to perform the upgrade. Often businesses decide to wait a while before purchasing upgrade modules. Justifying the cost of upgrading is a difficult task especially in times when business is slow. Of course the need to upgrade your ERP software also depends on the specific upgrades that are offered by ERP module producers. Adding to- or upgrading- the existing ERP software used may mean that divisions of a company such as customer service support or order maintenance might be more streamlined in the future. Adding a new functionality module helps to consolidate ERP platforms.

To estimate the maintenance or upgradation cost, another parameter is needed. The annual change traffic (ACT ) which consists of the proportion of original instructions that undergo a change during a year by addition or modification.

NNL + NML

ACT = ------------------------------------

NOL

where:

NNL = number of new lines, NML = number of modified lines, and

NOL = number of original lines.

the cost in the maintenance stage is given by the product of the development cost and the annual change traffic:

MTOTAL = ACT * MDEV

Where

MMAIN = Total Cost Measured

MDEV = Development Cost Measured

3.2 Overview of Existing Maintenance Model

3.2.1 Overview of differences between packages software and in-house software

Packaged software and in-house software differ in terms of aspects such as the rate of software change, source of costs, risks, control and relationship management, time-to-market, and maintenance responsibility. In response to market competition, packaged software tends to change more frequently through product updates or patches (Hybertson et al., 1997; Carney et al., 2000) than in-house software. Packaged software using-organizations incur costs for both annual maintenance fees payable to the vendor, as well as for typical in-house software corrective, adaptive and enhancement maintenance (Hybertson et al, 1997).

Packaged software entails vendor viability and maintenance support risks (Davis, 1988), as well as software product reliability and fit with user requirements risks (McDermid, 1997). Additionally, packaged software using-organizations must also manage the relationship with the vendor (Oberndorf et al., 2000). On the other hand, developing in-house software may involve development risks, cost/budget risks, system performance risks, and insufficient documentation risks (Davis, 1988). In general, the time-to-market of packaged software is relatively shorter than that of in-house software, and has lower resource costs to the client-organizations (Tran and Liu, 1997; Voas, 1998). Further, packaged software maintenance is shared with, and can be outsourced to the vendor (Hybertson et al., 1997), whereas in-house software is generally entirely maintained internally. Appendix 1 summarizes the main differences between packaged and in-house software as identified from the literature.

3.3 Packages software Maintenance

Reifer et al. (2003) state that packaged (commercial off-the-shelf) software maintenance is relatively im-mature, and that few software lifecycle models address the packaged software maintenance process. Hybertson et al. (1997) point out that packaged software products require different kinds of maintenance activities than those required for a mostly custom system. Carney et al. (2000) agree, suggesting additional difficulties not typically encountered with in-house software systems due to the packaged software maintenance environment not being completely under the client maintainer’s control.

A review of the packaged software literature suggests several maintenance activities unique to the packaged software environment. Packaged software such as ERP is purchased from a vendor, and continuously improved and maintained by the vendor. Hirt and Swanson (2001) note that ERP maintenance requires sharing of the maintenance tasks between the client-organization, the vendor and possibly third-parties (e.g. ASP, consulting firms). The ERP client-organization reports maintenance problems to the vendor (and consultant) and thereafter tracks problem resolution by the vendor (Nah et al., 2001). At a technical level, the implementation of ERP software "patches" and the upgrading to new versions of the package entail a thorough impact analysis to identify the object to be modified and estimate the potential consequences of carrying out the change (Ajila, 1995). This in turn involves making adjustments to previous modifications if they have been overwritten (Shi and Qian, 2001).

Carney et al. (2000) suggest that with packaged software, additional effort is most often required to negotiate with the vendor respective responsibilities for ongoing maintenance, determine the types of changes that can be made to the packaged software, and estimate the costs of retesting and recertifying the software. Additional effort is also required to manage licensing issues (Oberndorf et al., 2000) and contractual issues (Carney et al., 2000).

Further, packaged software upgrades require that client-organizations monitor the future development capability and financial situation of the vendor while continuously evaluating the upgrade options (Reiferet al., 2003). Oberndorf et al. (2000) suggest that the client must also maintain current knowledge of the available and emerging marketplace relevant to the installed packaged software.

The distinctive characteristics of packaged software maintenance activities as discussed above suggest a need to investigate lifecycle-data within the packaged software context. For example, Carney, Hissam and Plakosh (2000), based in the Software Engineering Institute (SEI) at Carnegie Melon University, suggest that the modification of packaged software code is an important decision, requiring that certain specific data items be captured. To that end, we now turn to an investigation of the current IEEE/EIA 12207.0 maintenance-process standard.

3.3.1 ISO/IEC 12207 1995 Maintenance Model

Activities before

Software delivery

Activities after

Software delivery

Activities during

Software disposal

In 1995, the Software Engineering Standards Committee (SESC) of the IEEE Computer Society adopted ISO/IEC 12207 and used it as a basis for life cycle processes within the IEEE Software Engineering Collection.

3.3.2 IEEE/EIA 12207.2-1997 Standards for Software Maintenance Model

Activities before

Software delivery

Activities after

Software delivery

Activities during

Software disposal

The outcome of IEEE and Electronic Industries Association (EIA) adaptation of ISO/IEC 12207, specifically relevant to this study is the IEEE/EIA Guide for information technology – Software Life Cycle Processes – Implementation Considerations or IEEE/EIA 12207.2-1997. It uses the same activity names as in ISO/IEC 12207 (IEEE/EIA 1997). These standards also make reference to other related IEEE standards.

This model is also includes the quantification factors and metrics for measurable maintenance attributes. The primary tasks involved in each activity are summarized in the following table.

Sr. no

Activity

Task

1

Process

Implementation

Develop plans for conducting maintenance activities; establish controls, rules and methods to record and track maintenance requests; outline workflow of a maintenance request; define a maintenance organization; describe the arrangement for resource allocations and performance tracking; define anticipated future maintenance requirements; identify maintenance effort determinants; define software configuration management (SCM) processes for managing modifications to the existing system.

2

Problem and

modification

analysis

Classify maintenance request; assign priority; verify and analyze the impact of the problem; identify alternative solutions; perform preliminary cost and benefit estimation for the modification; approve the selected modification option; carry out a detailed analysis on the modification.

3

Modification

Implementation

Identify the affected module; modify software module documentation; create test cases for the new design, safety and regression testing; detail documentation to be updated; define the test and evaluation criteria; do coding; conduct unit testing; integrate the modified software with the system; perform integration/regression test; carry out risk analysis; implement a test-readiness review to assess preparedness for system and acceptance test; notify user community of the product delivery schedule; develop an archival version of the system for backup; perform installation and training at customer site

4

Maintenance

review and

acceptance

Conduct review(s) with the modification authorizer’s organization to verify the integrity, interoperability test and interface test of the modified system; conduct functional configuration audit; and perform physical configuration audit

5

Migration

Develop, document, and execute a migration plan; notify users of the migration plans; conduct parallel operations of the old and new environment and provide the necessary training; notify the relevant parties of the migration schedule; conduct a post-operation review to assess the impact of the changes to the new environment; archive the data, documentation, logs and code used by or associated with the old environment

6

Software

Retirement

Develop a software replacement policy by taking into consideration the

replacement drivers; develop, document and execute a retirement plan; notify users of the retirement plans and activities; parallel operation of the retiring and new software product, and provide user training; notify those involved the retirement schedule; archive the data, documentation, logs and code used or associated with the retired software product.

3.3.3 Task-Oriented Software Maintenance Model

The maintenance model shown in Fig. 3.2 defines how various tasks in a chain are to be performed in the context of the maintenance objectives and constraints of the maintenance project. However, in his review of the literature, Deraman identified three major common features of the overall software maintenance model. These understand the software, modifying the software, and revalidating the software. Our model encompasses these features. It further shows that the software maintenance process consists of a group of systematic and well-defined tasks which should be performed one after the other in sequence in order to achieve maintenance goals. The software maintenance process takes the existing source code, its documents, and the modification requests as its input and produces a "modified" system as output to meet the user’s "new" requests. Hereafter, we shall use the term "modification" to denote any addition, deletion, alternation or any other maintenance actions. The phases in this model are explained in the following sections.

Figure 3.2 A task-oriented software maintenance modelDesign rationale

Program Comprehension

Decision

Feasibility

Determination

Requirement

Specification

Modification

Requirements analysis

User Maintenance

Request

Localization

Software

Components

Impact

Analysis

Software Metrics

Implementation Plan

Final Plan

Existing Program

Design document

To Implement

Phase

3.3.3.1 Modification Requirements Analysis

In this phase, requests from users already using the system are received. These can be anything like adding new functions, improving the performance of existing functions, migrating the system to other operational platforms due to a change of hardware/operating system, modifying the existing function due to a change of business rules in the organisation, or correcting errors. These requests can be analysed in detail for the existing system in such a way that the entire modification requirements can be well understood both by the user and the staff who are involved in the maintenance project. Changes may also be required to the system itself due to the need for a new operational environment.

3.3.3.2 Feasibility Determination

This is a constraint mechanism in the maintenance process. In this phase the user requirements are examined in terms of technical and economical feasibility. Two important issues are analysed: Is it really important andrelevant to introduce this modification to the existing system? And if it is, how much effort will be required to implement the change? The answers to these two fundamental management issues will determine whether the proposed modification will be introduced or not. Thus cost to benefit ratio is considered as a determinant of the modification process. The user requirements are refined and filtered at this stage. It actually includes estimating cost, staff, and tool availability, and quality requirements. A feedback loop exists between this phase and the previous one. The outcome of this phase is a decision whether to implement all or part of the user’s maintenance requests.

3.3.3.3 Program Comprehension or (Code X-ray)

In this phase, the complete design rationale of the system will need to be well understood by the maintainer. Source code level understanding is necessary to carry out the maintenance work. In a survey on software maintenance managers it was revealed that incompatible design documents for candidate software are the major cause of maintenance problems for 48% of the participating managers. If the design documents cannot be relied on for some reasons, then the source code alone needs to be studied for this purpose. In most cases, there is no historical trail of how the product was actually developed and why design and implementation were done as they were. Understanding the source code involves code reading, program execution, and the use of existing design documents. In such a situation, the assistance of automatic or semi-automatic program understanding tools like reverse engineering or re-engineering can be sought. These tools can be a valuable aid for understanding programs. Automatic design recovery, or code comprehension, is sometimes referred to as ‘code x-ray’.

3.3.3.4 Localization

In this phase, the precise location in the system where the proposed modification to be made is identified. It is important to trace out the exact modification area in the source code. This phase is also referred as ‘spotting’. The technique of program slicing or design recovery can be applied to the candidate code for this purpose. It is important to emphasis that, the program comprehension phase must be done correctly and completely before one can proceed to the localization phase. Otherwise, a wrong candidate module may be found.

3.3.3.5 Impact Analysis

This is an important and difficult phase in software maintenance. Without proper attention to and mastery of the candidate system design, it would be hard to find out how the intended modification would cause side effects in the system, and where these would occur. The consequences of the proposed modifications and the effect of the overall complexity of the system must be examined at this stage, with reference to the candidate system design.

3.3.3.6 Implementation Plan

In this phase, implementation of the intended modification is planned. It includes how to update the existing specification and design documents, and how to re-code and configure the new and modified components of the system. This is the final phase in the maintenance process. When all these phases are completed the usual development process is activated: the maintenance process triggers the requirement analysis phase in the development process, which entire process is split into smaller tasks that can be developed by teams. However, the model in Fig. 3.2.1 only shows how to prepare the maintenance environment, and to define strategy for software maintenance. It actually does not consider the development of the existing software product. Ways in which the implementation details of the maintenance process can be carried out in conjunction with the development process

3.4 Gaps found in IEEE/EIA 12207

Table 3.2 summarizes the gaps identified between the IEEE/EIA 12207 maintenance-process and maintenance-data and our analysis of the ERP packaged software maintenance experience of GSP. According to Grünbacher et al. (2004), in order to enforce quality assurance, the purpose and the desired results of the activities in the process need to be clearly defined. Table 4 contains such a definition of the purpose and the desired results of the additional activities recommended to ensure the IEEE/EIA 12207 standard can accommodate ERP maintenance.

Now we discuss deficiencies in IEEE/EIA Guide for Information Technology – Software Life Cycle Processes – Implementation Considerations (IEEE/EIA 12207.2-1997). These are identified by comparing IEEE/EIA 12207.2-1997 software maintenance preparation; software maintenance procedure and software upgrade stage with our generalize ERP maintenance preparation, and maintenance procedure and upgrade stage respectively. Note that the following discussion has relevance beyond the out specific case, and it supports our propositions.

3.4.1 Software maintenance preparation

Unlike traditional in-house software, ERP is off-the-shelf packaged software that is not only maintained by the ERP-employing organization but also by the vendor. This observation is consistent with the study by Hirt and Swanson (2001). The software vendor plays a significant role in an adopting-organization’s maintenance activities. The vendor introduces maintenance activities (e.g. patches and new versions), and is responsible for continuous research and development of the software. This clearly influences an ERP-using organization’s maintenance and upgrade decisions, strategies and policies. Thus, in planning for ERP maintenance, issues such as the magnitude and frequency of vendor maintenance activity and support, and the projected timing of withdrawal of vendor support for a given version, must be considered. Yet, the issue of vendor maintenance support is not considered in IEEE/EIA 12207.2-1997 standard for ERP maintenance model. Moreover, the maintenance effort determinant for example the system age discussed in the standard may not be applicable in the context of ERP. This is because system age is most likely an unknown factor (or transparent) to the ERP-adopting organizations. In contrast, the number of previous user-enhancements is found to affect the patch maintenance effort (Ng 2001a), yet is not discussed in the standard.

3.4.2 Software maintenance procedure

From our model, I observe that ERP maintenance procedure not only involves maintenance activities originated from internal sources but also external requests from the vendor. Consistent with results reported in (Nah et al. 2001), searching for vendor bug fixes, bug reporting to the vendor, and enquiries for new functionality from the vendor are a few of the main maintenance activities in an ERP environment. An additional activity found in ERP maintenance is reapplying previous modifications (whenever necessary) every time patch maintenance (or upgrade) is implemented. This is because the custom code could be overwritten by a patch (or a new version) if the vendor makes changes to the same software code and incorporates these in the patch or new version. Thus, in order to retain the customized functionality, re-application of the previous modification(s) is required. (Otherwise, no coding is required at all for maintenance support from the vendor or using the vendor’s code.) However, these main activities are not included in the IEEE/EIA 12207.2-1997 standard. Additionally, the standard does not incorporate the maintenance activity of resolving user support requests but merely addresses software change requests. According to more recent software maintenance taxonomies for in-house software (Chapin, 2000) and ERP software (Ng et al., 2002), user support requests are also considered a ERP maintenance activity. The existing standard for software maintenance model needs to reconsider this factor in order to reflect the practical reality that these support requests entail substantial maintenance resources.

3.4.3 Software upgrade

When upgrading an ERP system, the existing system is replaced by a new version readily available from the vendor. The user-organization must study and understand all new versions as they become available in order to decide which to implement. This entails fully assessing new functionality available from each version in order to identify the right version for the organization (note that this implicitly assumes that not all organizations will realize sufficient benefits to implement all new versions); and to prepare for the process of functionality comparison between a new version and the installed version during impact analysis. This research and selection activity is not considered in software migration or software retirement in IEEE/EIA 12207.2-1997. On the contrary, that standard focuses on the effort and procedures needed to develop, re-engineer and/or rewrite the existing system - activities that are typically, relatively less important, if required at all, with the implementation of a new package software version.

The installation of a new version will overwrite the existing system code. As a result, impact analysis between the new version and the installed version must be done, where the installed version, in addition to the ‘vanilla’ vendor code, also includes custom user-enhancements and modifications. This analysis and comparison process, will facilitate deciding which of the previous modifications or user-enhancements to keep (and re-apply to the new version once installed), and which are no longer needed. Here again, the existing standard does not include this activity of deciding whether to retain the installed user-enhancements. This exclusion from the standard is understandable because in-house software, for which the standard caters, is fully tailored to an organization’s business requirements. This is different from the generic ERP application software that most likely does not fit perfectly with the adopting-organization’s culture and business processes.

Stage

Major Activity

Activity

Data item

(Desired result)

Maintenance

Preparation

Manage relationship with vendor and vendor maintenance support

Negotiate software contract, functional requirement and support window

Keep vendor informed of user requirement and expectations

Determine vendor maintenance support

Vendor maintenance support report

Maintenance

Procedure

Monitor and record vendor maintenance support

Monitor parches introduces by the vendor

Download patches

Determine the goal, critically and importance or each patch

Record all patches already and yet to be implemented to the existing system

Estimate patch maintenance costs

Patch progress report

Identify the need for and request vendor maintenance support

Determine whether vendor provides solution for maintenance request.

Report the change request back to vendor

Minimize unnecessary internal maintenance cost

Vendor Support Request

Make decision on whether to really previous modifications and custom developments

Identify modifications that have been overwritten.

Determine customer business processes that are affected but no longer needed after patch implementation.

Analyze impacts and discrepancies of a patch on current modifications.

Make decision whether to reapply previous modification or custom development

Reapply previous modification or custom development during patch implementation

Previous modification and custom development report

Upgrade

Research upgrade option available

Conduct upgrade option search and gather related information for each option

Decide on type of upgrade

Make full assessment of new features or functionality for each option.

Draft plan how a new functionality benefits the organization, and plan for benefit realizations for the new business improvements

Make recommendations for the upgrade release or version

Upgrade option assessment and recommendation report

Conduct functional and non-functional impact analysis between the new upgraded version and the installed version.

Examine the functionality in-use for installed version.

Conduct functional impact analysis between new upgraded version and existing version.

Identify and determine technical requirements and impacts of new upgraded version.

Functional and non-functional impact analysis

Table 3.1 Gaps in the IEEE/EIA 12207 in the context of ERP maintenance

3.5 Conceptual ERP Maintenance and Upgradation Model

3.5.1 Structure of Model

As discussed in the previous sections, the ERP systems maintenance and upgradation model can be classified into three categories; the maintenance preparation stage, maintenance procedure stage and the software upgradation stage. For the successful ERP Maintenance and Upgradation Model adoption, The model hypothesizes the rationale for the relationships among variables based on these combined theoretical backgrounds and incorporates three main dimensions for identifying the truth about the ERP Maintenance and Upgradation Model’s Activities; Maintenance preparation, Maintenance Procedure and Software Upgrade.

The model also considers the ERP Maintenance and Upgradation Model activities based on the reviews on the fundamentals of project management. The activities suggested by several experts in interview. The discussion on maintenance and upgradation model here is focused in managing and executing maintenance preparation, maintenance procedure and software upgrade; the order in which these activities are performed; and the participants in these activities.

3.5.2 Model Activity

A total of Twenty One ERP Maintenance and Upgradation Model related variables are identified in this research. All the variables are extracted from interviews with industry experts. All the maintenance preparation, maintenance procedure and software upgrade related variables are hypothesized to have a positive impact on perceived usefulness directly, and then their relationships will be verified later with the analysis of the following surveys.

Classification of Model Activity

The implementation processes contains first phase as maintenance preparation and transition activities, such as the conception and creation of the maintenance plan, the preparation for handling the problems identified during the development and the follow-up on product configuration management.

In the second phase, the problem and modification analysis process, which is executed once the application has become the responsibility of the maintenance group. The maintenance programmer must analyze each request, confirm it and check its validity, investigate it and propose a solution. Document the request and the solution proposal and finally obtain all the required authorization to apply the modifications.

The process considering the third phase of implementation is the upgradation itself. The process acceptance of the modification, by confirming the modified work with the individual who submitted the request in order to make sure the modification provided a solution. The migration process is exceptional; ad is not part of daily maintenance tasks. If the software must be ported to another platform without any change functionality, this process will be used and a maintenance project team is likely to be assigned to this task.

Figure 3.3 Conceptual ERP Maintenance and Upgradation Model

Software Upgrade Phase

Design Upgrade Methodology

Identify

Influencing Factor

Develop

Upgradation Plan

Assess

Project Risk implications

Identify

Upgrade Implications

Construct

New System & Go Live

Conduct System

Validation and Testing

Maintenance Preparation Phase

Define

Maintenance

Access

User requirements

Estimate

Resource requirement

Dwell

Technical Preparation

Define

Vendor Support

Decide

Maintenance Plan

Define Training Schedule &

Establish Guidelines

Maintenance Procedure Phase

Classify

User Requirement

Define

Maintenance Support

Design Methodology

Estimate

Time and Cost

Conduct

Impact Analysis

Implement the Solution & Verify business solution

Record

Modifications

3.5.2.1 Maintenance Preparation Phase

Maintenance preparation involves planning for software maintenance management, and the maintenance process. In this stage, identify the organizational entities with which maintenance team interacts and the organizational structure in which maintenance operates. In this step, the distinct teams, working groups, required resources and their roles in the change process are identified. Information flows between actors are also being determined.

Define the maintenance

Define maintenance aims and objectives.

Define the impacts and future on the maintenance.

Identify benefits, costs and risks involved in maintenance.

Accessing the user requirements.

Collecting and validating user requirement.

Distinguish the maintenance request from the user support.

Estimate resource requirements.

Verify the available hardware and software resource before the starts maintenance activity.

Identify the number of staff and resource required for maintenance.

Define the maintenance team-size and team members.

Make an agreement with maintenance team members.

Outline the maintenance team’s roles, responsibilities and job specifications.

Define the authority of the maintenance team.

Define the vendor support.

Identify the vendor support required in the maintenance process.

Determine how and up to what extend the vendor will support.

Dwell on Technical preparation.

Solution manager should be installed, working, and current with support packs;

All your hardware and software should be consistent across the landscape (i.e., same service level, same permissions, etc.);

Upgrade your database priory.

Make sure you have enough memory installed prior to maintenance.

Deciding the maintenance plan.

Determine how each of the maintenance requests is serviced.

Establish Software Configuration Management (SCM) plan including configuration identification, configuration control, configuration status, accounting, configuration audits and reviews, interface control and vendor control.

Define a training schedule & Establish a Guidelines

Deciding frequency and type of training to be provided for the maintenance staff and system users.

Provide training to the in-house maintenance staff members.

Determine how each of the maintenance request type is serviced.

Outline the activities involved from the request initiation.

Identify the repetitive activities.

Describing the type of maintenance process support available and how and where to access them.

3.5.2.2 Maintenance Procedure Stage

Maintenance procedure includes the sequence of activities and tasks adopted by an organization in organizing, managing handling, controlling and executing the software maintenance request. In this stage, identify the phase involved in the creation of a new system release. As opposed to the notion of activity, phases produce one or several intermediate or final release products which reviewed according to quality assurance procedures. Identify the generic activities involved in each phase of maintenance activity.

Classify the user request.

Study the root of the problem.

Determine the nature of the request.

Distinguish the maintenance request from the user support.

Estimate maintenance effort.

Obtain approval for the change request for further investigation.

Prioritize the maintenance request.

Define the maintenance support.

Define the vendor support or other support available in the maintenance procedure.

Design the methodology.

Choose the type of strategy used for the maintenance process.

Proposing solution developing solution alternatives and methodology used for the solution.

Estimate the cost and time.

Conduct cost-estimation for the maintenance.

Estimate the maintenance implementation time.

Conduct impact analysis.

Identify the functional area, modules and documentations to be modified.

Design solution for the problem and update the relevant documentation.

Implement the solution & Verify business processes.

Customize the code or applying the code from the vendor as per the maintenance request.

Implement the available best solution.

Devising the test strategy.

Conducting quality, PCA and FCA test.

Record the maintenance.

Update user manuals and user training materials.

3.5.2.3 Software Upgrade Stage

Software upgrade stage comprises the activities and factors to be considered in upgrading and existing software system with a new version. In this phase, deciding the type and volume of the upgrade system. Designing the implementation strategy for the system upgrade. Identify the cost and risk associated wi