Effort Estimation Problems in Software Maintenance – A

Survey
Syed Sarmad Ali
Dept. of Computer Science & IT
The University of Lahore
And
Beihang University
sarmadali.uol@gmail.com
Muhammad Shoaib Zafar
Dept. of Computer Science and Engineering
Air University, Pakistan
And
Beihang University
mszafar.dcs@outlook.com
Muhammad Tallal Saeed
Dept. of Mechatronics Engineering
Air University, Pakistan
And
Beihang University.

Abstract— The software industry has been evolving over the
years. Software maintenance is as crucial as software
development. Software maintenance cost has gained a significant
important both for practitioners and researchers. Software
maintenance cost is very crucial to estimate the productivity of
the software, reliability, adaptability, and control. This research
investigation is a study that is based on the literature of
investigation conducted previously in the field of software
maintenance. We have found studies that reveal the effort
estimation problems related and have a direct impact on software
maintenance. We have also identified problems that have a direct
impact on software maintenance. This study will act as a
guideline for researchers to counter these problems. This study
will act as a platform to classify new direction and initiate full-
scale research.
Keywords—Cost estimation, Software Maintenance; Effort
Estimation, Corrective Maintenance; Perfective maintenance;
Adaptive Maintenance
I. INTRODUCTION
In recent years, software development cost has been increased
as compared to the overall other component computer system
project. Similarly, cost increases in the maintenance of the
software system. The majority of the cost is due to the cost of
effort made by humans. Therefore, most of the methods that
are created for software maintenance pay attention to the
above said component and predict in terms of Person-Month
[37]. To predict correct effort estimation is crucial for both
clients and software developers. It is beneficial for many
aspects such as scheduling, project planning, control, and
monitoring. Fail to predict correct estimation may lead to
over-budgeting, missing features and missing deadlines.
A. Software Maintenance:
Software maintenance has gained significant attention over the
last decade. Now more interest has been shifting towards the
betterment of the maintenance of the software. This comprises
of an improved understanding of the development of the
functioning of the software projects. This probably due to
severe reason which contains those substantial resources is
obligatory for the corporate Information System [IS]
department budget. In most cases, the Information system
fluctuates between 50% to 80% of the entire budget (reserved
budget for maintenance) [19,20]. Despite the above facts, yet
software maintenance has not been considered as the top
priority when it comes to comparing with the software
development phase [21] [22]. An investigation conducted in
the past, reveals that around $30 billion consumed around the
world on software maintenance [27] [34]. Many investigations
advocate that due to the organizational behavior, software
maintenance has been limited. In order to improve efficiency
and production, it is essential to consider variable and
inadequate data, which were not given much attention.
Moreover, steps need to be taken in order to make the above
variable effective [25]. Another major concern observed
regarding software maintenance is the lack of availability of
technical, managerial and estimators. It has been observed that
in most organizations that there is a shortage of resources
raises to 30% per year. Likewise, it is very difficult for
software maintenance personal can be found in the software
system. This consequence in un-professional technicians and
staff attempting to achieve software maintenance activities.
Furthermore, these personnel also work for the development
procedure of the system.
Another most important aspect regarding software
maintenance is the inadequate literature and research been
conducted. Historically, researchers had proposed
maintenance models, frameworks, techniques, and tools.
Nevertheless, the revolution of these techniques and tools to
the real world was yet again an enormous challenge for the
maintenance personnel. The actual purpose of this inadequate
resource is with rewriting the software. Our foremost
emphasis is to analyses and understands the software
maintenance model existence in the literature. Our goal is to
gather the most important models and provide a platform for
the researcher to understand the work done within the software
maintenance field. The evidence which investigations
embodies a particular synopsis of the software maintenance
field. Subsequently, this is an exploratory study, it is
unrealistic to highlight each detail of the field, specified
track/scope and conference article page limitations. We
express regret to a certain degree for the important effort
which may not be enclosed.
B. Major Goal
The foremost purpose or main motivation of this investigation
is to contribute to the area of software maintenance by
collecting the evidence and identify the problem that is
affecting software maintenance. Some motivations are as
follow:
• To extract problems affecting software maintenance.
• To investigate the causes of these problems.
• To recognize what models and procedures have been
used for estimating the cost of software maintenance.

978-1-7281-4970-7/20/$31.00
"
$2020 IEEE
#

Figure 1: Software Maintenance Process
II. SOFTWARE MAINTENANCE BACKGROUND
Software Maintenance the field of Software Engineering
which have been ignored over the period of time.
Nevertheless, apparently, it is the most crucial field in the
SDLC (software development lifecycle). Software developer
follows the requirements provided by the clients in order to
accomplish the software project. Perhaps after an ample
amount of time, there is a need for software maintenance
according to the changing circumstances and requirements by
the clients. Software maintenance is considered to be an
essential constituent of software development but
unfortunately, it has not given the same consideration as of
another field of SDLC. Software development holds much
higher importance as compared to software maintenance in the
majority of the software organizations. Software maintenance
initiated once the software development started and it endures
till the software system experiences the retirement process as
shown in Figure 1. According to Sommerville “Software
Maintenance do not halt once the software system is
distributed, nevertheless remains during the era of the system”
[3]. Furthermore, the software maintenance definition defined
in section 2.1.
A. Definition:
1) Maintenance of a software
IEEE STD (1219-1993) [1], has clearly state software
maintenance definition. “amendment of a software
system afterward delivery to eliminate faults, to progress
its presentation and additional features, and adjust to a
product to a fluctuating situation.” (ANSI-IEEE
explanation, [2]).
2) Maintainability:
The comfort through which a software product can be
modified afterward errors or insufficiencies happen,
and can be prolonged or contracted to embrace
innovative and new requirements [12].
B. Classification of Software Maintenance:
Software maintenance can be categorized as preventive
maintenance, perfective maintenance, corrective maintenance,
and adaptive maintenance.
Preventive maintenance is applied to empower upcoming
software maintenance activities and to restrict probable errors
of the functionality in the software system. Corrective
maintenance is associated with the modification and errors in
the software product or it is the exploration and removal of
errors in the software. Adaptive maintenance includes all the
matters that started as implications of affecting the existing
software to a substitute location of software or hardware.
Adaptive maintenance generally required when there is a
modification required as a sign of the hardware changes,
operating system changes, or DBMS changes. Perfective
maintenance is applied to expand the requirements of the
system, refining its functionality. This kind of maintenance is
obligatory when amendments made to the software to make it
additional maintainable. Literature suggests that software
maintenance is the emerging field of the software engineering
field. Moreover, it is also the most controversial and
concerned procedure in the SDLC, but then again it hasn’t got
much attention that was mandatory to make it more effective
[4][5][6][7][8]. Research studies also expressed some thought-
provoking evidence that the majority of the developers don’t
have the understanding that they are essentially undergoing
the maintenance procedure. They presumed that they are doing
the development process, nevertheless, in the actual scenario,
they performed maintenance activities.
C. Effort Estimation problems in Software Maintenance:
For organizations, it is hard to experience the software
maintenance procedure due to the shortage of maintenance
team and their expertise. It is difficult to perceive, how will
the system respond, if the software code is a change for
maintenance purposes and hence lead to over estimation.
Software maintenance is problematic if the software product is
not developed for maintenance. The additional reason might
comprise the organization is not focused on perfection rather
they want the system to initiate as soon as possible. The main
and foremost problems in predicting efforts connected to
software maintenance include software systems’ size and
efficiency of the software maintenance [31]. There are
numerous models for estimating size, source lines of code
(LOC), and function point [32]. LOC has been used as the size
measure of software maintenance, despite some complications
which result due to differences in the description on source
codes itself and including the novel, altered, or reprocessed
lines distributed. Nevertheless, counting the LOC for a priori
predicting is typically problematic when it comes to predicting
how much exertion would be obligatory for software
maintenance [32] [33]. Furthermore, the efficiency aspects of
software maintenance products must be distinguished with
software development projects. Table 3 suggest some models
that were proposed to solve similar estimation problem in
software maintenance.
 III. LITERATURE SURVEY
Initially, a system underneath analysis must have been
Over the last decade, numerous investigations have been functional for in excess of a year. Furthermore, a substantial
conducted in order to identify problems affecting software quantity of maintenance effort or procedures must be devoted
maintenance and cost estimation. Different research study has to the system. Thirdly, the software
been conducted over the years, in order to extract evidence, system successively consecutively in the organization
even on the Legacy systems. Lientz and Swanson [9] [10] essentially consumes a significant position within the
conducted a study comprises of a questionnaire, which was organizational procedures. Apart from these direct procedures
highly regarded in terms of extracting knowledge regarding of classifying the problematic, there are some problems stated
the aspects affecting the maintenance of the software. This in Lientz [29].
survey helps to identify numerous resources that are being
used for the maintenance process. These procedures comprise
development, modification, and programming to control the IV. SOFTWARE MAINTENANCE PROBLEM
system. Approximately 60% of the total maintenance process
consists of perfective maintenance, secondly upgrading The foremost emphasis of this study is to establish an
documentation of the system and finally, the productivity investigation which specifies the problems that are affecting
factor was detected. the software maintenance. The major problem is highlighted
Many research studies suggest that with few sample sizes of as suggested by Lientz and Swanson [14]. Palvia et.al [24]
the respondent results in doubtful analysis. However, Lientz likewise discussed and presented these problems in their
[9] presented some suggestions to sustenance his exploration research investigation as well. Table 1 highlights these
study. The primary suggestion, which he offered was that problems.
maintenance personnel sureness is very short and the
inspiration level is on the deteriorating side. His additional
Table 1
observation was that there is a substantial load on the
SOFTWARE MAINTENANCE PROBLEMS
maintenance personnel. One more hypothesis which he
Leintz & Sampson [14], Palvia et.al. [24]
presented that software development has significant
importance to minimize the cost of the maintenance [15] [16]
[17] [18]. Kriebel and Raviv selected diverse procedures to
report probable efficiency aspects. They chose different 1. Turnover Maintenance problem.
methods of Data Envelopment Analysis (DEA) to predict the 2. Quality of documentation.
association among the invention of software maintenance and 3. Changes in software and hardware
the input [19]. The investigation done by Lientz and Sampson 4. Extensions and enhancements demand
[14] was more reliable. Similar research done by the Data 5. Maintenance of programmers’ skills.
Processing Management Association (DPMA) contains in 6. Original programming quality.
excess of 2000 respondents. The above said research study 7. Availability of a number of maintenance
was inspired by the procedure presented by Lientz and programmers.
Sampson [26] and the observations can be perceived in [14] 8. Challenging stresses for programmer time
[25]. 486 respondents responded properly to the survey, which 9. Inadequate user attention.
was inspiring keeping in mind the questionnaire was lengthy. 10. Failure of system run.
Nevertheless, the requirement of the investigation and over-all 11. Deficiency of user considerate.
descriptive observations will assist the researchers in emerging 12. Storage necessities program.
novel concepts and direction. Lastly, the outcomes were 13. processing time requirements.
determined afterward entering the investigation of the 14. The motivation of the Maintenance
statistics in the SPSS software. Another research study is programmer.
shown in 1980 P.Weger and Lientz [28], on 18 systems 15. Predicting the requirement of maintenance
consecutively the naval. These software systems were weapon programming
software system monitoring missile, naval airplanes and ship- 16. The productivity of maintenance programming.
class. These software systems were real-time applications, 17. Reliability of System software and hardware.
typically rely on sensors and radars. The investigation 18. The integrity of data.
confirmed [28] the results of the earlier research investigations 19. Impractical user prospects.
staff within a similar field. Investigators must move according 20. Devotion to a programming standard
to the guidelines which were recommended by Lietz [14] [25] 21. Support for management.
[26], despite the fact leading the study in the field of software 22. The capability of system design details.
maintenance. 23. Pressures of budgetary
24. Consultation of programmed assurances
25. Insufficient user training
26. Revenue in user organizations

Table 1 presents problems of maintenance nonetheless utmost
thoughtful amongst them as depicted in Table 2. According to
Palvia et.al. [24], “Turnover of maintenance programmer,
improbable user anticipation, the productivity of maintenance
programmer, the budgetary, motivation of maintenance
programmer and quality of documentation are between the
aspects in which from previous decade enhancement have
been progressing to make it more accurate.
Table 2
MOST DEMANDING MAINTENANCE PROBLEMS
Palvia et.al. [24]
1. Enhancement Demand.
2. Demand time of programmer.
3. Quality of Documentation.
4. Impractical user anticipation.
5. Competence of the system design requirement.
6. Amount of availability maintenance programmers.
7. Commitments for meetings.
8. Deficiency of user considerate.
9. Insufficient user training.
10. Programming quality.
V. PROBLEMS IN ESTIMATING SYSTEM’S SIZE
Estimation of the software product is among the most crucial
aspect for the successful. Before the beginning of the software
maintenance activity, it is essential to estimate the number of
resources that are being required for the implementation of the
procedure. This tends to divert to a new research area for
measuring a system. The measuring of the software system
does not only relate to the measuring of the software size but
also it relates to the resources required in order to perform
maintenance. To have a better understanding of the size of the
project, management personal must involve the estimators to
forecast the correct size and cost estimation.
Palviaet.al. [24] and Lientz [26] [27] [28] [29] proposes that
the environment aspect plays an important role in the process
of measuring a system. The factor that affects measuring the
size of the project are discussed as follows: these factors were
presented in diverse studies [24] [25] [26].
A. User external
The user plays a crucial role in any organization socially and
culturally and in some cases competitively. In any
organization, the main resistance to change is caused by the
users. It is very difficult to perform re-engineering or
enhancement or retirement without taking in confidence all the
users.
B. Technological Factor
As technology progresses, the organization needs to adopt new
changes in technology to compete in the market. This is
crucial for every organization to equipped with the latest
technology to make products in their businesses. The
distributed application was adopted as soon as it launched in
the market. Therefore, in order to identify and determine the
size of the software, one must have to comprehend by what
method many terminals are devoted to the system.
C. Managerial Factor
The managerial factor cannot be disregarded in any
organization; the management aspect cannot be
disregarded. The manager has an influence on almost all
the employees working under his command. Every
organization needs to progress forward with the help of the
decision made by the Managers and work done by the
employee. Therefore, there is a chance that employees
extract shortcuts in order to complete their tasks on time.
Consequently, managers have to follow the procedures
according to the documentation and apply new techniques
when needed to counter these problems
D. Marketplace
To maintain goodwill and credibility each association has to
effort hard. In order to contest with the other organization, the
marketplace inspires organizations to adopt new technologies
and make continuous changes. Eventually, it helps the
organization to move forward and progress.
E. Organizational Issues
There is always been a debate to merge the development team
and maintenance team together or keep them separate. Lientz
[29], presented that the maintenance team might face
complications if they do not work with the development team.
The maintenance team has to extract from the top in order to
understand the functionality of the software. Research shows
that there is a shortage of maintenance personnel 20% – 30%
[29]. It also suggests that appropriate designation for the
employees is necessary for the organizations.
F. Productivity Issue
The productivity of the overall system can be improved by
identifying problems affecting productivity [26] [29]. The user
himself is one of the most important factors for productivity.
A dissimilar measure has to be set for the user as he can be a
programmer or can be any user.it is understandable that the
programmer is superior to the other normal users, because of
the nature of work. If the core requirement of the system is
found the complexity of the system will be reduced but it also
helps to design and improve the system productivity.
G. Theoretical Problems
IEEE [1][2] presented the definition of software maintenance
which has been under reflection by a maximum of the
investigators. They emphasized improvement along with
functional support. Re-engineering, problematic identification
and debugging are considered as the main constituent of
software maintenance. Re-engineering is the recording of the
system’s overall structure for better productivity.
Augmentation can be particularized with improvements in
documentation, accumulating data and file development.
 Table 3:
Models for solving Effort Estimation problems

S.No Model Equation Description Reference

The COCOMO II model is the extended version of the COCOMO

The COCOMO which was proposed by Boehm.
1. II model The COCOMO II model reproduces the predictable efforts for
[34]
changing reusable software.

AME = ACT × SDT The ACT is well-defined as ‘the segment of the software product’s
The ACT model foundation instructions which suffer modification throughout a typical [35]
E = ACT × 2.4KLOC1.05 (Schaefer’s study) year, either addition or modification’

FP model defines the size of the software consist of five functions: (1)
internal logical files (ILF) 2) external interface files (EIF) (*which are
EFP = (ADD + CHG + CFP) × VAFa + (DEL × VAFb) data functions type).
ADD = Addition
3) external inputs (EI), 4) external outputs (EO), and 5) external
CHG = Change
inquiries (EQ) (*transactional function types).
3. The FP model CFP = unadjusted function points added by conversion. [36]
DEL=Deleted The FP of maintenance projects are calculated by three-component of
VAFa and VAFb = value adjustment factor of the application after and
functionality (1) the application functionality which is comprised of the
before the project, respectively.
user necessities for the project; (2) the adaptation functionality; and (3)
the value adjustment factor (VAF).
The unadjusted function count (FC) is calculated by multiplying each
raw count by the projected weight (W):

The VAF of a software maintenance project can be calculated by the

SMPEEM following:
(“Software- The SMPEEM is considered to assist the project executive to compute
Maintenance- the predictable software maintenance effort.
4. FP can be calculated by the following:
Ten novels VAFs are applied for altering the FPs considering the
[37]
Project- Effort-
Estimation software maintenance complication features.
Model) Effort in term of size is calculated by:

The relation among the software maintenance effort and FPs can be
calculated by the following:

Direct Labor Cost = Σ {Occurrence Frequency × Average Service Time

× Number of Workforce × Unit Cost of Wage by Level of Workforce}
(1)
Total Cost = Direct Labor Cost + Indirect Overhead Expense + This model is designed to estimate maintenance cost for the packaged
5. Package Model Engineering Fee + Direct Expense + VAT (2)
software. [38]
Verification of the model was done by applying on 17 projects.
= Direct Labor Cost + 110% of Direct Labor Cost + 20 % of (Direct
Labor Cost + 110% of Direct Cost) + Direct Expense + VAT (3)
= Direct Labor Cost × 2.52 + Direct Expense + VAT (4)

6. SMmm N/A (SMmm) developed to assess the maturity of the software maintenance [39]
function and help in identifying improvement activities

Software The work of this model are as follows 1) to designate the important
Maintenance positions of software maintenance; 2) to existing the model inform
7. Capability N/A the process showed throughout 2003, and 3) to existing, [40]
Maturity Model for the primary time, the efficient construction of the
(SMCMM) model.
The study presented by Lientz [29], proposes that
improvement by the user is the foremost action in any
association. A study [29] proposes that inconsequential
importance (about fewer than 20%) specified to the segment
of recording (re-engineering for the productivity) and to
identifying and resolving errors. The documentation segment
has the minimum of the attention been specified. The study
proposes that a lesser amount of 20% of the effort done in the
stage of documentation. Considering all the aforementioned
results, it is analyzed that there is a need for a comprehensive
framework that is required in an organization that performs the
maintenance process. It is also analyzed by most of the
researchers that the concept of categories of software
maintenance is unknown in many organizations. The
technician and development staff that are involved in
maintenance actions are not exactly the maintenance staff.
Most of the workers do not have the idea of categories. There
is an essential requirement to minimize the gap amongst the
research and the real operation of the maintenance procedure.
VI. DISCUSSION & CONCLUSION
This research study has examined some of the most crucial
problems that are affecting the software maintenance process
and effort estimation in particular, which is eventually faced
by the organization. We have presented some models from the
literature in Table 3, that are being extensively used in the
software maintenance domain. These models include some
well-known cost estimation base model (such as COCOMO
II), which are nowadays being used by the researchers to build
a “Hybrid Model” for better estimation of the effort. Similarly,
Functional point (FP), is used for measuring the size of the
project. For estimation of the software maintenance effort
estimation, SMPEEM model was developed in order to
compute the predictable software maintenance effort. Another
model, “Package Model” was also presented in order to
estimate maintenance cost.
The considerable focus needs to be done on the application of
software maintenance. Study reveals that there is a
requirement of numerous resources in the software
maintenance procedure and activities. Therefore, it is
significant to recognize and correct the complications, which
are disturbing the software maintenance process. This research
has emphasized the problem and also the issues that contribute
to the problem. Our research will assist the investigators by
providing the preliminary examination of the problem which
is affecting the software maintenance process and effort
estimation.
References
[1] IEEE Standard I2 19- 1992. Software Maintenance Standard, published
by the IEEE Standards Office. P.O. Box 1331. Piscataway, NJ 08855-1331.
[2] IEEE. Standard glossary of softii~are engineering terminology.
ANSI/IEEE Standard 729, IEEE.
[3] Sommerville, Software Engineering, 9th ed., Addison-Wesley, 2011.
[4] Krogstie, J., and Solvberg. A.. Sqfbvar-e Mnintenance in Noma; A
Survey Investigation, Proc. of Conference on Software Maintenance- 1994,
Computer Soc. Press, IEEE. Canada, ( 1 994),304-3 13.
[5] Cousin L. and Collofello J.S., A Task-Based Approach to lmproving the
Sotiware Maintenance Process, Proc. of Conference on Software
Maintenance- 1992, Computer Soc. Press, IEEE,
[6] Pressman, R. S., Software Engineering- A Practitioner S Approach,
McGraw-Hill Book Company Europe, London, (1994).
[7] Sherer, S. A., Cost Bene$t Analysis and the Art of Sofware Maintenance
Process, Proc. of Conference on Software Maintenance-1992, Computer Soc.
Press, IEEE, Orlando (Florida), (1992), 70-77.
[8] Sommerville, Y ., Sofhvare Engineering, Addison-Wesley Publishing
Company, ( 1989).
[9] Daly, J., Brooks A., Miller J., Roper M. and Wood, Ven$cation of Results
in Software Maintenance Through External Replication, Proc. of Conference
on Software Maintenance- 1994, Computer Soc. Press, IEEE, Canada, (1
994), 50-57.
[10] Dekleva, S. M., Delphi Study of Software Maintenance Problems,
Proc. of Conference on Software Maintenance- 1992, Computer Soc. Press,
IEEE, Orlando (Florida), (1 992), 10-1 7.
[11] Genuchten, M., Brethouwer, G., Boomen, T. and Heemstra, F.,
Empirical Stud? of Software Maintenance, Information and Software
Technology, Vol. 34, No. 8 (Agosto 1992). 507-512.
[12] J. Martin and C. McClure, Software Maintenance: The Problem and Its
Solutions. Englewood Cliffs, NJ: Prentice-Hall, 1983.
[13] S.M. Dekleva. Soft~uare Maintcnance: 1990 Statiis. Journal of Software
Maintenance, vo1.4, I'Ij233-247, 1992.
[14] B.P. Lientz and E.B. Swanson. Problems in Application Software
Maintenance. Comms. of ACM, 24, 1982, 763 – 769.
[15] Belady, L.A., Lehman, M.M. A model of large program development.
IBM Systems J., 15, 3 (1976), 225-252.
[16] Boehm, S.W. The high cost of software. In Horowitz: Practical
strategies for developing large software systems. Reading, MA: Addison-
Wesley, 1975.
[17] Boehm, B.W., Brown, J.R., Lipow, M. Quantitative evaluation of
software quality. IEEE Computer Society, 2nd International Confer- ence on
Software Engineering, 1976, 592-605.
[18] Canning, R.G. , ed. That maintenance "iceberg". EDP Analyzer, 10, 10
(October 1972).
[19] Bankar, R.D.,Datar,S.M., and Kemerer, C.F.,”A model to
evaluate the productivity of software maintenance projects,”Management
Sciences, VOL 37, NO 1 January 1991, pp, 1-18
[20] Kim, C., and Westin, S. “ Sofwtare maintainability: Peeception of EDP
professionals,” MIS Quarterly, June 1988, pp. 167-179.
[21] Moad, J, “Maintainability the competitive edge,” Datamotion, Vol 36,
No 4, Feb 15,1990, pp.61-66.
[22] Swanson, E.B. and Beath, C.M. “Reconstructing the system development
organization,” MIS Quarterly, September 1989, pp. 293-304
[23] Parikh, G. "Restructuring Your COBOL Programs."
Computerworld Focus, Vol. 20, No. 7A, February 19, 1986, pp.
39-42.
[24] Prashant Palvia, Aaron Ptula and John Nosek, “Problems and
Issues in Application Software Maintenance Management ” Journal of
Information Technology Management, Volume VI, Number 3, 1995.
[25] Paddock, C.E. and Shephard, G.G. “Managing software maintenance
: The challenge of insufficient data” Journal of System Management, Vol 42,
No 10, Oct 1991, pp.28-31,36.
[26] Lientz, B.P. , Swanson, E.B. Discovering issues in software
maintenance. Data Management (October 1978), 15-18.

[27] Lientz, B.P., Swanson, E.B. Software maintenance management

– a study of the maintenance of computer application software in 487 data
processing organizations. Rea-Sing, MA: Addison-Wesley Publishing
Company, Inc., 1980.

[28] Lientz, B.P. and Wagner, P., A Survey of Eighteen Software

Commana and Control Systems, Office of Naval Research Report.

[29] Bennet P.Lientz, “Issues in Software Maintenance”,1983.

[30] Parikh, G. "Restructuring Your COBOL Programs." Computerworld

Focus, Vol. 20, No. 7A, February 19, 1986, pp. 39-42.

[31] Martin J, Mcclure C. Software Maintenance: The Problem and its

Solutions. Prentice-Hall: Englewood Cliffs NJ, 1983; 23.

[32] Low GC, Jeffery DR. Function points in the estimation and evaluation
of the software process. IEEE Transactions on Software Engineering 1990;
16(1):64–71.

[33] Jones TC. Measuring programming quality and productivity. IBM

System Journal 1978; 17(1):39–63

[34] Boehm BW, Clark B, Horowitz E, Westland C, Madachy R, Selby R.

Cost models for future software life cycle process: COCOMO 2.0. Annals of
Software Engineering Special Volume on Software Process and Product
Measurement, Arthur JD, Henry SM (eds.). Science Publishers: Amsterdam,
1995; 57–94

[35] Pressman RS. Software Engineering A Practitioner’s Approach, ch. 20.

McGraw-Hill: New York NY, 1992; 677

[36] Albrecht AJ. Measuring application development productivity.

Proceedings of the joint SHARE/GUIDE and IBM Application Development
Symposium. SHARE, Inc. and GUIDE Intl. Corp.: Chicagho IL, 1979; 83–92.

[37] Ahn, Y., Suh, J., Kim, S., & Kim, H. (2003). The software maintenance
project effort estimation model based on function points. Journal of Software
Maintenance and Evolution: Research and Practice, 15(2), 71–85.
doi:10.1002/smr.269

[38] Woo Je Kim, and Soo Jin Jung (2014). A Method for Estimating
Maintenance Cost of Package Software. International conference on
Computer Science and Information Systems (ICSIS’2014) Oct 17-18, 2014
Dubai (UAE)

[39] April, A., Huffman Hayes, J., Abran, A., & Dumke, R. (2005). Software
Maintenance Maturity Model (SMmm): the software maintenance process
model. Journal of Software Maintenance and Evolution: Research and
Practice, 17(3), 197–223. doi:10.1002/smr.311.

[40] April, A., Abran, A., and Dumke, R.R. ‘SMCMM model to evaluate and
improve the quality of the software maintenance process: SMCMM model to
evaluate and improve the quality of the software maintenance process’ (IEEE,
2004, edn.), 2004, 1st Edi. pp.
243-248.