Lovely Professional University

TERM PAPER OfPrinciples of Software Engineering

TOPIC: - CSM [Categories of Software Maintenance]

Submitted to: Submitted by:

Ms. Shaina Dhingra Pramod Ku.Tiwari Lecturer, LSM Roll no. - B44 LPU Reg.No-10901147

Anu Chauhan Roll no.- B48 Reg.No-10902214 Sec. - S1906 MBA-IT

Index

1. Declaration Page no: 3

2. Acknowledgement Page no: 4

3. Preface Page no: 5

4. Introduction Page no: 6

5. Categories of Software maintenance Page no: 6

6. The Significance of Software Maintenance Page no: 7

7. Process of Software Maintenance Page no: 8

8. Maintenance Management Page no: 10

9. Reverse Engineering Page no: 12

10. Re-Engineering Page no: 12

11. Legacy System Page no: 13

12. Waterfall Model Page no: 14

13. Conclusion Page no: 22

14. References Page no: 23

DECLARATION

I, Pramod Kumar Tiwari & Anu Chauhan student of Lovely Professional University have completed the Project on: CSM: Categories of Software Maintenance The information given in this project is true to the best of my knowledge.

(PRAMOD Ku. TIWARI) (ANU CHAUHAN)

ACKNOWLEDGEMENT

First of all I would like to thank the Lovely Professional University and take the opportunity to do this project as a part of the MBA-IT.

Many people have influenced the shape and content of this project, and many supported me through it. I express my sincere gratitude to Ms. Shaina Dhingra for assigning me a project on Principles of Software Engineering, which is an interesting and exhaustive subject.

He has been an inspiration and role model for this topic. His guidance and active support has made it possible to complete the assignment.

I also would like to thank my Friends who have helped and encouraged me throughout the working of the project. Last but not the least I would like to thank the Almighty for always helping me.

PREFACE

This project is undertaken to fulfil the project work component of the M.B.A programme in 2nd Semester. My project guide from L.P.U is Lect. Ms. Shaina Dhingra.

This term paper is based on the Computer and Introduction of the CSM .

INTRODUCTION-

Software Development has many phases. These phases include Requirements Engineering, Architecting, Design, Implementation, Testing, Software Deployment, andMaintenance. Maintenance is the last stage of the software life cycle. After the producthas been released, the maintenance phase keeps the software up to date with environmentchanges and changing user requirements.

“Software maintenance is the process of modifying a software system or component after delivery to correct faults, improve performances or other attributes, or adapt to a changed environment.”

“Software maintenance is the totality of activities required to provide cost-effective support to a software system. Activities are performed during the pre-delivery stage as well as the post-delivery stage. Pre-delivery activities include planning for post deliveryoperations, supportability, and logistics determination. Post-delivery activities include software modification, training, and operating a help desk.”

DESCRIPTION OF THE NATURE OF THE PHASE-

This section will cover what the software maintenance phase is about. As briefly seen inthe introduction, software maintenance is not limited to the correction of latent faults. The term software maintenance usually refers to changes that must be made to software after they have been delivered to the customer or user. The definition of software maintenance by IEEE is as follows:The modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment. The following subsections will discuss different types of software maintenance, the significance and the characteristics of software maintenance.

CATEGORIES OF SOFTWARE MAINTENANCE-

There are four types of maintenance according to Lientz and Swanson: 1. Corrective Maintenance.

2. Adaptive Maintenance.3. Perfective Maintenance

4. Preventive Maintenance.

1. CORRECTIVE MAINTENANCE :

Corrective maintenance deals with the repair of faults or defects found. A defect canresult from design errors, logic errors and coding errors .

Design errors occur when, for example, changes made to the software are incorrect,incomplete, wrongly communicated or the change request is misunderstood.

2. ADAPTIVE MAINTENANCE :

Adaptive maintenance consists of adapting software to changes in the environment, such as the hardware or the operating system. The term environment in this context refers to the totality of all conditions and influences which act from outside upon the system, for example, business rule, government policies, work patterns, software and hardware operating platforms.

3. PERFECTIVE MAINTENANCE :

Perfective maintenance mainly deals with accommodating to new or changed user requirements. Perfective maintenance concerns functional enhancements to the system and activities to increase the system’s performance or to enhance its user interface. A successful piece of software tends to be subjected to a succession of changes, resulting in an increase in the number of requirements. Examples of perfective maintenance include modifying the payroll program to incorporate a new union settlement, adding a new report in the sales analysis system,improving a terminal dialogue to make it more user-friendly, and adding an online help command .

4. PREVENTIVE MAINTENANCE :

Preventive maintenance concerns activities aimed at increasing the system’s maintainability, such as updating documentation, adding comments, and improving the modular structure of the system. The long-term effect of corrective, adaptive and perfective changes increases the system’s complexity. Software evolution is now widely used in the software maintenance community. For example, The Journal of Software Maintenance added the term ‘evolution’ to its title to reflect this transition.

THE SIGNIFICANCE OF SOFTWARE MAINTENANCE-

As software systems age, it becomes increasingly difficult to keep them ‘up and running’without maintenance. The following stories show the significance of the software maintenance phase in the software development life cycle.

COSTS AND CHALLENGES :

However one decides to categorize the maintenance effort, it is still clear that software maintenance accounts for a huge amount of the overall software budget for an information system organization. Software maintenance was characterized as an “iceberg” to highlight the enormous mass of potential problems and costs that lie under the surface. Although figures vary, several surveys [1, 2, 7, 10, 34, 46, 54, 56, 58] indicate that software maintenance consumes 60% to 80% of the total life cycle

costs; these surveys also report that maintenance costs are largely due to enhancements (often 75–80%), rather than corrections.Several technical and managerial problems contribute to the costs of software maintenance. Among the most challenging problems of software maintenance are: program comprehension, impact analysis, and regression testing.

One of the major challenges in software maintenance is to determine the effects of a proposed modification on the rest of the system. Impact analysis [6, 64, 35, 81] is the activity of assessing the potential effects of a change with the aim of minimizing unexpected side effects. The task involves assessing the appropriateness of a proposed modification and evaluating the risks associated with its implementation, including estimates of the effects on resources, effort and scheduling. It also involves the identification of the system’s parts that need to be modified as a consequence of the proposed modification. Of note is that although impact analysis plays a central role within the maintenance process, there is no agreement about its definition and the IEEE Glossary of Software Engineering Terminology [40] does not give a definition of impact analysis.

MODEL-

A typical approach to software maintenance is to work on code first, and then making the necessary changes to the accompanying documentation, if any. This approach is captured by the quick-fix model, shown in figure 4, which demonstrates the flow of changes from the old to the new version of the system [8]. Ideally, after the code has been changed the requirement, design, testing and any other form of available documents impacted by the modification should be updated. However, due to its perceived malleability, users expect software to be modified quickly and cost-effectively. Changes are often made on the fly, without proper planning, design, impact analysis, and regression testing. Documents may or may not be updated as the code is modified; time and budget pressure often entails that changes made to a program are not documented and this quickly degrades documentation. In addition, repeated changes may demolish the original design, thus making future modifications progressively more expensive to carry out.

PROCESSES-

Several authors have proposed process models for software maintenance. These modelsorganize maintenance into a sequence of related activities, or phases, and define the order in which these phases are to be executed. Sometimes, they also suggest the deliverables that each phase must provide to the following phases.

IEEE and ISO have both addressed software maintenance, the first with a specific standard and the latter as a part of its standard on life cycle processes. The next two sections describe the maintenance processes defined by these two documents.

1- IEEE-1219 : The IEEE standard organizes the maintenance process in seven phases, as demonstrated in figure. In addition to identifying the phases and their order of execution, for each phase the standard indicates input and output deliverables, the activities grouped, related and supporting processes, the control, and a set of metrics. The phase also includes activities to determine whether to accept or reject the request and to assign it to a batch of modifications scheduled for implementation.

ANALYSIS : This phase devises a preliminary plan for design, implementation, test, and delivery. Analysis is conducted at two levels: feasibility analysis and detailed analysis. Feasibility analysis identifies alternative solutions and assess their impacts and costs, whereas detailed analysis defines the requirements for the modification, devises a test strategy, and develop an implementation plan.

DESIGN : The modification to the system is actually designed in this phase. This entails using all current system and project documentation, existing software and databases, and the output of the analysis phase. Activities include the identification of affected software modules, the modification of software module documentation, the creation of test cases for the new design, and the identification of regression tests.

IMPLEMENTATION : This phase includes the activities of coding and unit testing, integration of the modified code, integration and regression testing, risk analysis, and review. The phase also includes a test-readiness review to asses preparedness fort system and regression testing.

REGRESSION/SYSTEM TESTING :This is the phase in which the entire system is

tested to ensure compliance to the original requirements plus the modifications. In addition to functional and interface testing, the phase includes regression testing to validate that no new faults have been added. Finally, this phase is responsible for verifying preparedness for acceptance testing.

DELIVERY : This is the phase in which the modified systems is released for

installation and operation. It includes the activity of notifying the user community, performing installation and training, and preparing and archival version for backup.

2- ISO-12207-

While the standard IEEE-1219 is specifically concerned with software maintenance, the standard ISO-12207 deals with the totality of the processes comprised in the software life cycle. The standard identifies seventeen processes grouped into three broad classes: primary, supporting, and organizational processes. Processes are divided into constituent activities each of which is further organized in tasks.

PROCESS IMPLEMENTATION : This activity includes the tasks for developing plans and procedures for software maintenance, creating procedures for receiving, recording, and tracking maintenance requests, and establishing an organizational interface with the configuration management process.

PROBLEM AND MODIFICATION ANALYSIS : The first task of this activity is concerned with the analysis of the maintenance request, either a problem report or a modification request, to classify it, to determine its scope in term of size, costs, and time required, and to assess its criticality. It is recommended that the maintenance organization replicates the problem or verifies the request. The other tasks regard the development and the documentation of alternatives for change implementation and the approval of the selected option as specified in the contract.

MODIFICATION IMPLEMENTATION : This activity entails the identification of the items that need to be modified and the invocation of the development process to actually implement the changes. Additional requirements of the development process are concerned with testing procedures to ensure that the new/modified requirements are completely and correctly implemented and the original unmodified requirements are not affected.

MAINTENANCE REVIEW/ACCEPTANCE : The tasks of this activity are devoted to assessing the integrity of the modified system and end when the maintenance organization obtain the approval for the satisfactory completion of the maintenance request. Several supporting processes may be invoked, including the quality assurance process, the verification process, the validation process, and the joint review process.

SOFTWARE RETIREMENT : The last maintenance activity consists of retiring a software system and requires the development of a retirement plan and its notification to users.

MAINTENANCE MANAGEMENT-

Management is “the process of designing and maintaining an environment in which

individuals, working together in groups, accomplish efficiently selected aims” . In the case of maintenance the key aim is to provide cost-effective support to a software system during its entire lifespan. Management is concerned with quality and productivity, that imply effectiveness and efficiency. Management consists of five separate functions- planning, organizing, staffing, leading and controlling.

PLANNING : Planning consists of selecting missions and objectives and predetermining a course of actions for accomplishing them. Commitment of human and material resources and scheduling of actions are among the most critical activities in this function.

ORGANIZING : Organizing is the management function that establishes an intentional structure of roles for people to fill in an organization. This entails arranging the relationships among roles and granting the responsibilities and needed authority.

STAFFING : Staffing involves filling the positions in the organization by selecting and training people. Two key activities of this function are evaluating and appraising project personnel and providing for general development, i.e. improvement of knowledge, attitudes, and skills.

LEADING : Leading is creating a working environment and an atmosphere that will assist and motivate people so that they will contribute to the achievement of organization and group goals.

CONTROLLING : Controlling measures actual performances against planned goals and, in case of deviations, devises corrective actions. This entails rewarding and disciplining project personnel.

Software maintenance organizations can be designed and set up with three different organizational structures: functional, project, or matrix.

FUNCTIONAL ORGANIZATIONS : Functional organizations are hierarchical nature. The maintenance organization is broken down into different functional units, such as software modification, testing, documentation, quality assurance, etc. Functional organizations present the advantage of a centralized organization of similar specialized resources.

PROJECT ORGANIZATIONS : Project organizations are the opposite of the functional organizations. In this case a manager is given the full responsibility and authority for

conducting the project; all the resources needed for accomplishing the project goals are separated from the regular functional structure and organized into an autonomous, self-contained team. The project manager may possibly acquire additional resources from outside the overall organization.

MATRIX ORGANIZATIONS : Matrix organizations are a composition of functional and project organizations with the objective of maximizing the strengths and minimizing the weaknesses of both types of organizations. Figure 15 shows a matrix organization; the standard vertical hierarchical organization is combined with an horizontal organization for each project. The strongest point of this organization is that a balance is struck between the objectives of the functional departments and those of the projects. The main problem is that every person responds to two managers, and this can be a source of conflicts. A solution consists of specifying the roles, responsibility and authority of the functional and project managers for each type of decisions.

REVERSE ENGINEERING-

Software reverse engineering originated in software maintenance. Reverse engineering as a process is difficult to define in rigorous terms because it is a new and rapidly evolving field. Traditionally, reverse engineering has been viewed as a two step process: information extraction and abstraction. Information extraction analyses the subject system artifacts – primarily the source code – to gather row data, whereas information abstraction creates user-oriented documents and views. Tilley and Paul propose a preliminary step that consists of constructing domain-specific models of the system using conceptual modeling techniques.

The IEEE Standard for Software Maintenance suggests that the process of reverse engineering evolves though six steps: dissection of source code into formal units; semantic description of formal units and creation of functional units; description of links for each unit (input/output schematics of units); creation of a map of all units and successions of consecutively connected units (linear circuits); declaration and semantic description of system applications, and; creation of an anatomy of the system. The first three steps concern local analysis on a unit level (in the small), while the other three steps are for global analysis on a system level (in the large). Reverse engineering process into the following three sequential phases: Goals, Models, and Tools.

RE-ENGINEERING-

“Software Re-engineering is any activity that: (1) improves one’s understanding ofsoftware, or (2) prepares or improves the software itself, usually for increasedmaintainability, reusability, or evolvability.”

Software re-engineering has proven important for several reasons. Arnold identifies seven main reasons that demonstrate the relevance of re-engineering:“Re-engineering can help reduce an organization’s evolution risk;Re-engineering can help an organization recoup its investment in software;Re-engineering can make software easier to change;Re-engineering is a big business;Re-engineering capability extends CASE toolsets;Re-engineering is a catalyst for automatic software maintenance;Re-engineering is a catalyst for applying artificial intelligence techniques to solvesoftware re-engineering problems.”

LEGACY SYSTEM-

A scenario that highlights the high cost of software maintenance is legacy systems. These are systems developed over the past 20/30 years (or even more) to meet a growing demand for new products and services. They have typically been conceived in a mainframe environment using non-standard development techniques and obsolete programming languages. The structure has often been degraded by a long history of changes and adaptations and neither consistent documentation nor adequate test suites are available.

Four factors that have been successfully used to asses the value of a legacy system and make informed decisions are: obsolescence, deterioration, decomposability, and business value.

OBSOLESCENCE : Obsolescence measures the ageing of a system due to the progress of software and data engineering and the evolution of hardware/software platforms. Obsolescence induces a cost which results from not taking advantage of modern methods and technologies which reduce the burden of maintaining a system.

DETERIORATION : Deterioration measures the decreases of the maintainability of a system (lack of analyzability, modifiability, stability, testability, etc.) due to the maintenance operations the system has undergone in its lifespan. Deterioration directly affects the cost of maintaining a system.

DECOMPOSABILITY : Decomposability measures the identifiability and independence of the main components of a system. All systems can be considered as having three components: interfaces, domain functions, and data management services. The decomposability of a system indicates how well these components are reflected in its architecture.

BUSINESS VALUE :

Business Value measures the complexity of the business process and rules a system, or system’s component, implements and their relevance to achieve efficiency and efficacy in the business operation.

Waterfall model

Design

Specification

Software plansand requirements

Operation andMaintenance

Integration andTesting

Coding

Unscheduled Scheduled

Reactive Emergency Corrective Adaptive

Proactive Perfective

IEEE categories of software maintenance

ISO categories IEEE categories

Emergency maintenance

Problem resolution

Corrective maintenance interface modification

Adaptive maintenance

functional expansion orperformance improvement

perfective maintenance

The quick-fix Model

The iterative-enhancement Model

The full-reuse Model

An example of maintenance model

The IEEE Maintenance Process

The ISO Life Cycle Process

The ISO Maintenance Process

The Function of Project Management

A Functional Organizational

Reverse Engineering and Re-Engineering

A Life Cycle Model for legacy System

CONCLUSION-

This article has overviewed software maintenance, its strategic problems, and the available solutions. The underlying theme of the article has been to show that technical and managerial solutions exist that can support the application of high standards of engineering in the maintenance of software. Of course, there are open problems and more basic and applied research is needed both to gain a better understanding of software maintenance and to find better solutions.

Nowadays, the way in which software systems are designed and built is changing profoundly, and this will surely have a major impact on tomorrow’s software maintenance. Object technology, commercial-off-the-shelf products, computer supported cooperative work, outsourcing and remote maintenance, Internet/Intranet enabled systems and infrastructures, user enhanceable systems, are a few examples of areas that will impact software maintenance. Currently there is a debate on the nature and the essence of software maintenance. Indubitably, the traditional vision of software maintenance as a post-delivery activity dates back to the seventies and is strictly related to the waterfall life cycle models.

References:

http://en.wikipedia.org/wiki/Software_maintenance

http://www.google.co.in/url?sa=t&software maintenance

http://portal.acm.org/citation.cfm?id=859273

http://www.tethermedia.com/maintenance_projects.htm