A Case Study on the Strategy of Maintaining Commercial Software with a Large Number of Users

Software maintenance is the activity in which changes occur in the artifacts of a software after delivery, with the purpose of keeping it available, correcting its failures, improving its performance and adapting it to new or modified requirements, according to the needs of Your users. It is an indispensable activity, without which existing systems would quickly become lagging and inefficient for organizations. The objective of this work is to verify the adherence of existing software maintenance models and processes in an organization whose product is used by a large number of users. After identifying and evaluating the problems of the company’s current situation, carried out through a case study, actions are suggested to improve its software maintenance process.


INTRODUCTION
The software development life cycle consists of a series of phases: planning, analysis and specification of requirements, design, implementation, testing, delivery and deployment, operation and maintenance.Upon completion of its development, the software is delivered to the customer, independent of the application domain, size and complexity, will continue to evolve over time.In the scope of software changes occur when errors are corrected, when there is adaptation to a new environment, when the client requests new improvements or new functions and when the application goes through a reengineering process to provide benefits in a modern context (Sommerville, 2007).
Observing the aforementioned considerations, it becomes evident that software companies understand the need to research and relate more information about software maintenance activity.These need to highlight the main difficulties and challenges of the maintenance activity, the best practices and processes to be adopted, and the existing tools that support this maintenance activity.Second (Sommerville, 2007) points out that the success of the operations of several organizations is directly linked to the proper functioning of the systems.The lack of knowledge in models and approaches that help in the software maintenance process in organizations, makes many systems have characteristics of legacy systems, according to (Mellegard et al., 2016) and (Ahmad et al., 2016).Therefore, it is necessary to ensure the availability of systems and efficiency of care of software maintenance requests.
In this sense, this article presents a case study that aims to map the software maintenance process of a company, and verify the adherence of models, processes and practices of the software maintenance activity.
The case study was prepared by making a survey of the existing software maintenance process in the company.Subsequently, a search was made for the best practices, processes and software maintenance activities that fit the company, within the model used.
The structure of this text includes a literature review, presented in section II.A systematic mapping models in order to identify processes is shown in section III, a case study and operated is explained in section IV, the results of the analysis in Section V and in section VI findings are presented, followed by references.

THEORETICAL BACKGROUND
Software Maintenance is directed to the preservation of existing software, correcting errors and making the changes necessary to maintain reciprocity in software operating environment.Evolution, on the other hand, enhances the functionality and quality of the software.Maintenance is driven by bug reports and change requests.Evolution is driven by new requirements, functional or non-functional (Assessment et al., 2016).Both come in the form of a request for change.

Software Maintenance
The software maintenance activity is characterized by the modification of a software product already delivered to the client, to correct any errors, performance improvements, or any attribute, or to adapt that product to a modified environment.The software maintenance may be defined as a part of the software development cycle (Sommerville, 2011a;Standard, 2006).In fact, it is not uncommon for a software organization to spend 60 to 70 percent of all software maintenance resources (Pressman, 2007).

Types of Software Maintenance
According to (Rezende, 2005) "in general, all software undergoes maintenance, either for simple postdeployment adjustments, or for substantial improvements, by virtue of the legislation and, finally, because it is generating erros".In this sense, Sommerville (2011b) recalls that there are three different types of software maintenance: maintenance to repair defects in the software, maintenance to adapt the software to a different operating environment and maintenance to add functionality.A fourth category of service is presented by some authors (Pressman, 2009).These four types of software maintenance, are structured in accordance with ISO / IEC 14764 (Standard, 2006) and are described below: • Correction Maintenance: o Corrective maintenance: Corrective maintenance refers to modifications required by actual errors in a software product.o Preventive Maintenance: They seek to identify previously possible sources of problems in the software and to correct them in advance.

• Improvements Maintenance:
o Adaptive Maintenance: refer to tailor the software to your external environment, including changes to implement new system interface requirements, new system requirements, or new hardware requirements.o Perfective Maintenance: aim to add new functionality features to the software, usually due to user requests.

SYSTEMATIC MAPPING
The systematic mapping, in this work, aims to find and analyze relevant and recognized primary works in the area of software maintenance.In this sense, the purpose of this section is to identify which models, practices and/or existing software maintenance processes, in addition, we sought to identify the main tools used.
This study was based on the guidelines proposed by (Petersen et al., 2008) and was conducted by 4 steps -Definition of the research questions, String of searches, inclusion and exclusion criteria and analysis of the results.

Definition of Research Questions
We sought to answer the research questions that served as a guide in the mapping of this research, so that it was possible to conclude and explain about software maintenance in companies.The previously defined questions were: (Q1) What are the main challenges in software maintenance?(Q2) What models, processes or practices are adopted in software maintenance?(Q3) What tools are there to support software maintenance?

Search String
To search the digital libraries, an English search string was created, formatted according to the rules of each digital library.According to (Petersen et al., 2008) primary studies are identified by using search strings in the database or manually in periodicals.Table 1 presents the elaborated strings.

Inclusion and Exclusion Criteria
The selected studies were analyzed in order to identify those relevant to the research subject.According to (Kitchenham and Charters, 2007) the initial searches return a great amount of studies that are not relevant, do not answer the questions or even have no relation with the topic in question.Thus, the selection stage of the primary studies was divided into: Definition of Inclusion and Exclusion Criteria for primary studies and definition of the selection process.
In this study, inclusion criteria were defined as: A search was carried out in the ISO database, in order to identify standards that support the software maintenance process, the ISO / IEC 14764 standard was identified, which contains the activities and tasks necessary to modify an existing software, preserving its integrity, and all activities and tasks to be performed in a software will be the responsibility of the maintenance team (Standard, 2006).
The exclusion criteria of this study were: 1. Articles that have no relationship with Maintenance of software in companies will be excluded; 2. Studies that are not included in the context of Software Projects, Software Industry or Software Engineering; 3. Studies that clearly do not address research questions; 4. Studies that do not meet the period from 2009 to 2016.Initially the searches returned 41 primary studies that reported the maintenance of software in companies, so the titles, abstracts and keywords of all articles were read and each one generated a list of selected studies.After the analysis of the list, the reading of the abstracts, introduction and conclusion and the application of the inclusion and exclusion criteria were carried out again, which resulted in a subset of 18 studies considering the 3 digital libraries.

Analysis of Results
This section presents the results of the analysis performed in the 18 studies, answering the research questions defined in Section A. After presenting the general data of the analysis, the answers to the research questions based on the analysis that was carried out in the systematic mapping.
(Q1) What are the main challenges in maintaining software in organizations?
According to the concluded survey, the authors (Li et al., 2010) cite the high costs as a major challenge in software maintenance.The authors (Stojanov et al., 2014) affirm that the estimation of software maintenance effort in companies is one of the main challenges, since software maintenance consumes most daily hours of work for all programmers.In addition, most software maintenance activities are related to the resolution of user requests, on the other hand the authors (Tsunoda and Ono, 2014) and (Tsunoda et al., 2015) state that work efficiency for maintenance and software support is something to be studied for companies.Still in this context the authors (Van

Springer³
Maintenance AND software AND companies ¹ http://ieeexplore.ieee.org/Xplore/home.jsp² http://dl.acm.org/³ http://www.springer.comDer Schuur et al., 2011) state that the prioritization of software maintenance tasks as well as the implementation of processes in this activity is totally essential for software maintenance tasks.
The lack of knowledge in the corrective maintenance activity of software in companies is cited by the authors (Alaranta and Betz, 2011), and the authors (Mellegard et al., 2016) and (Ahmad et al., 2016) cite the lack of models and approaches that help the development of these software in the many of them have the characteristics of legacy systems.
The evaluation of the quality of software products, measurement of defects and approaches of identification of individual versions in software maintenance is reported by (Singh and Sangwan, 2014) as one of the challenges, since all three allow software professionals to evaluate what works and what which does not work on software identifying improvements and ease of maintenance.
For the authors (Poklemba et al., 2009), the main challenge in software maintenance is the high cost that the company has in the moment of a new development to carry out maintenance on its products.
Change the structure of the analysts participating in the software maintenance and practice of new improvements that maintenance staff is crucial in view of the authors (Ohba et al., 2007), because from this new structure will be possible to create an indicator to time the transfer of software maintenance responsibilities within the company and to consider the delivery time of system maintenance responsibilities.
The authors (Stojanov et al., 2014)consider that the evaluation of maintenance processes is a major challenge for companies, as well as improve the planning activities is essential to increase the efficiency of services provided to customers and product quality Software.
(Q2) What are the best models, processes and / or practices to be adopted in software maintenance?
For the authors (Stojanov et al., 2013) the best practice to be adopted is a model to estimate the average number of working hours for the known frequency of software maintenance requests.The authors (Poklemba et al., 2009) and (Dantas et al., 2013) believe that the best practice to adopt is to implement a process that explores what should be the correct way of software design, what are the most common mistakes, and how to win the maintenance of low cost in this software.And propose an evaluation and selection of software maintenance processes that assist in the planning of maintenance activities is approach that software companies should adopt according to the authors (Stojanov et al., 2014) and (Marques-Neto et al., 2013).
The application of agile methodology is a practice to facilitate software maintenance, as these agile methods can help speed up the process and improve code quality, bringing user satisfaction and motivation as well as communication among team members.Maintenance authors according to (Ahmad et al., 2016).Regarding the work of the software maintenance team, the authors (Van Der Schuur et al., 2011) argue that applying a history of software operations will promote consensus among employees on the priority of maintenance tasks to be developed and how many bugs need to be corrected, thereby facilitating communication between teams and prioritizing delivery dates and activities and the authors (Ohba et al., 2007) state that the creation of a structuring model for new software maintenance team, thus analyzing the time to deliver maintenance improvements and determining the optimal time to do so is essential For the adaptation and productivity of this maintenance team.In this same segment in software maintenance team improvement, the authors (Alaranta and Betz, 2011) suggest that the implementation of a theory of knowledge coordination in development groups can solve problems in the software maintenance process of companies.
Implement a framework of metrics software process-oriented aspects to predict the bugs and identify the software maintenance index is a proposal to improve according to the authors (Singh and Sangwan, 2014).
The application and development of UML diagrams in the development of software (Unified Modeling Language) according to authors (Dantas et al., 2013) and (Marques-Neto et al., 2013), would facilitate future software maintenance tasks, encouraging maintainers to maintain diagrams updated and thus help companies to analyze and verify how systems are being maintained, making it easier to reach the prospects of their end users.
The current standard that supports planning, management and execution of software maintenance activities is ISO / IEC 14764: 2006, this standard defines that a potential means of containing software maintenance costs is the use of CASE tools.
(Q3) What tools are there to support software maintenance?
With the aim of raising the critical reading of the articles presented in this paper, question 3 was elaborated to describe tools found in those articles that support processes or improvements in software maintenance in companies.
Software maintenance activities require the help of tools.The vision for CASE is an interrelated set of tools to support all aspects of software development and maintenance.
According to (Ahmad et al., 2016), Kanban has been a tool that supports software maintenance because it offers several benefits for maintenance work, such as bringing visibility to maintenance tasks, protecting teams from excessive commitment, helping to prioritize tasks , synchronization of work with other teams, still state that when using Kanban, team action for urgent work is more spontaneous, and the work can be pulled according to high priorities.
The systems used for maintenance management are commonly referenced as CMMS -Computerized Maintenance Management Systems (Wireman, 2008).In Brazil, they are simply called the Maintenance System.The CMMS are tools for companies to track equipment and inventory items, to detail when and how work orders are to be executed, to link all labor costs, materials and tools (Peters, 2015).

CASE STUDY
According to (Fonseca et al., 2002) the research allows an approximation and an understanding of the reality to investigate, as a permanently unfinished process.It proceeds through successive approximations of reality, providing subsidies for intervention in the real.
The method used for the development of this work was the case study, since it is an empirical investigation that allows the study of a contemporary phenomenon within its real life context, especially when the boundaries between the phenomenon and the context are not clearly defined (Yin et al., 2011).
The research focused on identifying how the organization performs software maintenance.The product investigated is an application with more than 7000 users allocated to 400 customers.These users are scattered from north to south of Brazil.

Company Characterization and Current Scenario
The organization studied is a medium-sized company focused on mobility systems for industries, wholesale and retail, located in the interior of the state of São Paulo.Founded in 1991, it is staffed by a team of forty-five software engineering professionals, and is looking for improvements in its software maintenance processes.
An analysis was performed in the current company scenario, and identified that software maintenance is performed only by a single sector, called the coding sector, there is no defined model for this activity.This sector does not only meet software maintenance demands, but also performs other activities relevant to the development area.In Table 2 it is possible to analyze the challenges, processes raised in the literature and the comparison with the current scenario of software maintenance of the company.
After mapping the current scenario and analyzing all the information collected, the following problems were selected and enumerated, within the case studied: A. Lack of a process for activities of the software maintenance team; B. Lack of visibility of software maintenance tasks and activities; C. Absence of planning, criteria and documentation of activities; D. High cost in relation to hours applied in this activity; E. Overloading tasks; F. Failure to communicate with the user; G. Delivery time.
The lack of a process in the software maintenance activity is one of the biggest problems (A), according to the company analyzed.The lack of a standard procedure to follow in relation to software maintenance in the company

Element identified in systematic mapping
Company's current scenario The prioritization of software maintenance tasks, implementation of processes in this activity [17].
Nonexistent.Absence of a process of maintenance of Software; Task Overload Adoption of models and approaches that support the maintenance of software in the company [18] [4] and [5]. Nonexistent.
Greater consumption of programmers' hours in software maintenance [14].
Existing.It causes a very large cost for software maintenance activity.Most software maintenance activities are linked to user requests [15].
Existing.Most software maintenance requests are identified by the clients / users of the systems.The evaluation of the quality of software products, measurement of defects and approaches of identification of individual versions in software maintenance [19] Nonexistent.Today the maintenance and performed when reported to the staff.
High cost of the company at the time of a new development to perform maintenance on their products [20]. Existing.
Evaluation and selection of software maintenance processes that assist in the planning of maintenance activities, as well as documentation [23] Nonexistent.Earlier maintenance record too shallow.Insufficient documentation.
is one of the main challenges because the company can not identify these demands.There is an inherent concern of delivering requests to customers, as many need faster answers and solutions.Cases of emergency maintenance, when they occur, are prioritized to the detriment of others.
The second problem raised (B), results in the time wasted of the maintenance team, since there is no routine and visibility of the tasks in progress in software maintenance, nor a survey of the activities, they are considered only with resolution of Called.From the Team Coordinator perspective, it becomes difficult to get a broad view of what is being done and several bottlenecks go unnoticed.
The lack of planning, criteria and documentation of the maintenance area is another problem for the company (C).This lack of planning and criteria causes the activity to be performed informally, without considering the specific importance of each request made by the user.There is no documentation with records history of software maintenance, it is perceived that lack of documentation is something that, secondly, the company could assist in the process.
High cost in relation to the hours applied in this activity (D), for the internal control of the sector, today the professional that takes care of software maintenance requests, loses a lot of time in this activity, often due to the lack of knowledge in performing maintenance on the product.
Overloading tasks (E), in the current context the development task needs to merge with maintenance, contributing to the decrease of performance of the maintainer.This worsens when tests on a new feature are being done in parallel to some fix requested by the client.
Failure to communicate with users (F), there is a gap between users and the process, ie, the user can not see the flow of their demand, preventing better monitoring.The professionals in charge of maintenance also reported that the client does not always fully understand what he is requesting, often generating discussions between the company and the client, generating a communication problem between user and developer.
The case studied has identified that in many cases the customer believes that a certain maintenance will suffice to adapt the software to its new business need, when in fact it is not enough.This difficulty of understanding the software by the client end up generating wear situations in the relationship between company and client.
Delivery time is always a problem when there is no process to conduct maintenance.This was another factor verified, since not always the maintenance with a scheduled and informed date to the customer, can be delivered in the agreed term, usually due to rework in maintenance already done, or changes of priorities of delivery according to the customers.
In relation to the analysis of the current model of the company, it is realized that the implementation of an improvement for the software maintenance process is necessary.The next section will investigate the adherence identified in the literature compared to the needs of the company.

Analysis of the case study and adherence to the elements identified in the systematic mapping
After the case study and the systematic mapping, the following elements were identified.Table 3 shows the elements identified with the case study carried out in the company.
After defining the elements, the relationship was established with the actors (Organization, Developer, Client / Users).This adherence of the elements identified in the case study will establish the responsibilities with the actors to meet the ideal model to be implemented in the company.
It is possible to verify the relationship of the elements with the actors through Table 4.

ANALYSIS OF RESULTS
After cross-identification of the elements, shown in Table 3, this section presents the adherence of the models found in the literature through the systematic mapping in the elements shown in Table 2.This work does not contemplate the implantation, that is, they are evaluated if the models / process and practices that are adherent, but are not mitigated techniques of implementation of these.
ISO / IEC 14764: 2006 complies with the following elements E1, E2, E3, E4, E5 and E6.The element E1 is partially attended, because for the implantation of this model the team must know the products and the types of maintenances that must be realized in these.The E2 element is met by the standard, since the maintenance process of software in a company is initiated through a request, another factor that attends the communication is the fact that in the implementation stage of the execution of the process the maintenance team must perform a Communicate with the customer and maintain feedback.The E3 Element is one of Norma's main goals, as it relies on all software maintenance processes, making it a complete flow for service in that industry.Through the standard it is also possible to manage maintenance activities, where all activities have inputs, controls and outputs, so this standard will meet element E4.
The controls provide guidance to ensure that maintenance activity produces correct outputs.In relation to the costs raised through Element 5, the standard makes a control for cost estimation before executing the maintenance process, that is, since it is only an estimate, it partially meets this element.Documentation management is one of the main activities within each stage of the standard because every change in the system or development requirements must be recorded and maintained a history of such documentation.
The elements E7, E8 and E9 are not met by the standard, since the Norma does not offer tools to aid in software development, HelpDesk and management.According to reports in the literature it is possible to raise the use of tools that assist companies in the development, management and support.According to (Tsunoda and Ono, 2014) and (Poklemba et al., 2009), the aid of a tool for system maintenance and support is essential for a construction of a dataset so that it can analyze through the maintenance phase planning reports and project support from software companies.

E3
Define the whole software maintenance process in the company.
Knowledge of the process applied by the company and execution of the same.
Keep up the current process your request.

E4
It should ensure the management of all activities related to software maintenance.Must be aware of all activities.Not applicable

E5
The estimated costs related to hours worked in software maintenance / correction should be performed.
Have the necessary knowledge to evaluate the estimated hours to perform certain maintenance.
You should receive the estimated hours / costs of your request.

E6
It should be ensured that all documentation related to the development and maintenance is carried out.
All changes must be recorded in the documentation.Not applicable

E7
One should ensure a tool for managing HelpDesk calls.
Must have knowledge to analyze calls and report each step.
You should see the entire flow of your request.

E8
Ensure the help of development tools that facilitate the code for later maintenance.
Knowledge of using and supporting this tool for development.
Not applicable

E9
Ensure the assistance of management tools such as CMMS for software maintenance activities.
Knowledge of using and supporting these tools for their activities.
Not applicable

CONCLUSIONS
This paper presents the case study of an organization, whose problems in software maintenance are aggravated by the lack of a process for such activities and tasks within a business context.It was evidenced that such problems directly interfere in the software maintenance activity, generating lack of planning, high cost, overloading of tasks, and failure to communicate with the users of these systems.In addition, a systematic mapping was carried out to show through the literature reports processes and activities that support the maintenance of software in companies.
With this study, it was possible to perceive the flaws in the software maintenance process of the company, since it also made it possible to visualize what needs to be improved so that this maintenance is carried out successfully and that the product is delivered to the highest quality possible.
After the analysis presented in Section V (results analysis), we conclude that no process, a practice identified in the literature through systematic mapping, has fully addressed the problem reported in the case study, and it is necessary to create a model or strategy that can help Company in this area.

FUTURE WORKS
It is suggested as future work the elaboration of a strategy of improvement in the Company, as well as an elaboration with the employees and managers, of a plan for non-invasive implantation.The carrying out of further case studies with the purpose of further contributing to the enrichment of the software maintenance process.

Table 3 .
Identified elements

Table 4 .
Elements with authors