SOFTWARE MAINTENANCE 1

SOFTWARE MAINTENANCE 1

Software Maintenance Software maintenance is often considered to be an unpleasant, time consuming, expensive and unrewarding occupation - something that is carried out at the end of development only when absolutely necessary 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 Modifying a program after it has been put into use Maintenance management is concerned with planning and predicting the process of change Configuration management is the management of products undergoing change. 2

Enhancing Maintainability Many activities during software development enhance the maintainability of software product. Analysis activities Standards and guidelines Design activities Implementation activities Supporting documents From maintenance view point, the most important activities that occur during analysis are establishing standards and guidelines for the project and the work products to ensure uniformity of the products, setting of milestones to ensure that the work products are produced on schedule, specifying quality assurance etc. 3

Software maintenance may be performed by the developing organization, by the customer, or by a third party on behalf of the customer. In any case the customer must be given an estimate of the resources required and likely costs to be incurred in maintaining the system. Standards and guidelines: various types of standards and guidelines can be developed to enhance the maintainability of software. Standard formats for requirements documents and design specifications, structured coding conventions and standardized formats for the supporting documents like users manual etc will contribute to the understandability and hence maintainability of the software. Standards can be specified by the software quality group. 4

Design activities: Architectural design is concerned with developing the functional components, conceptual data structures and interconnections in software system. Detailed design is concerned with specifying algorithmic details, concrete data representations and details of the interfaces among routines and data structures. Implementation activities: Implementation, like design, should have the primary goal of producing software that is easy to understand and easy to modify. Supporting documents: Maintenance guide and test suite description are the two important supporting documents that should be prepared during the software development cycle in order to ease maintenance activities. 5

Managerial Aspects of Software Maintenance Successful software maintenance, like all software engineering activities, requires a combination of managerial skills and technical expertise. One of the most important aspects of software maintenance involves tracking and control of maintenance activities. Maintenance activity for a software product usually occurs in response to a change request filed by a user of the product. Change requests are usually initiated by users. A change request may entail enhancement, adaptation or error correction. A change request is first reviewed by an analyst, either closes the change request or submits to the control board the change request, the proposed fix, and an estimate of the resources required to satisfy the request. 6

Managerial Aspects of Software Maintenance Change control board: The control board reviews and approves all change requests. The board may deny, recommend a modified version of change, or approve the change as submitted. The analyst provides liaison between the change control and the request initiator. Approved changes are forwarded to the maintenance programmers for action in accordance with the priority and constrains established by the change control board. The software is modified, revalidated and submitted to the change control board for approval. If the change control board approves, the master tapes and external documents are updated to reflect the changes, and the modified software is distributed to user sites as specified by the control board. 7

Managerial Aspects of Software Maintenance Change Request Summaries: The status of the change requests and software maintenance activities should be summarized on a weekly or monthly basis. The summary should report emergency problems and temporary fix in effect since the last report; new change requests received and their probable dispositional ole open requests, along with the status of progress and probable closing date for each; and change requests that have been closed since the last summary report, including a description of each closed request and its disposition. In addition, a maintenance trends summary should be included in each change request summary; a trends summary graph showing the number of new requests and the total number of open requests as a function of time. 8

Managerial Aspects of Software Maintenance Quality Assurance Activities: The quality assurance group should conduct audits and spots checks to determine that external documents are properly updated to reflect modifications. Quality assurance group monitors change requests, prepares change request summaries, performs regression testing of software modifications, provides configuration management, and retains and protects the physical media for software products. The group should be represented on the change control board and should have sign-off authority for new releases of modified software products. Change control is administered by quality assurance personnel. 9

Managerial Aspects of Software Maintenance Organizing maintenance programmers: Software maintenance can be performed by the development team or my members of separate organization. There are advantages and disadvantages to both approaches. Members of the development team will be intimately familiar with the product; they will understand the design philosophy of the system and why it functions as it does. Also they will take great care to design and implement the system to enhance maintainability. On the other hand they will probably be less careful in preparing the supporting documentation. Also they may be assigned to new project while retaining the responsibility for maintenance of the released product. 10

Managerial Aspects of Software Maintenance Maintenance by a separate group forces more attention to standards and high quality documentation. It is also has the advantage of releasing the development team to pursue other activities. They can become highly expert on various details of the product because they devote their full attention to the product. However, a morale problem associated with maintenance programming, and rightly or wrongly a stigma is often associated with being a “maintenance programmer”. A desirable method of organizing maintenance programming is to periodically rotate programmers between development and maintenance. 11

Configuration Management Configuration management is concerned with tracking and controlling of the work products that constitute a software product. Software tools to support configuration management include configuration management data base and version control. A configuration management data base can provide information concerning product structure, current revision number, current status and change request history for each product version. A version control library may be part of a configuration management data base or it may be used as a stand-alone tool. 12

Source-Code Metrics A software metric is a measure of some property of a piece of software or its specifications. Most of the metrics incorporate easily computed properties of the source code, such as the number of operators and operands, the complexity of the control flow graph, the number of parameters and global variables in routines and the number of levels and manner of interconnection of call graph. The approaches taken to compute a number or set of numbers that measures the complexity of the code. Thus a program with measure 10 would be more complex than a program with measure 5. 13

The maintenance process Maintenance is triggered by change requests from customers or marketing requirements Changes are normally batched and implemented in a new release of the system Programs sometimes need to be repaired without a complete process iteration but this is dangerous as it leads to documentation and programs getting out of step 14

The maintenance process Change requests Impact analysis System release planning Change implementa tion Perfective maintenance Adaptive maintenance Corrective maintenance System release 15

Change processes Change requests Analyze source code Modify source code Deliver repaired system Fault repair process Change requests Change analysis Requirements updating Software development Iterative development process 16

System documentation Requirements document System architecture description Program design documentation Source code listings Test plans and validation reports System maintenance guide 17

Maintainer corrects problems and makes improvem ents Users Interact with the System Users Identify Proble ms & Improv ements The Maintenance Lifecycle 18

Types of Software Maintenance In order for a software system to remain useful in its environment it may be necessary to carry out a wide range of maintenance activities upon it. Swanson (1976) was one of the first to examine what really happens during maintenance and was able to identify three different categories of maintenance activity: 19

Corrective Changes necessitated by actual errors (defects or residual "bugs") in a system are termed corrective maintenance. These defects manifest themselves when the system does not operate as it was designed or advertised to do. 20

Adaptive Any effort that is initiated as a result of changes in the environment in which a software system must operate is termed adaptive change. Adaptive change is a change driven by the need to accommodate modifications in the environment of the software system, without which the system would become increasingly less useful until it became obsolete. 21

Perfective The third widely accepted task is that of perfective maintenance. This is actually the most common type of maintenance encompassing enhancements both to the function and the efficiency of the code and includes all changes, insertions, deletions, modifications, ex tensions, and enhancements made to a system to meet the evolving and/or expanding needs of the user. A successful piece of software tends to be subjected to a succession of changes resulting in an increase in its requirements. This is based on the premise that as the software becomes useful, the users tend to experiment with new cases beyond the scope for which it was initially developed. Expansion in requirements can take the form of enhancement of existing system functionality or improvement in computational efficiency. 22

Preventive The long-term effect of corrective, adaptive and perfective change is expressed in Lehman's law of increasing entropy: As a large program is continuously changed, its complexity, which reflects deteriorating structure, increases unless work is done to maintain or reduce it. 23

Distribution of maintenance effort Corrective maintenance (17%) Adaptive maintenance (18%) Perfective maintenance (65%) 24

SOFTWARE PROCESS AND PROJECT METRICS 25

Software process and project metrics are quantitative measures that enable software engineers to gain insight into the efficiency of the software process and the projects conducted using the process framework. In software project management, we are primarily concerned with productivity and quality metrics. The four reasons for measuring software processes, products, and resources (to characterize, to evaluate, to predict, and to improve). Software metrics refers to a broad range of measurements for computer software. Measurement can be applied to the software process with the intention of improving it on a continuous basis. Measurement can be used throughout the software project to assist in estimation, quality control, etc 26

Within the context of software project management, we are concerned primarily with productivity and quality metrics. Measures, Metrics, and Indicators Measure: provides a quantitative indication of the size of some product or process attribute Measurement: is the act of obtaining a measure Metric: is a quantitative measure of the degree to which a system, component, or process possesses a given attribute. Indication: is a metric or combination of metrics that provide insight into software process, a software project or the product itself. 27

Metrics in the process and project domains Measurement is common place in the engineering world. Metrics should be collected so that process and product indicators can be ascertained. Process indicators enables a software engineering organization to gain insight into the efficacy of an existing process. ie Process indicators enable software project managers to: assess project status, track potential risks, detect problem area early, adjust workflow or tasks, and evaluate team ability to control product quality 28

Process Metrics Private process metrics (e.g. defect rates by individual or module) are known only to the individual or team concerned. Public process metrics enable organizations to make strategic changes to improve the software process. Metrics should not be used to evaluate the performance of individuals. Statistical software process improvement helps and organization to discover where they are strong and where are week. 29

Process Metrics Number of requests for corrective maintenance Average time required for impact analysis Average time taken to implement a change request Number of outstanding change requests If any or all of these is increasing, this may indicate a decline in maintainability 30

Project Metrics Software process metrics are used for strategic purpose, project measures are tactical. Project metrics, and the indicators derived from them are used by a PM and a software team to adapt project work flow and technical activities Software project metrics are used by the software team to adapt project workflow and technical activities. Project metrics are used to avoid development schedule delays, to mitigate potential risks, and to assess product quality on an ongoing basis. Every project should measure its inputs (resources), outputs (deliverables), and results (effectiveness of deliverables). 31

Software Measurement Measurement in the physical world can be categorized into two: Direct and Indirect. Software metrics can be categorized similarly. Direct measures of the software engineering process include cost and effort applied. Direct measures of the product includes lines of code produced, execution speed, memory size and defects reported over some set period of time. The cost and effort required to build the software, the number of code produced and other direct measures are relatively easy to collect as long as specific conventions for measurement are established in advance. 32

Software Measurement Indirect measures of the product include functionality, quality, complexity, efficiency, reliability, maintainability, and many other “ abilities”. Indirect measures are more difficult to assess Size Oriented Metrics Derived by normalizing (dividing) any direct measure (e.g. defects or human effort) associated with the product or project by LOC. Size oriented metrics are widely used but their validity and applicability is widely debated. 33

Function Oriented Metrics Function oriented metrics use a measure of the functionality delivered by the application as a normalization value. Since functionality cannot be measured directly, it must be derived indirectly using other direct measures Function points are computed from direct measures of the information domain of a business software application and assessment of its complexity. Once computed function points are used like LOC to normalize measures for software productivity, quality, and other attributes. 34

Extended Function Point Metrics Function point measure was originally designed to be applied to business information system application Feature points and 3D function points provide a means of extending the function point concept to allow its use with real-time and other engineering applications. The relationship of LOC and function points depends on the language used to implement the software. 35