Applying project management techniques to web application maintenance
the design and construction of Lockheed Martin's robotic coatings facility
The Internet has highlighted how time compression can provide a competitive weapon for early adopters of web-based technology. Companies who have applied these technologies in concert with carefully developed business plans have discovered new market opportunities and exposed weaknesses in their competition. Traditional “brick and mortar” industries such as financial services, retail, entertainment and media, manufacturing, and pharmaceuticals are using the Internet to provide self-help services, reach new global clients, and reduce delivery time. Founders of failed “dotcom” businesses have educated their respective industries in what to avoid when shaping a web-based business and or application.
The rapid growth of software applications built to exploit the ubiquitous nature of the Internet has produced a pressing, albeit familiar challenge to Information Technology (IT) organizations. The challenge is: given a fixed resource pool, how can 24x7 application support be provided for a global user community while resolving software exceptions and developing enhancements and new releases? These responsibilities and challenges are not novel to IT organizations. Legacy applications such as payroll, time and attendance and inventory tracking, have been used for decades and require both support and enhancement. The difference between legacy and web-based application support is the clock speed of change and the life cycle of the application.
Why is web application maintenance important? Despite slower growth expected for 2001, the Gartner Group predicts B-to-B sales to reach $919 billion. Jones (1994) states that the average U.S. enterprise spends 45% of its total budget on software maintenance and Pigoski (1997) recommends that between 10% and 15% of development costs should be allocated to maintenance on an annual basis.
This paper examines how project management techniques can be used to reduce the turnaround time for bug fixes and enhancement releases and to improve the performance and reliability of web application maintenance.
Web Application Maintenance
The rate of change in both technology and business opportunities in the Internet economy requires an evolutionary design process. With this approach, development steps are iterative. As business needs or technology changes dictate, interim products become available for use as new requirements are gathered and incorporated into the production system. In this life cycle, maintenance is provided in parallel with continuing development and begins when a user first touches the system.
The web-based application support organization often evolves from an initial development project. Technical specialists are transitioned to the support team when their subsystem elements are completed. Since the application is new, the perception is that only minor bug fixes will be required and that support resources do not need to be dedicated to maintenance; they can continue to perform new development. This ad-hoc approach to maintenance usually leads to the following problems:
• Poorly Defined Scope—The range of support requirements and activities are ill defined. Budget and schedule overruns are common.
• lack of Process—Failure to establish a maintenance methodology, processes, and tools inhibit the support organization's ability to respond to changing business and technology needs.
• Deficient Quality Assurance—The support team cannot ensure that the maintained system is reliable and will meet performance expectations.
The main problems caused by an informal approach to delivering web-based application maintenance can be addressed by completing a Maintenance Planning project. Proper planning can mitigate the loss of investment in a web-based application that cannot evolve or scale over time.
Maintenance planning identifies and prepares the resources required to provide ongoing maintenance support for the web-based application. Performing maintenance planning is a project. The ultimate product is the road map by which the support organization will monitor, manage modifications to, and optimize the application. This maintenance plan includes the scope of maintenance to be performed, the processes to be used, the organizational structure of the support team, the environment required to provide support and how maintenance will be transitioned to those resources executing the support functions.
Exhibit 1. Proportion of Maintenance Work
The Scope of Maintenance
As with any project, critical to the success of the ongoing web-based application maintenance initiative is a clearly defined scope. This is the first step in Maintenance Planning. It is an uncommon practice for an on-demand support organization maintaining an evolutionary web-based system to understand the full range of web application maintenance activities. The scope of maintenance to be performed is the basis for future planning and essential to the ongoing success of the support initiative.
A frequent misconception is that web-based application maintenance is only fixing bugs. Lehman's (1980) first law of software evolution, Continuing Change, states that a system needs to change over time in order to be successful. While this may include fixes for program errors, it also includes incorporating user requests, accommodating new business rules, modifying infrastructure to improve performance and upgrading technology platforms.
In 1976, E.B. Swanson identified three different categories of work that are performed in maintenance that apply to web-based applications. They are:
• Corrective—Changes necessitated by actual errors; i.e., program exceptions or bugs.
• Adaptive—Any effort that is initiated because of changes in the environment in which a software application must operate.
• Perfective—All changes including additions, deletions, modifications, extensions, and enhancements made to an application to meet evolving and or expanding user needs.
IEEE, in the 1993 Standard of Software Maintenance added another category called Preventative Maintenance which is the “maintenance performed for the purpose of preventing problems before they occur.”
Historically, the majority of maintenance activities are in the area of Perfective maintenance. Considering the rate of change of web-based applications, this can only hold true today.
Pigoski (1997) defines four levels of scope for software maintenance, they are:
Based on the scope of maintenance activities, processes can be developed to ensure repeatable results. Many of these processes are analogous to the generally accepted practices necessary to manage a project. Required elements include:
• Maintenance methodology (similar to a base development framework) that ensures that only the work required to complete activities are undertaken. The “IEEE Standard for Software Maintenance” (IEE 1993) details an iterative process for managing the delivery of maintenance support (see Exhibit 2).
• Communications and escalation procedures that allow users and other system stakeholders to understand how issue notifications will be processed and what escalation methods (if necessary) are to be used. (Communications Management)
• Change control procedures that define how major and minor changes to the system will be requested, and the approval process for accepting and ultimately implementing the change. (Change Management)
• Risk management process for identifying, analyzing and responding to risks associated with changes to the application. ( Risk Management)
• Establishing metrics by which the performance of the support initiative can be measured and reported upon.
• Test and release procedures that validate and maintain the reliability of the application. (Quality Management)
• Configuration Management to ensure that strict version control of all system elements (including documentation) is maintained. (Integration Management)
There are a wide variety of architectures and technologies available for constructing a web-based application, including three and four-tier architectures, a myriad of application, web, database servers and numerous script languages including JScript, VBScript and Perl. Creating an organizational structure to effectively support many web-based applications requires a fractional resource model. The fractional model utilizes specific competencies of individual team members on an on-demand basis, to satisfy specific support requirements. Planning for the support organization requires that the right compliment of skills is available to meet the scope of maintenance to be provided.
The Maintenance Environment
Creating maintenance processes is useless unless a proper environment for delivery is planned. The maintenance environment is the infrastructure (hardware, software, network communications) that will be used by the team to perform support. A typical environment includes a development environment where system changes can be produced and unit tested, a staging environment where system, regression and user acceptance tests can be run in a safe and secure manner and a physical network that allows releases to be pushed to the production environment. The maintenance environment must also include code and documentation repositories that support the Configuration Management procedures.
Exhibit 2. Software Maintenance Levels of Scope
Exhibit 3. IEEE Maintenance Process
Once the support processes and environment have been created, maintenance activities have to be transitioned to the organization providing support. Several key areas associated with transition are knowledge transfer, training and formal turnover.
The level of knowledge transfer depends on the expertise of the gaining support group and their familiarity with the application to be supported. For determining ongoing maintenance characteristics where the support team is unfamiliar with the application, an assessment on various aspects of the application should be conducted. The assessment should include sessions with the developer or current maintainer of the application. Focus areas for the assessment could include the following:
Internet Business Environment: The goal of the Internet Business Environment assessment is to understand the business environment within which the application exists. The business conditions or business events that may affect support for the application are identified.
Web Application and Development Environment: The goal of the Web Application and Development Environment assessment is to provide an analysis of the application architecture and the practices used to build the application. Application architecture topics include how the application is distributed, what third-party and custom components are used, and whether error management and data access are consistent throughout the application. Development environment topics include whether the application is understandable, adaptable, easy to administer and coded using proper naming conventions.
Information Management: The goal of the Information Management assessment is to analyze the manner in which changes to data and content will be administered and controlled on an ongoing basis. Data Management includes the day-to-day and long-term management of information generated from online order activity and transactions. Content management includes the scheduled and ad-hoc updates of text, links, and graphics used on the site.
Performance and Usability: The goal of the Performance and Usability assessment is to analyze the performance of the application from four distinct perspectives. Functional performance is concerned with how well the application performs to assumed or expected requirements. Usability is concerned with how navigation, search, and content affect the users’ experience. Systems performance is concerned with how well the application design supports volume and quality requirements and the responsiveness and reliability of the application.
Operating Environment: The goal of the Operating Environment assessment is to provide an analysis of the platform on top of which the application resides, as well as the processes in place to manage that environment. This does not include physical assessment of the hardware and operating software. It is intended to identify only platform-related issues that may affect the ongoing support of the application.
In addition to the functional area assessment, functional and performance testing can also be performed on the application.
Using the scope of maintenance to be provided, planning can be performed for addressing the acquisition and training of the human resources required to support the application. Training should be timely and focused on those resources identified for specific activities during support. Examples include database management, content updates, and creative development.
Formal turnover of the application targeted for support should be planned as the final milestone in the Maintenance Planning project. A summary test should be conducted on each process that was created using the established support environment. The most important test should be to take a work request, modify the application, and promote the application change into production. A formal report indicating a state of readiness should be generated and submitted to application stakeholders. Upon acceptance of the report, the support organization begins formal maintenance of the application.
Managing Ongoing Support
Ongoing support begins after the application stakeholders have accepted the Maintenance Plan and results of readiness testing. This entails executing the processes designed for providing maintenance, controlling change requests and reporting on performance of the support team. The key factor in introducing stability and reliability into a web-application support initiative is to communicate effectively with all system stakeholders and plan all work prior to execution.
Since the majority of maintenance activities are in the realm of Perfective maintenance, establishing and maintaining shared expectations with system users is essential. Typically, a user will submit an enhancement request with no feedback on the status of the request. In a dynamic environment, weekly planning sessions to prioritize and plan activities are necessary. This planning session incorporates both technical and business input to ensure that critical changes are always highest in the work queue. This alleviates the perceived unpredictable nature of maintenance. Without these planning sessions, the support team's assigned work can change so frequently that the team is rendered ineffective and it becomes impossible to predict when anything will be completed.
Scheduling recurring releases of the application on a weekly basis has the single biggest impact on preventing the confusion that can result from responding to unplanned work requests. Severity Level 1 issues (system failure) that require immediate resolution will undoubtedly occur. User expectations relating to work requests are established by simply establishing and communicating a release schedule. Release schedules allow the support team to assess the risk associated with system changes and prepare risk management and contingency plans.
The rate of change in both technology and business opportunities in the Internet economy has created a need to perform maintenance in parallel with continuing development. Web-based application support organizations are often required to evolve their efforts from that of an initial application development project to one of support service provider. Often, this role is undertaken with inadequate planning and insufficient time to prepare and enable the resources to provide high levels of support to application stakeholders. By creating a Maintenance Plan before commencing support activities support team is well positioned to provide repeatable and reliable results. Validating and then documenting the state of support readiness will provide the application stakeholders with the information required to make sound business decisions relating to the support of their investment.
IEEE. 1993. IEEE std 1219: Standard for Software Maintenance. Los Alamitos, CA: IEEE Computer Society Press.
Jones, C. 1994. Assessment and Control of Software Risks. Englewood Cliffs, NJ: Prentice Hall.
Lehman, M.M. 1980. On Understanding Laws, Evolution, and Conversation in the Large-Program Life Cycle. The Journal of Systems and Software. 1, 213–21.
Pigoski, T. 1997. Practical Software Maintenance. New York: John Wiley & Sons.
Project Management Institute. 2000. A Guide to the Project Management Body of Knowledge. Newtown Square, PA: Project Management Institute.
Swanson, E.B. 1976. The Dimensions of Maintenance. Proceedings of the Second International Conference on Software Engineering, 492–97.
Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville, Tenn., USA