Problem in software maintenance

Impact analysis is performed after a change request enters the software configuration management process. IEEE states the impact analysis tasks:.

The severity of a problem is often used to decide how and when it will be fixed. The software engineer then identifies the affected components. Several potential solutions are provided, followed by a recommendation as to the best course of action. Software designed with maintainability in mind greatly facilitates impact analysis.

Modifications may include corrections, improvements, or adaptation of the software to changes in environment as well as changes in requirements and functional specifications. As a primary software quality characteristic, maintainability should be specified, reviewed, and controlled during software development activities in order to reduce maintenance costs.

Maintainability is often difficult to achieve because the subcharacteristics are often not an important focus during the process of software development. This in turn can, and often does, result in a lack of software documentation and test environments, which is a leading cause of difficulties in program comprehension and subsequent impact analysis. The presence of systematic and mature processes, techniques, and tools helps to enhance the maintainability of software.

Organizational objectives describe how to demonstrate the return on investment of software maintenance activities. Initial software development is usually project-based, with a defined time scale and budget. The main emphasis is to deliver a product that meets user needs on time and within budget. In contrast, software maintenance often has the objective of extending the life of software for as long as possible.

In addition, it may be driven by the need to meet user demand for software updates and enhancements. In both cases, the return on investment is much less clear, so that the view at the senior management level is often that of a major activity consuming significant resources with no clear quantifiable benefit for the organization.

Staffing refers to how to attract and keep software maintenance staff. Maintenance is not often viewed as glamorous work. The software life cycle process is a set of activities, methods, practices, and transformations that people use to develop and maintain software and its associated products.

At the process level, software maintenance activities share much in common with software development for example, software configuration management is a crucial activity in both.

Maintenance also requires several activities that are not found in software development see section 3. These activities present challenges to management. The team that develops the software is not necessarily assigned to maintain the software once it is operational.

In deciding where the software maintenance function will be located, software engineering organizations may, for example, stay with the original developer or go to a permanent maintenance- specific team or maintainer. Having a permanent maintenance team has many benefits:. Since there are many pros and cons to each option, the decision should be made on a case-bycase basis. Outsourcing and offshoring software maintenance has become a major industry.

Organizations are outsourcing entire portfolios of software, including software maintenance. More often, the outsourcing option is selected for less mission-critical software, as organizations are unwilling to lose control of the software used in their core business.

One of the major challenges for outsourcers is to determine the scope of the maintenance services required, the terms of a service- level agreement, and the contractual details. Outsourcers will need to invest in a maintenance infrastructure, and the help desk at the remote site should be staffed with native-language speakers. Outsourcing requires a significant initial investment and the setup of a maintenance process that will require automation.

Software engineers must understand the different categories of software maintenance, discussed above, in order to address the question of estimating the cost of software maintenance. For planning purposes, cost estimation is an important aspect of planning for software maintenance. Section 2. Maintenance cost estimates are affected by many technical and nontechnical factors.

A combination of these two can also be used. Parametric cost modeling mathematical models has been applied to software maintenance. Of significance is that historical data from past maintenance are needed in order to use and calibrate the mathematical models. Cost driver attributes affect the estimates.

Experience, in the form of expert judgment, is often used to estimate maintenance effort. Clearly, the best approach to maintenance estimation is to combine historical data and experience. The cost to conduct a modification in terms of number of people and amount of time is then derived. Maintenance estimation historical data should be provided as a result of a measurement program.

There are several software measures that can be derived from the attributes of the software, the maintenance process, and personnel, including size, complexity, quality, understandability, maintainability, and effort.

Complexity measures of software can also be obtained using available commercial tools. Discussion of software process and product measurement is also presented in the Software Engineering Process KA. The software quality model suggests measures that are specific for software maintenance. Providing software maintenance effort, by categories, for different applications provides business information to users and their organizations.

It can also enable the comparison of software maintenance profiles internally within an organization. In addition to standard software engineering processes and activities described in IEEE , there are a number of activities that are unique to maintainers.

However, they may also be used to keep a manager focused on all aspects of maintenance. An example of an Ishikawa diagram of lube oil system strainer basket failures. The Ishikawa diagram helps you focus on the different aspects of a problem so the listed causes will not be concentrated in one or two areas.

For instance, most problems can be broken down into four areas: personnel, maintenance practices, hardware and systems. Some problems may be divisible into more than four, but with some imagination, most should yield at least these four. These categories force you to look at a situation from multiple perspectives to generate possible causes. Some refer to these diagrams as fishbone diagrams or cause-and-effect C-E diagrams.

They encourage you to list as many causes as possible. To do this, you must withhold judgment until the listing is complete to assure no one jumps to conclusions. By contrast, the Kepner-Tregoe method relies on describing what the problem is, what it is not, where it occurs and where it does not. In effect, you are building a fence around the problem to keep important information inside and under review while keeping out extraneous information.

Your main thrust is to identify what has changed. The true cause will account for all effects. If one effect could not be caused by the selected cause, that cause must be discarded.

Prevention requires maintenance management to develop a new mindset and make a conscious decision to move away from fighting fires. By understanding the four basic types of maintenance problems, the different levels of problem-solving and the three categories of objectives, you will be better prepared to achieve this new mindset.

We encourage you to read our updated Privacy Policy Hide. Toggle navigation Toggle search. Magazine Subscribe Today! Current Issue Archive Advertise. Problems vs. Difficulties A problem is a situation that can be characterized by a gap between your existing circumstances and where you do or do not want to be. Where Maintenance Issues Originate Issues are caused by your goals or a lack of them. Levels of Problem-solving In addition to recognizing the four problem types, you must also be aware that problem-solving can be divided into four levels of sophistication: reaction or acting on the problem when it occurs and then forgetting about it until the next time; adaptation or learning to live with the problem by adjusting to the symptoms; anticipation, which includes attacking root causes with preventive techniques; and a proactive approach, which involves changing the conditions that spawned the problem in the first place.

Categories of Objectives Your objectives will determine the problems you experience. When language C came into existence, Unix was re-engineered in C, because working in assembly language was difficult.

Other than this, sometimes programmers notice that few parts of software need more maintenance than others and they also need re-engineering. It is a process to achieve system specification by thoroughly analyzing, understanding the existing system. This process can be seen as reverse SDLC model, i. An existing system is previously implemented design, about which we know nothing.

Designers then do reverse engineering by looking at the code and try to get the design. With design in hand, they try to conclude the specifications.

Thus, going in reverse from code to system specification. It is a process to re-structure and re-construct the existing software. It is all about re-arranging the source code, either in same programming language or from one programming language to a different one.

Restructuring can have either source code-restructuring and data-restructuring or both. Re-structuring does not impact the functionality of the software but enhance reliability and maintainability. Program components, which cause errors very frequently can be changed, or updated with re-structuring. Forward engineering is a process of obtaining desired software from the specifications in hand which were brought down by means of reverse engineering.

It assumes that there was some software engineering already done in the past. Forward engineering is same as software engineering process with only one difference — it is carried out always after reverse engineering. A component is a part of software program code, which executes an independent task in the system.

It can be a small module or sub-system itself. The login procedures used on the web can be considered as components, printing system in software can be seen as a component of the software. Components have high cohesion of functionality and lower rate of coupling, i. In OOP, the objects are designed are very specific to their concern and have fewer chances to be used in some other software. Save to Library Save. Create Alert Alert. Share This Paper. Background Citations. Methods Citations. Topics from this paper.

Software maintenance. Citation Type. Has PDF. Publication Type.