1. CS189A/172 - Winter 2008 Lecture 15: Software Maintenance

2. Software Maintenance What is software maintenance? –Software maintenance is the process of modifying the software system or component after the delivery to correct faults, improve performance or other attributes, or adapt to a change in environment

3. Maintenance Is Costly For most software, software maintenance occupies between 40 to 90 percent of total life cycle costs A common mistake is to overlook maintenance costs: – In 1950s, when banks were hiring their first full-time programmers they were worried about what these people will do after the programs were written Maintenance is challenging –When US banks introduced ATMs, existing banks had difficulty in adapting their software to the new system, whereas new banks writing software from scratch had an easier time –In UK two mergers of financial institutions were canceled due to problems of integrating software from two different organizations

4. Types of Software Maintenance Perfective maintenance –Changes required as a result of user requests to improve some of the qualities of the software Adaptive maintenance –Changes needed as a consequence of change in the environment of the software such as operating system, hardware or change in the requirements Corrective maintenance –The identification and removal of faults in the software Preventive maintenance –Changes made to software to make it more maintainable

5. Software Maintenance Issues The important requirement for the client is that changes are accomplished quickly and cost effectively The reliability of the software should not be degraded by the changes A program used in a real world environment has to change or it will progressively become less useful As a program keeps evolving its structure tends to become more complex, extra resources must be devoted to preserving the semantics and simplifying the structure When the source code for the software changes, this has a ripple effect since also the documentation, design and test suites have to change

6. Organizational Issues Initial software development is product-oriented where the aim is to deliver a product within budget and timescale Software maintenance on the other hand is closer to a service Some companies choose to outsource maintenance –not a good idea for the core products –outsourcing company will spend sometime assessing the software before accepting the contract Service level agreements between the customer and the maintenance organization are used to define the service to be provided during maintenance –Unfortunately for software products we are more likely to see agreements in the form of disclaimer rather than warranty

7. Process Models for Maintenance Process management is defined as the direction, control and coordination of work performed to develop a product or perform a service A common process model for software maintenance has four key stages –Help desk: The problem is received, a preliminary analysis undertaken, and if the problem is sensible, it is accepted –Analysis: A managerial and technical analysis of the problem is undertaken to investigate and cost alternative solutions –Implementation: The chosen solution is implemented and tested –Release: The change (along with possibly others) is released to the customer

8. IEEE Standard for Software Maintenance IEEE Standard defines seven stages of software maintenance activity: –Problem Identification –Analysis –Design –Implementation –System Test –Acceptance Test –Delivery Each of the seven activities have: –input life cycle products: inputs to this activity –output life cycle products: deliverables of this activity –activity definition –control: a set of quality control actions –metrics: the measurements that should be performed

9. IEEE Standard for Software Maintenance: Analysis Phase For example the analysis phase accepts a validated problem report, initial resource estimates and project and system documentation Analysis phase has two components –Feasibility analysis: Assess the impact of the modification, investigate alternative solutions, assess short and long term costs, compute benefit of making the change –Detailed analysis: Once a particular approach is chosen, in detailed analysis phase, requirements for the modification, the software components involved are identified, a test strategy and an implementation plan is produced

10. IEEE Standard for Software Maintenance: Analysis Phase Analysis phase produces the following deliverables: –Feasibility report for problem reports –Detailed analysis report –Updated requirements –Preliminary modification list –Development, integration and acceptance test strategy –Implementation plan

11. Technical Aspects of Software Maintenance Certain technical issues are common to both software development and maintenance –configuration management and version control (CVS, RCS) Some technical issues are unique to software maintenance –to determine the cost of making a change to meet a software change request

12. Impact Analysis Ripple effect propagation is a phenomenon by which changes made to a software component along the software life cycle (specification, design, code, or test phase) have a tendency to be felt in other components Impact analysis –the task of assessing the effects for making the set of changes to a software system –translate the user identified problem into software terms, the primary components of the system which must be altered to meet the new requirement –figure out the changes that will be the consequence of the primary change in all components not just code

13. Impact Analysis Most modern programming languages and compilers will do some static analysis to report the incompatibilities which result from changes in one part of the code –an automated impact analysis to prevent undesirable ripple effects

14. Traceability Traceability is a degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor successor or master subordinate relationship to one another If software products are traceable, impact analysis will be easier –when you make a change in your design you would like to figure out which software components will be effected by that change

15. Legacy Systems Legacy systems –typically an old, large, heavily modified system –none of the original developers may still be around –the languages may be out of date It is estimated that there 70 billion lines of COBOL code in existence still doing useful work

16. Legacy Systems Different options about the maintenance of legacy systems: –keep the legacy software, subcontract the maintenance to companies who specialize on maintenance of legacy systems –replace parts of the software –re-implement from scratch –discard software and discontinue –freeze maintenance and phase in a new system –encapsulate the old system and call as a server to the new –reverse engineer the legacy system and develop a new software suite

17. Reverse Engineering Reverse engineering is the process of analyzing a subject system to identify the system’s components and their inter-relationships, and to create representations of the system in another form or at a higher level of abstraction Examples: –Producing call graphs or control flow graphs from source code –Generating class diagrams from the source code

18. Reverse Engineering Two types of reverse engineering: –Redocumentation: the creation or revision of a semantically equivalent representation within the same relative abstraction layer For example adding indentation to the source code –Design recovery: involves identifying meaningful higher level abstractions beyond those obtained directly by examining the system itself

19. Reverse Engineering The main goal is to help with the program comprehension Most of the time reverse engineering makes up for lack of good documentation Documentation required in the implementation phase and the maintenance phase maybe different Program documentation written in the implementation phase can be very useful in the maintenance phase –Javadoc, docgen

20. Re-engineering During the maintenance phase the product may need to be restructured –Restructuring: the transformation from one representation to another at the same relative level of abstraction, while preserving the system’s internal behavior –Re-engineering: The examination and alteration of the subject system to reconstitute it in a new form, and the subsequent implementation of the new form

21. Re-engineering Examples –Control flow restructuring to remove “spaghetti code” –Converting monolithic code to use procedures –Identifying modules and abstract data types –removing dead code and redundant variables –simplifying aliased/common or global variables

22. Refactoring A reengineering technique called refactoring became quite popular recently Refactoring is a change made to the internal structure of software to make it easier to understand and modify without changing its observable behavior

23. Refactoring: A Example For example assume that you have a method which looks like: class Promotion choosePromotion(Account anAccount) { switch (anAccount.getType()) { case SILVER:... case GOLD:... case PLATINUM:... }

24. Refactoring: An Example One can refactor this code by subtyping the Account class and moving the choosePromotion method to the Account class This would get rid of the switch statement in the code and make it easier to maintain class Account choosePromotion() {... }

25. Refactoring Catalog The idea is that one can generalize refactoring transformations and catalog them –similar to design patterns There is a catalog of refactoring transformations in the following book: –“Refactoring: Improving the Design of Existing Code,” by Martin Fowler, Addison Wesley One can use this refactoring catalog to look for refactorings that are applicable to a software system

26. Refactoring Catalog Each entry in the catalog has five parts: –name: useful in creating a vocabulary for refactorings –summary: a summary of the situation where the refactoring would be needed and a summary of what it does – motivation: why the refactoring should be done, and the circumstances when it shouldn’t be done –mechanics: explaining how to carry out the refactoring –examples: demonstrating how the refactoring works

27. Why Reverse or Re-Engineer a System? Here are some reasons for reverse or re-engineering a software system –To enforce product or process standards –To permit better maintenance management –To simplify complex software –Facilitating detection of errors –Removing side effects –Improve code quality –Production of up-to-date documentation –Preparing full test suites –Improving the performance –Bringing into line with practices elsewhere in the company –To allow major changes to be made –To discover design and requirements specification –To establish a reuse library –To introduce technical innovation such as new user interface