Software change. Software maintenance

Similar documents
Software Maintenance. Maintenance is Inevitable. Types of Maintenance. Managing the processes of system change

Legacy Systems. Older software systems that remain vital to an organisation. Legacy systems. Legacy system replacement

Documentation & Maintenance

ICS 52: Introduction to Software Engineering

ICS 52: Introduction to Software Engineering

Configuration management. Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 29 1

CSC 408F/CSC2105F Lecture Notes

Introduction to Software Engineering

Software Engineering I. Chapters 8 & 9. SW Testing & Maintenance. Slide 1. 12/17/2017 SW Testing and Maintenance

2. Draw and explain state transition diagram for a typical weather information system. (8M)

Losing Control: Controls, Risks, Governance, and Stewardship of Enterprise Data

Software Prototyping Animating and demonstrating system requirements. Uses of System Prototypes. Prototyping Benefits

SOFTWARE ENGINEERING DECEMBER. Q2a. What are the key challenges being faced by software engineering?

Incremental development A.Y. 2018/2019

Process of Interaction Design and Design Languages

ORACLE SERVICES FOR APPLICATION MIGRATIONS TO ORACLE HARDWARE INFRASTRUCTURES

Training & Documentation. Different Users. Types of training. Reading: Chapter 10. User training (what the system does)

Introduction to Software Engineering

Business Phone System Buyer s Guide

Session 4112 BW NLS Data Archiving: Keeping BW in Tip-Top Shape for SAP HANA. Sandy Speizer, PSEG SAP Principal Architect

Reducing the costs of rework. Coping with change. Software prototyping. Ways to Cope with change. Benefits of prototyping

CS 390 Software Engineering Lecture 3 Configuration Management

Four Essential Steps for Removing Risk and Downtime from Your POWER9 Migration

OCR Interchange Service Agreement

Rethinking VDI: The Role of Client-Hosted Virtual Desktops. White Paper Virtual Computer, Inc. All Rights Reserved.

RED HAT ENTERPRISE LINUX. STANDARDIZE & SAVE.

SMARTnet provides you with the following advantages:

Testing is a very big and important topic when it comes to software development. Testing has a number of aspects that need to be considered.

Software Processes. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 4 Slide 1

CS2112 Fall Assignment 4 Parsing and Fault Injection. Due: March 18, 2014 Overview draft due: March 14, 2014

Session 4b: Review of Program Quality

10 Cloud Myths Demystified

The requirements engineering process

Tackling the data analytics dilemma for predictive maintenance Dawen Nozdryn-Plotnicki Advanced Analytics Dave Kinney Technical Fellow September 2017

Three Key Considerations for Your Public Cloud Infrastructure Strategy

Provided as an educational service by: Introduction

SPREADSHEETS AND SOLVENCY II

IT323 - Software Engineering 2 1

CMSC 435: Software Engineering Section 0201

COLUMN. Responsive design for mobile intranets? How should the intranet be presented on mobile devices? JULY What is responsive design?

Designing Next Generation Test Systems An In-Depth Developers Guide

1 Visible deviation from the specification or expected behavior for end-user is called: a) an error b) a fault c) a failure d) a defect e) a mistake

Static and dynamic Testing

Part 5. Verification and Validation

IT your way - Hybrid IT FAQs

Benefits of Maintaining Computer Systems

10 Cloud Myths Demystified

Planning for Information Network

OVM to UVM Migration, or There and Back Again: A Consultant s Tale. by Mark Litterick, Verification Consultant, Verilab GmbH

Agile Accessibility. Presenters: Ensuring accessibility throughout the Agile development process

WHITE PAPER. The General Data Protection Regulation: What Title It Means and How SAS Data Management Can Help

Symantec Security Monitoring Services

A Visual Guide to Automated MVC Reengineering

Erasmus+ 2017/18 Timeline, Checklist & FAQs

Get your business Skype d up. Lessons learned from Skype for Business adoption

Incentives for IoT Security. White Paper. May Author: Dr. Cédric LEVY-BENCHETON, CEO

DATABASE ADMINISTRATOR

Principles of Information Security, Fourth Edition. Chapter 1 Introduction to Information Security

Operating Systems. Memory Management. Lecture 9 Michael O Boyle

Software Quality Assurance. David Janzen

Rediffmail Enterprise High Availability Architecture

Introduction To Software Testing. Brian Nielsen. Center of Embedded Software Systems Aalborg University, Denmark CSS

Basic Concepts of Reliability

Forecasting Technology Insertion Concurrent with Design Refresh Planning for COTS-Based Electronic Systems

Simple Garbage Collection and Fast Allocation Andrew W. Appel

Incident response in the energy

Specifying and Prototyping

WHITEPAPER. Embracing Containers & Microservices for future-proof application modernization

STRUCTURED SYSTEM ANALYSIS AND DESIGN. System Concept and Environment

A Security Model for Space Based Communication. Thom Stone Computer Sciences Corporation

Bender Remote Assist

SOFTWARE PRODUCT QUALITY SOFTWARE ENGINEERING SOFTWARE QUALITY SOFTWARE QUALITIES - PRODUCT AND PROCESS SOFTWARE QUALITY - QUALITY COMPONENTS

5 STEPS for Turning Data into Actionable Insights

Memory Allocation. Static Allocation. Dynamic Allocation. Dynamic Storage Allocation. CS 414: Operating Systems Spring 2008

Klocwork Architecture Excavation Methodology. Nikolai Mansurov Chief Scientist & Architect

Lecture 5: Requirements Specifications

Lecture 19 Engineering Design Resolution: Generating and Evaluating Architectures

Practical Database Design Methodology and Use of UML Diagrams Design & Analysis of Database Systems

PDF - INTEL FORTRAN XE DOCUMENT

Distributed Data Infrastructures, Fall 2017, Chapter 2. Jussi Kangasharju

Verification and Validation. Assuring that a software system meets a user s needs. Verification vs Validation. The V & V Process

OO Project Management

Software processes. Objectives. Contents

SOFTWARE MAINTENANCE: A

Dilbert Scott Adams. CSc 233 Spring 2012

McLaughlin Brunson Insurance Agency, LLP

SIS Operation & Maintenance 15 minutes

Reminder: Mechanics of address translation. Paged virtual memory. Reminder: Page Table Entries (PTEs) Demand paging. Page faults

Paper. Delivering Strong Security in a Hyperconverged Data Center Environment

One and a half hours. Appendices A and B are located at the back of the exam UNIVERSITY OF MANCHESTER SCHOOL OF COMPUTER SCIENCE

2 Software life span models

Hybrid IT Managed Services

Ch 1: The Architecture Business Cycle

Iowa Department of Transportation Statewide Coordinated GIS

Sample Exam. Advanced Test Automation - Engineer

Where Should the Brain of Your Mobile Application Live?

Total Cost of Ownership: Benefits of ECM in the OpenText Cloud

Total Cost of Ownership: Benefits of the OpenText Cloud

Verification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1

New Zealand Customs Service: Managing Trade Assurance capability risks

Transcription:

Software change 1 Software change is inevitable New requirements emerge when the software is used The business environment changes Errors must be repaired New equipment must be accommodated The performance or reliability may have to be improved A key problem for organizations is implementing and managing change to their legacy systems DISCUSSION Project A change to your project A change to someone else s project Another team in your class Another team from 2000 Another team from 1990 Software maintenance 2 Modifying a program after it has been put into use Maintenance does not normally involve major changes to the system s architecture Changes are implemented by modifying existing components and adding new components to the system 1

Maintenance is inevitable 3 The system requirements are likely to change while the system is being developed because the environment is changing. Therefore a delivered system won't meet its requirements! Systems are tightly coupled with their environment. When a system is installed in an environment it changes that environment and therefore changes the system requirements. Systems MUST be maintained if they are to remain useful in an environment Types of maintenance 4 Maintenance to repair software faults Changing a system to correct deficiencies in the way it meets its requirements Maintenance to adapt software to a different operating environment Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial implementation Maintenance to add to or modify the system s functionality Modifying the system to satisfy new requirements Which one is most common? 2

Distribution of maintenance effort 5 Fault repair (17%) Software adaptation (18%) Functionality addition or modification (65%) Maintenance costs 6 Usually greater than development costs (2* to 100* depending on the application) Affected by both technical and nontechnical factors Increases as software is maintained. Maintenance corrupts the software structure so makes future maintenance more difficult. Ageing software can have high support costs (e.g. old languages, compilers etc.) 3

Development/maintenance costs 7 System 1 System 2 0 50 100 150 200 250 300 350 400 450 500 $ Development costs Maintenance costs Maintenance cost factors 8 Team stability Maintenance costs are reduced if the same staff is involved with them for some time Contractual responsibility The developers of a system may have no contractual responsibility for maintenance so there is no incentive to design for future change Staff skills Maintenance staff is often inexperienced and has limited domain knowledge Program age and structure As programs age, their structure is degraded and they become harder to understand and change 4

Change requests 9 Change requests are requests for system changes from users, customers or management In principle, all change requests should be carefully analyzed as part of the maintenance process and then implemented In practice, some change requests must be implemented urgently Fault repair Changes to the system s environment Urgently required business changes The maintenance process 10 Change requests Impact analysis System release planning Change implementation System release Perfective maintenance Adaptive maintenance Corrective maintenance 5

Maintenance prediction 11 Maintenance prediction is concerned with assessing what parts of the system may cause problems and have high maintenance costs Change acceptance depends on the maintainability of the components affected by the change Implementing changes degrades the system and reduces its maintainability Maintenance costs depend on the number of changes and costs of change depend on maintainability Maintenance prediction 12 What parts of the system are most likely to be affected by change requests? Predicting maintainability What parts of the system will be the most expensive to maintain? Predicting system changes Predicting maintenance costs What will be the lifetime maintenance costs of this system? How many change requests can be expected? What will be the costs of maintaining this system over the next year? 6

Change prediction 13 Predicting the number of changes requires understanding the relationships between a system and its environment Tightly coupled systems require changes whenever the environment is changed Factors influencing this relationship are Number and complexity of system interfaces The business processes where the system is used Evolutionary software 14 Rather than think of separate development and maintenance phases, evolutionary software is software that is designed so that it can continuously evolve throughout its lifetime 7

Configuration management 15 New versions of software systems are created as they change For different machines/os Offering different functionality Tailored for particular user requirements Configuration management is concerned with managing evolving software systems System change is a team activity CM aims to control the costs and effort involved in making changes to a system Configuration management 16 Involves the development and application of procedures and standards to manage an evolving software product May be seen as part of a more general quality management process 8

Configuration management planning 17 All products of the software process may have to be managed Specifications Designs Programs Test data User manuals Thousands of separate documents are generated for a large software system DISCUSSION CM planning 18 Starts during the early phases of the project Must define the documents or document classes that are to be managed Documents which might be required for future system maintenance should be identified and specified as managed documents 9

The CM plan 19 Defines the types of documents to be managed and a document naming scheme Defines who takes responsibility for the CM procedures Defines policies for change and version management Defines the CM records which must be maintained The CM plan 20 Describes the tools which should be used to assist the CM process and any limitations on their use Defines the process of tool use Defines the CM database used to record configuration information May include information such as the CM of external software, process auditing, etc. 10

The configuration database 21 All CM information should be maintained in a configuration database This should allow queries about configurations to be answered Who has a particular system version? What platform is required for a particular version? What versions are affected by a change to component X? How many reported faults in version T? The CM database should preferably be linked to the software being managed 11