Software Maintenance. Software Maintenance - Terminology u Software Maintenance –consists of the...

Software Maintenance

Software Maintenance- Terminology

Software Maintenance– consists of the activities required to keep a

software system operational and responsive after it is accepted and placed into production.

Software Evolution– a continuous change from a lesser, simpler, or

worse state to a higher or better state

Software Maintainer– person whose mission is to support existing

software systems

Software Maintenance Problems

Most computer programs are difficult and expensive to maintain

Software changes are poorly designed and implemented

The repair and enhancement of software often injects new bugs that must later be repaired

Relative Costs of Maintenance

3% Requirements definition3% Preliminary design5% Detailed design7% Implementation15% Testing67% Operations and Maintenance

Software Development and Maintenance Differences

– Constraints of an existing system»Changes must conform or be compatible with an

existing architecture, design and code constraints

– Shorter time frames»Development spans 1 or more years

Maintenance spans hours or up to 6 months

– Available test data»Development creates all test data from scratch

Maintenance uses existing test data with regression testing creating new data for the changes

Maintenance Categories

Corrective maintenance Adaptive maintenance Perfective maintenance (Preventative maintenance -

Pressman)

Corrective Maintenance

focuses on fixing defects is a reactive process

– i.e. defects generally need to be corrected either immediately or in the near future

Defects– refer to the system not performing as

originally intended or as specified in the requirements

Adaptive Maintenance

includes all work related to how the software functions– i.e. relates to enhancing software functionality

includes all changes to meet the evolving needs of the user and the environment– i.e. system changes, additions, insertions,

deletions, modifications, extensions and enhancements

Perfective Maintenance

includes all efforts to improve the quality of the software

includes restructuring code, creating and updating documentation, improving reliability or efficiency

Maintenance work in the above categories is often performed concurrently

The Maintenance Process

begins when a request for change is initiated by a user

ends when the system passes testing, is accepted by the user and is released for operation

in between there are many activities that must be planned and co-ordinated by use of

Change Management

Software Maintenance Process

Seven-step approach:Step 1 - Change ManagementStep 2 - Impact AnalysisStep 3 - System Release PlanningStep 4 - Design ChangesStep 5 - CodingStep 6 - TestingStep 7 - System Release

Software Maintenance Process ...

Step 1 - Change Management– to uniquely identify, describe and track

the status of each requested change– in an organisation

»change requests are recorded and tracked through all stages of the maintenance process in a Change Management Tracking System

»Project Management and QA receive information about the status of the Change Requests


Change Request »basic tool (manual or electronic) of change

management

»documents all information about changes

»updated throughout the maintenance process to help manage the system release for the analysis of the types and frequency of defects to communicate to maintainers, managers and

clients


Change Request Examples:

Severity Codes used are:

1: System is down or system outputs are causing catastrophic problems.

2: System is operational and can be manually overridden or ignored until a specific date.

3: Includes all repairs and enhancements that can be deferred until the next scheduled system release.

4: Includes all minor repairs or enhancements.


Step 2 - Impact Analysis

An Impact Analysis– identifies all systems/system products

affected by a change request developing an estimate of the resources needed to accomplish the change

Steps:1. Evaluate Change Requests

(In assignment the changes will be your Stage 2 Requirements)

2. Estimate Resources


Impact Analysis …

Aims:• to determine the scope of the requested

change for planning and implementation of the change

• to develop accurate estimates of resources• to analyse cost/benefits of the change• to communicate the complexity of the change


Impact Analysis ...1. Evaluate Change Requests

• look for potential impact on:• existing systems, other systems, hardware,

documentation, data structures and humans

• without analysis of the changes the change may insert defects that are not immediately apparent

Impact Analysis example exercise: refer Tutorial Notes


Impact Analysis ...

Evaluate Change Requests ...Problems:

»documentation doesn’t exist and must be created

»documentation is out of date or incorrect leading to incorrect design decisions


Impact Analysis ...2. Estimate Resources

In an organisation, a project manager must estimate:

– Number of people required to complete the system– The equipment required eg PCs, printers, copiers etc– Other facilities such as offices, support staff etc– Cost of the system etc

How is this done? - use Software Metrics


Impact Analysis ...To Estimate Resources need to know:

– Size of required changes measured as– LOC and/or– Function Points and/or– Proxies such as classes and routines

(Impact Analysis will give this information)

– Historical information– eg Productivity Rate, Average LOC per Routine

(Assignment Stage 1 will give you this information)

– Time required to complete the system changes– Size of system and productivity rate


Step 3 - System Release Planning Aims:

» to establish the schedule of system releases» to determine the contents of a system release

System Release/Version Description Document»describes the contents / timing of a system release»communicates between maintainers and users»used by operations to plan hardware, operational

procedures and backup procedures


Step 3 - System Release Planning ...Scheduled Releases

»the method of working changes so that work can be managed like a development project

Unscheduled Releases cause problems with:

the most important changes may not be done first training / documentation may not coincide with the

system release testing of the changes may not be adequate


Step 4 - Design Changes Aims:

» to develop a revised logical (system level) and physical (program level) design for the change

analyse and design the changes update the documentation update the configuration management system update the change request for management

»to design the changes for each of the categories of maintenance


Design Changes …

Corrective Maintenance– includes all repairs of defects in an existing

system

Defects can stem from:»requirements specification errors»design errors

about 80% of all problems stem from requirements and design

»coding errors


Problems repairing defects:»cleanly repairing a defect

repairing a defect has a 20-50% chance of introducing another defect

because: Ripple-effect may be overlooked person who makes the repair is not generally the

person who wrote the code

» increased testing

Every solution causes new problems


Types of Corrective MaintenanceEmergency Repairs

»usually performed in a short time frame»often focuses on a single program»includes all severity 1 and 2 defects

Scheduled Repairs» to fix defects that do not require immediate attention» to re-examine all emergency repairs» generally severity 3 and 4 defects (non-critical)


Design Changes ...Adaptive Maintenance

Aims to evolve systems to meet user and business needs

» Invoked by: internal needs external competition external requirements e.g. changes in law

– Essentially the same as a new development» Requirements and Systems, Data, Program and Module

Design

At each stage conduct design and code reviews.


Design Changes ...Perfective Maintenance

Why improve software that works?

Why improve the quality of working programs?»costs shrink»programs become more maintainable


Perfective Maintenance ...– includes all efforts to polish or refine the

quality of the software or the documentation– includes re-engineering

» rewriting and upgrading documentation» restructuring poorly written code

– important that the improvement reduces the system maintenance costs


Perfective Maintenance ... In an organisation, • the reasons for quality improvement need to be

documented for management• the procedure to identify the candidates or particular

programs that need changing is as follows:

1. Define the program selection criteria2. Gather related data3. Analyse the data4. Implement a solution5. Review the benefits and results derived


Perfective Maintenance Procedure1. Define Program Selection Criteria

ie, to choose which programs to change look at the following metrics

Defect Type Defect Costs Symptoms Cause Failure Rate (MTBF-Mean Time Between

Failures) Failure Type Field performance Enhancement Costs Enhancement Rate


Perfective Maintenance Procedure ...2. Gather related data

ie, obtain the above information from the following reliable sources:

Change request database Historical change request Configuration management system histories Operating system logs Time-operating / project management systems


Perfective Maintenance Procedure ...3. Analyse the data

• Conduct a Pareto Analysis

A Pareto Analysis identifies the 20% of the programs that consume 80% of the budget and personnel resources i.e. 80/20 rule


Perfective Maintenance Procedure ...

4. Implement a Solution»select the specific qualities to improve »select a solution to achieve these qualities

apply problem-solving techniques follow the guidelines (on next slide):

- Guidelines for Implementing Alternatives

5. Review the benefits and results derived


Design Changes ...Guidelines for

Implementing Alternatives– Complete redesign and rewrite

»Use when: more than 20% of the program must be changed program is being upgraded to new technology

»Do not use when: the design and function of the program is not

known


Design Changes ...Guidelines for

Implementing Alternatives... – Complete restructuring or overhaul

of the existing code» use on highly maintenance prone programs

– Partial restructuring integrated with adaptive maintenance

» use for orderly improvement with each system release


Design Changes ...Guidelines for Implementing

Alternatives...– Retirement of the system and

complete redevelopment»Use when:

moving to a new technology the costs of maintaining the software and the

hardware exceed the cost of re-development


Step 5 - Code Aim:

»to clarify existing code and simplify changing it

Re-Engineering Source Code»Restructuring»Redesign and rewrite code

»Remember design and code reviews


Step 6 - Software Testing

Maintenance / Development DifferencesFor Maintenance:

only changes need to be reviewed only new test cases that exercise the changes need to

be developed existing and new test cases are required to test the

changes test results are compared against previous test results

(Regression Testing)


Software Testing ...Maintenance Testing

»Rule of Thumb (Brook 1975): 1/3 planning and design 1/6 coding 1/4 component and early system test 1/4 system test with all components

»Easier to test incrementally»Data collected during impact analysis

identifies what must be tested at each level


Step 7 - System ReleaseAims:

»package the system for release including: documentation software training other products hardware

»deliver the system to the user install the system release with backup procedures


Summary There are 3 (4) categories of maintenance

corrective, adaptive, perfective, (preventative) There is a defined maintenance process, which

ensures the delivery of quality software A procedure with 7 steps.

Perfective maintenance includes the selection of criteria, a search for the data and the use of a Pareto Analysis

Software Maintenance. Software Maintenance - Terminology u Software Maintenance –consists of the...

Documents

Transcript of Software Maintenance. Software Maintenance - Terminology u Software Maintenance –consists of the...