Environment for Managing Software Maintenance Projects

A Software Engineering Environment (SEE) is quite useful in order to manage the complexity of SM projects, since it can provide the needed services. Of the different aspects to highlight in these environments, in this chapter we put our main attention on those that are more directly related to the goal of helping in the management of SM complexity: to approach the SMP from a wide perspective of business processes to integrate technological and management aspects; to define a Process-centered Software Engineering Environment (PSEE); and to use a multilevel conceptual architecture based on standards like MOF (Meta-Object Facility). The MANTIS proposal of integral environment for the management of SM projects is also presented, and the main components of this environment are commented: conceptual tools (multilevel architecture, ontologies, software processes models and metamodels); methodological tools (methodology, and interfaces with organizational and managerial processes) and technical tools (horizontal and vertical software tools, repository, and interaction with process enactment software tools).

A Methodology for Software Maintenance

Software maintenance is the most expensive stage of the software life cycle. However, most software organizations do not use any methodology for maintenance, although they do use it for new developments. In this article, a methodology for managing the software maintenance process is presented. The methodology defines clearly and rigorously all the activities and tasks to be executed during the process and provides different sets of activities for five different types of maintenance (urgent and non-urgent corrective, perfective, preventive, and adaptive). In order to help in the execution of tasks, some techniques have been defined in the methodology. Also, several activities and tasks for establishing and ending outsourcing relationships are proposed, as well as several metrics to assess the maintainability of databases and their influence on the rest of the Information System. This methodology is being applied by Atos ODS, a multinational organization among whose primary business activities is the outsourcing of software maintenance.

The Impact of eXtreme Programming on Maintenance

One of the emerging techniques for managing software project is eXtreme Programming (XP), which surely is changing the way in which we develop and manage software. XP is based on four values and 12 rules that explain how to develop software in an XP-compliant mode. In this chapter, all values and rules are addressed and the XP lifecycle of a project is introduced in order to guide the reader in discovering how XP can aid maintenance by keeping maintenance costs constant over time. Before drawing conclusions, the direct impact on the maintenance process due to the adoption of XP values and rules is also exploited at the end of the chapter.

Enhancing Software Maintainability by Unifying and Integrating Standards

Software standards are highly recommended because they promise faster and more efficient ways for software development with proven techniques and standard notations. Designers who adopt standards like UML and design patterns to construct models and designs in the processes of development suffer from a lack of communication and integration of various models and designs. Also, the problem of implicit inconsistency caused by making changes to components of the models and designs will significantly increase the cost and error for the process of maintenance. In this chapter, an XML-based unified model is proposed to help to solve the problems and to improve both software development and maintenance through unification and integration.

Patterns in Software Maintenance

In software design, patterns—that is, structured, named descriptions of good solutions to common problems in context—have become a popular way of recording and transferring problem-solving expertise. The aim of this chapter is to describe how patterns can help in the field of software maintenance. There are two main uses of patterns in software maintenance. The first is to consider the introduction of a design pattern to an existing design. The second approach is to consider patterns for the maintenance process itself. For example, reengineering patterns describe solutions to common problems in the reengineering of a system, considering issues such as how to split the necessary changes into risk-minimizing steps. We discuss the advantages, pitfalls and practicalities of using patterns in both of these ways.

Software Maintenance Cost Estimation

This chapter deals with the subject of estimating the costs of software maintenance. It reviews the existing literature on the subject and summarises the various approaches taken to estimate maintenance costs starting with the original COCOMO approach in 1981. It then deals with the subject of impact analysis and why it is essential to estimate the scope of maintenance projects. Examples are given to illustrate this. It then goes on to describe some of the tools the author has developed in the past ten years to support his practice of maintenance project estimation including the tools SoftCalc and MainCost. For both of these tools empirical studies of industrial experiments are presented as proof of the need to automate the estimation process.

Requirements Risk and Maintainability

In order to continue to make progress in software measurement as it pertains to reliability and maintainability, we must shift the emphasis from design and code metrics to metrics that characterize the risk of making requirements changes. By doing so we can improve the quality of delivered software, because defects related to problems in requirements specifications will be identified early in the life cycle. We provide an approach for identifying requirements change risk factors as predictors of reliability and maintainability problems. Our case example consists of twenty-four Space Shuttle change requests, nineteen risk factors, and the associated failures and software metrics. The approach can be generalized to other applications with numerical results that would vary according to application.

Migrating Legacy System to the Web

The Internet is an extremely important new technology that is changing the way in which organizations conduct their business and interact with their partners and customers. To take advantage of the Internet open architecture, most companies are applying business reengineering with the aim of moving from hierarchical centralized structures to networked decentralized business units cooperating with one another. As a consequence, the way in which software information systems are conceived, designed, and built is changing too. Monolithic, mainframe-based systems are being replaced by distributed, Web-centric, component-based systems with an open architecture. Ideally, business process reengineering should entail the adoption of new software systems designed to satisfy the new needs of the redesigned business. However, economic and technical constraints make it impossible in most cases to discard the existing and legacy systems and develop replacement systems from scratch. Therefore, legacy system migration strategies are often preferred to replacement. This entails that a balance must be struck between the constraints imposed by the existing legacy systems and the opportunities offered by the reengineering of the business processes.

Software Maintenance and Organizational Health and Fitness

This chapter sets out a foundation for the management of software maintenance. The foundation highlights a fundamental for managing software maintenance effectively—recognition of the connection between managing change in organizations and the organizations’ health and fitness. The changes arising as a consequence of software maintenance nearly always impair or improve that health and fitness. The basis for that impact lies in how business rules contribute to the performance of systems, and in how systems contribute to the performance of organizations. An understanding and application of how changes from software maintenance on business rules and systems affect the performance of organizations provides a basis for management action. With that added confidence, managers can reduce impairing their organizations’ health and fitness and can increase positive action to improve their organizations’ health and fitness via software maintenance.

Problem Management within Corrective Maintenance

Problem management is the dominating process within corrective maintenance. It not only handles software problems but also provides quantitative feedback important for assessing product quality, crucial for continuous process analysis and improvement and essential for defect prevention. Chapter 2 gives a detailed description of the problem management process and its constituent phases, activities, and roles involved. It also provides (1) general definitions on the basic terminology utilized within corrective maintenance, (2) roadmaps visualizing the corrective maintenance from different perspectives, (3) general descriptions of the most important issues within support (upfront maintenance) process – the process tightly collaborating with the problem management process, and finally, (4) it gives a glimpse into Corrective Maintenance Maturity Model (CM3): Problem Management – a process model specialized to only problem management process within corrective maintenance.