Abstract

1 Research premises and hypothesisWeb application have to be designed to handle a large number of users as one of the advantages of being online is that fact that they are accessible by anyone with an Internet connection. The higher the number of protective users for the web application, the higher the probability of generating downtime [1] or surfacing functionality issues. As web applications grow and attract evermore user traffic their maintenance process needs to handle a vaster array of issues [1] thus growing evermore complex and costly. Maintenance is an important stage in a web application's lifecycle. Maintenance used to be regarded as repair work [2] but it is now increasingly being considered as improvement work [3]. When developing a web application, one might either choose to focus on specifications, functionality and deadlines and deal with maintenance in due time or, thoroughly plan for the maintenance stage even from the start. The need to keep development costs down and meet strict deadlines compels most development teams to opt for the first option. Choosing the first option will help keep development costs down but will eventually generate cascading maintenance costs. Increasing maintenance costs might prove a challenge in the context of ever-increasing efforts aimed at modifying existing code. 50% of the global software population is engaged in modifying existing applications rather than writing new applications [4].If the maintenance stage of an application's life cycle is considered during its development stage and its design and architecture are implemented so that the end product will be easily maintainable the result is labeled as a maintenance-ready web application. By developing the web application with considerable consideration to maintenance its complexity, cost and development time will increase. However, maintenance costs and development time will decrease. So, the main focus of the current research is to determine if building maintenance-ready web applications generates cost savings in maintenance that could compensate for the additional cost generated by additional time invested in building an easily maintainable application. Thus the research hypothesis states that by developing maintenance-ready applications the time needed to implement maintenance tasks decreases and therefore the overall maintenance cost is considerably reduced. According to [ISO/IEC 14764] maintenance is focused on four main objectives:* corrective which entails emergency fixes and routine debugging [5] consisting of reactive modification of a software product performed after delivery to correct discovered problems; corrective maintenance tasks deal with bugs and issues that were missed by the testing team; reducing the number of corrective maintenance task is rather difficult as the testing process is error prone and no matter how much additional effort or resources you invest, it will always have considerable limitations; the major advantage in maintaining web application is that corrective code can be released and made available for all the users instantaneous [6];* adaptive concerning software or hardware system changes [5] which consists of modification of a software product performed after delivery to keep a software product usable in a changed or changing environment; adaptive tasks include changes made to the web application in order to keep it up to date with changes made to the hosting environment, operating system, web server, database engine or supporting technologies; reducing the number of adaptive maintenance tasks is difficult to achieve as its almost impossible to foresee future technological changes and plan for them;* perfective related to user enhancement, improved documentation and computational efficiency [5] which implies modification of a software product after delivery to improve performance or maintainability; perfective maintenance tasks often include changes requested by the web application owner, the marketing department or sales department; perfective maintenance tasks can be reduced by making the web application more customizable;* preventive which tackles modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults; preventive tasks include checking the access logs and the error logs on a regular basis, making code and database backups, monitoring server load and retesting core functionality as often as possible; reducing preventive maintenance tasks is rather hard to accomplish as performing them more frequently often increases their effectiveness. …

Highlights

  • Generates cost savings in maintenance that could compensate for the additional cost generated by additional time invested in building an maintainable application

  • Corrective which entails emergency fixes and routine debugging [5] consisting of reactive modification of a software product performed after delivery to correct discovered problems; corrective maintenance tasks deal with bugs and issues that were missed by the testing team; reducing the number of corrective maintenance task is rather difficult as the testing process is error prone and no matter how much additional effort or resources you invest, it will always have considerable limitations; the major advantage in maintaining web application is that corrective code can be released and made available for all the users instantaneous [6];

  • In the case of the ALFA application the cost increase generated by making the web application maintenance ready was 9%

Read more

Summary

Project Type preventiv Devzy e

Task name column represents the way the task is referred internally by the development team. The task name derives from the email subject in which the task was requested. Client column represents the person to which progress on the task needs to be reported. Project column represents the name of the project the task belongs to. Type column refers to the category of the maintenance task and takes the values corrective, adaptive, perfective and preventive. Duration column represents the number of hours spent on a particular task by the development team. Cost column represents the amount billed for the time consumed on implementing a particular task. The standard rate is $35 per hour

Number of Duration
Conclusion
Findings
Assessing Evidence from Change
Full Text
Paper version not known

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.