Tutorial 4 IT323.  Q1. As a software project manager in a company that specializes in the development of software for the offshore oil industry, you.

Slides:



Advertisements
Similar presentations
Software change management
Advertisements

Chapter 11 Software Evolution
SOFTWARE MAINTENANCE 24 March 2013 William W. McMillan.
1 / 24 CS 425/625 Software Engineering Software Evolution Based on Chapter 21 of the textbook [SE-8] Ian Sommerville, Software Engineering, 8 th Ed., Addison-Wesley,
Software Evolution Managing the processes of software system change
March 30, Exploratory Testing Testing Approaches Analytical Information-driven Intuitive Exploratory Design the tests and test concurrently Learn.
Dr Kettani, Spring 2002 Software Engineering IIFrom Sommerville, 6th edition Software change l Managing the processes of software system change.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
CSEM01 SE Evolution & Management Anne Comer Helen Edwards
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Software evolution.
Software evolution.
Software maintenance Managing the processes of system change.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Chapter 27 Software Change.
Software Reengineering 2003 년 12 월 2 일 최창익, 고광 원.
Software Re-engineering
Chapter 9 – Software Evolution and Maintenance
Problems with reuse – Increased maintenance costs; lack of tool support; not-invented- here syndrome; creating, maintaining, and using a component library.
This chapter is extracted from Sommerville’s slides. Text book chapter
Lecture # 22 Software Evolution
Software evolution. Objectives l To explain why change is inevitable if software systems are to remain useful l To discuss software maintenance and maintenance.
Software change  Managing the processes of software system change.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Software change l Managing the processes of software system change.

Chapter 3: Software Maintenance Process Omar Meqdadi SE 3860 Lecture 3 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
CS 425/625 Software Engineering Legacy Systems
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Software change l Managing the processes of software system change.
Chapter 11 Maintaining the System System evolution Legacy systems Software rejuvenation.
Manag ing Software Change CIS 376 Bruce R. Maxim UM-Dearborn.
Software evolution l Software evolution is the term used in software engineering (specifically software maintenance) to refer to the process of developing.
Lecture 14 Maintaining the System and Managing Software Change SFDV Principles of Information Systems.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution 1.
Software Evolution Program evolution dynamics Software maintenance Complexity and Process metrics Evolution processes 1.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28Slide 1 CO7206 System Reengineering 4.2 Software Reengineering Most slides are Slides.
HNDIT23082 Lecture 06:Software Maintenance. Reasons for changes Errors in the existing system Changes in requirements Technological advances Legislation.
Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
1 Software Maintenance The process of changing the system after it has been delivered and in operation Software change is inevitable –New requirements.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution 2.
Chapter 9 – Software Evolution Chapter 9 Software Evolution130/10/2014.
1 Chapter 12 Configuration management This chapter is extracted from Sommerville’s slides. Text book chapter 29 1.
Software Architecture in the Future 1960s. Assembly languages, subroutines, semicolon as connectors 1970s. Structuring of programs to achieve qualities.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Chapter 9 – Software Evolution 1Chapter 9 Software evolution.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Chapter 8: Maintenance and Software Evolution Ronald J. Leach Copyright Ronald J. Leach, 1997, 2009, 2014,
Software Maintenance1 Software Maintenance.
© SERG Reverse Engineering (Software Maintenance & Reengineering) Software Maintenance Managing the processes of system change.
Software Development Module Code: CST 240 Chapter 6: Software Maintenance Al Khawarizmi International College, AL AIN, U.A.E Lecturer: Karamath Ateeq.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini XVI. Software Evolution.
Environment Assessment
Chapter 18 Maintaining Information Systems
Introduction to Software Evolution and Maintenance
Chapter 9 – Software Evolution
Software Engineering (CSI 321)
Chapter 16 – Software Reuse
Chapter 9 – Software Evolution
CS 425/625 Software Engineering Software Evolution
Maintenance.
Chapter 9 – Software Evolution and Maintenance
Chapter 27 Software Change.
Maintaining a Program In today’s lesson we will look at:
Chapter 8 Software Evolution.
Lecture 06:Software Maintenance
Software Engineering I Session 8
Chapter 16 – Software Reuse
Legacy system components
Software Maintenance Part1 Introduction. Outlines What Is Software Maintenance Purposes of Maintenance Why We Need It Maintenance Difficilties Some Tips.
Software Re-engineering and Reverse Engineering
Presentation transcript:

Tutorial 4 IT323

 Q1. As a software project manager in a company that specializes in the development of software for the offshore oil industry, you have been given the task of discovering the factors that affect the maintainability of the systems developed by your company. Suggest how you might set up a program to analyze the maintenance process and determine appropriate maintainability metrics for the company.

 factors which affect maintainability such as (program and data complexity, use of meaningful identifiers, programming language, program documentation etc.). They should then suggest how these can be evaluated in existing systems whose maintenance cost is known and discuss problems of interaction. The approach should be to discover those program units which have particularly high maintenance costs and to evaluate the cost factors for these components and for other components.

 Q2. Briefly describe the three main types of software maintenance. Why is it sometimes difficult to distinguish between them?

Q2- Answer The three main types of software maintenance are:  Corrective maintenance or fault repair. The changes made to the system are to repair reported faults which may be program bugs or specification errors or omissions.  Adaptive maintenance or environmental adaptation. Changing the software to adapt it to changes in its environment e.g. changes to other software systems.  Perfective maintenance or functionality addition. This involves adding new functionality or features to the system. They are sometimes difficult to distinguish because the same set of changes may cover all three types of maintenance. For example, a reported fault in the system may be repaired by upgrading some other software and then adapting the system to use this new version (corrective + adaptive). The new software may have additional functionality and as part of the adaptive maintenance, new features may be added to take advantage of this.

 Q3. Under what circumstances might an organization decide to scrap a system when the system assessment suggests that it is of high quality and high business value?

Examples of where software might be scrapped and rewritten are:  1. When the cost of maintenance is high and the organization has decided to invest in new hardware. This will involve significant conversion costs anyway so the opportunity might be taken to rewrite the software.  2. When a business process is changed and new software is required to support the process.  3. When support for the tools and language used to develop the software is unavailable. This is a particular problem with early 4GLs where, in many cases, the vendors are no longer in business. There are other reasons why software may be scrapped, depending on local circumstances.

 Q4. What are the strategic options for legacy system evolution? When would you normally replace all or part of a system rather than continue maintenance of the software?

Q4- Answer The strategic options for legacy system evolution are:  1. Abandon maintenance of the system and replace it with a new system.  2. Continue maintaining the system as it is.  3. Perform some re-engineering (system improvement) that makes the system easier to maintain and continue maintenance.  4. Encapsulate the existing functionality of the system in a wrapper and add new functionality by writing new code which calls on the existing system as a component.  5. Decompose the system into separate units and wrap them as components. This is similar to the solution above but gives more flexibility in how the system is used. You would normally choose the replacement option in situations where the hardware platform for the system is being replaced, where the company wishes to standardize on some approach to development that is not consistent with the current system, where some major sub-system is being replaced (e.g. a database system) or where the technical quality of the existing system is low and there are no current tools for re-engineering.?