Thirty years ago, software maintenance was characterized as an "iceberg”. We hope that what was immediately visible is all there is to it, but we know that an enormous mass of potential problems and cost lies under the surface [6]. Research industry presently spends in excess of $15 bn per annum on data maintenance, including software, services, consulting and so forth. Nor is it recognized as an independent restraint within data management. Indeed, the tasks required in data maintenance are typically treated as being just a part of what you need to do when maintaining, implementing or upgrading application software. There are several issues involved in software maintenance in a software industry and this research paper is related to conducting an analytical study of the challenges involved in it.
1. Introduction : The challenges involved in maintaining software over a period of time is known to software developers in prior. Procedures such as software migration, reformation and reengineering all entail source code alteration. They depend largely on study and understanding of the multifaceted system architecture and connections that exemplify both legacy and recent software systems. It is broadly acknowledged that tools that carry software investigation and upholding responsibilities would go extensive way towards tackling the restraints that software developers and maintainers toil with on a day-to-day basis. Nevertheless, notwithstanding a profusion of tools, not several are used by developers and very small number is considered indispensable for a meticulous growth or maintenance undertaking. This research paper examines several design concerns linked to the expansion and implementation of tools to conduct software investigation and preservation.
In other words, software maintenance is defined as the “modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a changed environment”. This definition can be further elaborated to an extent of several issues related to software reengineering.
Software companies, especially in the US and Europe, have suffered the brunt of a destabilized economy and a stricter regulatory environment has been required over there. As of now, as they are more aware of the threats that proved futile for their projects as well as their market reputation, capital reserves and even to their survival; they are now taking up new endeavors more carefully than ever before. A lot of those that endured the decline still countenance gloomy circumstances in the upcoming years, as they are persistently suffering losses on mortgage and securities and resist acting in accordance with novel investment policies. Long-term possibility relies on their capacity to devote prudently in projects, convene to regulatory objectives and evade the expensive and public disappointment that passed along to lots of their counterparts.
Significance of software maintenance: Software maintenance is the most expensive part in the software development lifecycle. But with the advancement in the technology, it has become the more time consuming task for the developers as of now.
The monetary shock of software upholding is also more noteworthy than ever, restating the statement made by Chikofsky and Cross that [1]: “Any activity that even minimally reduces maintenance efforts would yield significant cost savings in the software industry”. It has also been seen that not a lot of software investigation and maintenance tools are used in Industry. Ulrich [2] relates this to deficiency of knowledge of existing tools and unwillingness to transform on the part of software developers and maintainers. This involves a lot of issues but majorly there are two important causes related to low level of maintenance in accordance to tool utilization. They can be studied under as: Dearth of policies for utilization and deficiency of tool incorporation.
The earlier relates to the detail that very modest experimental data of software maintenance activities are considered to be present. Tools offer services, but how each suits in the by and large maintenance procedure has not yet been successfully considered. The establishment of proven and effective procedures and guide for maintenance of software during its alteration mode is based on realistic scenario and thus it relates to symbolizing vital rudiments for implementing software development. As of now only a small amount of practical facts are available which relates to the actuality that software incorporation is important.
According to Lethbridge and Singer [3], lack of tool incorporation and incongruity was the foremost grievance about tools articulated by software maintainers. The same rationale has been cited as the major obstacle to the progression of a consistent reverse engineering upbringing. Software developers would benefit from an incorporated milieu that permits a composition of services to influence the study offered by self-regulating maintenance paraphernalia.
Another vital encouragement for debate was the realism of alteration in software systems. In this perspective, the phrase preservation relates to growth and a persistence of expansion activities. From this viewpoint, tools need to bear on hand software relics in a manner that take care of source code as an ultimate allusion for upholding activities. Well-organized utilization of renovation, testing and quality assurance practices is imperative to make certain that tools sustain the full extensiveness of activities concerned with the software upholding procedure.
The dilemma of rising serviceable software project cost forecast systems is perpetual and there are several challenging advancements. Therefore, in current years there has been encouragement to carry out practical based assessment in order that our indulgent in project prophecy might be based upon existent world verification. Thus now, we are in the exciting situation of possessing this verification in profusion.
As an instance, an assessment of three software engineering academic journals was conducted and it was identified to have almost 50 unrelated studies [4] and on the whole several hundred studies have been published. This is as expected leads to the next step of requirement, for developing a schema of comprehension, particularly when not the entire indication is dependable. This procedure of constituting a schema of comprehension is usually referred to as Meta analysis.
It is an indispensable activity if we are to have any optimism of making good judgment of, and making use of, consequences from our experimental studies. Nevertheless, it becomes evident that when methodically combining consequences several difficulties come across.
Elevated Maintenance Expenses
There are numerous reasons for elevation of maintenance expenses of a software system. These may at the lead to increasing revenue during the lifetime of the software. They are listed as under:
• Maintenance personnel are time and again inexpert and unknown with the application realm.
• Programs being kept may have been developed without up to date method; they may be unstructured, or optimized for effectiveness, not maintainability.
• Changes may establish new liability, which prompt for supplementary modification.
• As a system is altered, its interface has a propensity to mortify, which makes it harder to modify.
• With time, records may no longer imitate the realization.
The Current Status
As it has been discussed, there is need of multifaceted procedures for adjudging cost forecast of software projects. This has conventionally given the magnitude to the software industry and resultant requirement to forecast costs at an early phase of a project; to an acceptable degree of precision. Unfortunately, this objective remains mainly unconquered with not a single approach controlling it.
From recent analysis and utilization of forecast procedures, parametric models, numerical and machine learning methods and expert judgment, a conclusion has been met that these diverse forecast phenomenon has given elevation to the rising number of studies, which are independent of the forecast phenomenon, to experimentally authenticate and compare approaches using several industrially derived data sets.
One advantage of utilizing different data sets is that there is expectation to better sample the somewhat undefined population of software projects and thereby achieve a better idea, as to how the forecast phenomenon might generalize. Since the revolutionary works of researchers there has been a huge enhancement in the figure of studies. At the same time, as this give a great prospect to combine outcome and build a by and large representation, there are, unfortunately, still a number of difficulties.
An Example Analysis
As an instance of the unpredictable nature of practical outcome relating to the estimation of forecast systems there is need to consider regression models and analogy based phenomenon.
A total of 15 studies have been recognized through a methodical evaluation [5] of the journal and conference proceedings. Still no judgment has been arrived at concerning the quality of articles, as all 15 studies have undergone peer assessment.
Cluster Tally
Regression 5
Contradictory nature 4
Analogy 6
Analogy and Regression-Based Forecast
The above table shows an almost even split between the different studies based upon reported exactness stages. This is challenging since it is uncertain what in general body of facts is representing, nor what recommendation should be given to practitioners. The setback we require to tackle is: why are the outcome contradictory? One might anticipate contradictory outcome when models are produced from dissimilar data sets, however, in several cases results were incoherent even when operating on the same data set and the same forecast techniques.
This is not essentially due to negligence but may be to the stochastic character of some rationale techniques and fine variation of forecast techniques.
Conclusion : In this research paper, there is indication towards the next challenge for pragmatic software engineering researchers fascinated in project forecast, is how to effectively combine results. Presently, this is not easy due to the range of assessment approaches in work. In addition, there is discussion regarding the two forecast techniques that have undergone considerable analysis (regression and analogy) the results are almost evenly split.
This means that there are two concerns for the research society. First, there is a requirement of better assessment and reporting regulations. Second, researchers should ask queries such as ‘when it would be best to use approach A above approach B?’, as opposed to ‘is approach A better than B?
References
1. Elliot J. Chikofsky and James H. Cross II. “Reverse Engineering and Design Recovery: Taxonomy”. IEEE Software, 7(1):13–17, Jan/Feb 1990.
2. William M. Ulrich. Legacy Systems: Transformation Strategies. Prentice Hall, 2002.
3. Timothy C. Lethbridge and Janice Singer. “Understanding Software Maintenance Tools: Some Empirical Research”. In Proceedings of the International Workshop on Empirical Studies of Software Maintenance (WESS’97), Bari, Italy, October 1997.
4. Keith Gallagher’s Home Page. URL: http://www.cs.loyola.edu/~kbg/.
5. B. Kitchenham, “Procedures for performing systematic reviews,” Keele University, UK, Technical Report TR/SE-0401 - ISSN: 1353-7776, July 2004.
6. Canning, R., "The Maintenance 'Iceberg'," EDP Analyzer, vol. 10, no. 10, October 1972.
Print version