Software Maintenance.

Name: Software Maintenance.
Uploaded: 2017-07-19T10:14:45+00:00
Duration: PTM17S40
Channel: Sylvia Collins
Description: Software Maintenance.

Software Maintenance

Software Maintenance - Terminology
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 definition 3% Preliminary design 5% Detailed design 7% Implementation 15% Testing 67% 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 Management Step 2 - Impact Analysis Step 3 - System Release Planning Step 4 - Design Changes Step 5 - Coding Step 6 - Testing Step 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: Evaluate Change Requests (In assignment the changes will be your Stage 2 Requirements) 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 ... 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 ... 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 Maintenance Emergency 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 criteria 2. Gather related data 3. Analyse the data 4. Implement a solution 5. Review the benefits and results derived

Perfective Maintenance Procedure 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 ... 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 Differences For 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 Release Aims: 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.

Similar presentations

Presentation on theme: "Software Maintenance."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Software Maintenance.

Similar presentations

Presentation on theme: "Software Maintenance."— Presentation transcript:

Similar presentations

About project

Feedback