Change Management

1. Change Management Change is inevitable Maintenance

2. Change Management • Change management is the application of many different ideas from the fields of engineering, business and psychology to systematically manage the changes that occur over the life cycle of the product. Maintenance

3. Change Management II • The management of change is concerned with change within all aspects of software production: • Software development • Maintenance • Project management • Version control • Release management Maintenance

4. Simplified Change Management Technique • Request change by completing a change request form • Analyse change request • If change is valid then • Assess how change might be implemented • Assess change cost • Record change request in a database • Submit request to change control board • If change is accepted then • Repeat • make requested changes to software • record changes and link to associated change request • submit changed software for quality approval • Until software quality is adequate • create new system version • Else • reject change request • Else • reject change request • EndIf Maintenance

5. Maintenance Maintain - to keep up, continue or preserve Maintenance

6. Maintenance • Any changes that have to be made to the product after it has been handed over to the client. • Documentation • Manuals • Any other component of the product Maintenance

7. IEEE Maintenance categories • Corrective – refers to the correction of residual faults not realised before the product is handed over to the client. • Adaptive – refers either to changes required by the product to meet the changing demands of the client or for the product to remain useful and competitive. • Perfective – refers to changes to the product to increase its efficiency. Also included in this category are changes to improve the maintainability of the product. • Preventative – refers to changes to the software which seek to avoid problems associated with some future crises (e.g. y2k bug) Maintenance

8. Why is maintenance hard? • Maintenance become hard when: • There is the inability to trace the product or the process that created the product • Changes are not adequately documented • It is difficult to track changes • There is a ripple effect when making changes. Maintenance

9. Who should be responsible for maintenance? • Developing organisation • Third party organisation Maintenance

10. Developing Organisation I • Advantages • The developer has the best knowledge of the system and should therefore be in a better position to administer change. • There will be no need for elaborate documentation (i.e. between the developer organisation and the maintenance organisation). • The user of the software will only need to work with the developing organisation • Once maintenance duties are managed properly, personnel at the developing organisation are more personally satisfied because there is diversity in the workload). Maintenance

11. Developing Organisation II • Disadvantages • Developers often spend too much time perfecting the developed system (i.e. tweaking) causing documentation to suffer. • Personnel may leave the developing organisation especially if only maintenance is performed. • Often, the original developers get reassigned to high-priority projects. • If a developer expert leaves, the people responsible for the maintenance might not be adequately trained. • New employees may be de-motivated by the quantity of maintenance work. Maintenance

12. Third party Organisation I • Advantages • Better documentation is produced as developers are now ‘forced’ to produce documentation to support the system. • Formal turnover procedures are created, thereby further ensuring the existence of necessary documents (e.g. software licenses, training – lectures etc…). This way, the maintainer will understand the difference between what he should get to support the system and what is actually received. • Procedures for implementing changes are established • Maintenance programmers get to know the strong and weak points of the system. They have a more objective viewpoint and are less likely to be biased. • Morale is improved; people who like maintenance are likely to do a better job. Maintenance

13. Third party Organisation II • Disadvantages of this approach are: • Transition of the system (i.e. from developer to maintainer) may be slow. • There is a significant training need. • It takes time to learn a new system. • User support can suffer. • Morale can decrease if the wrong people are assigned Maintenance

14. Fault Reports I : Reporting the fault • Fault reports provide a mechanism for changing the product. • if the product appears to be working incorrectly, then a fault report should be filed by the user. • The report should include enough information to allow the maintenance programmer to recreate the problem, which will usually be some sort of software failure. Maintenance

15. Fault Reports II - Towards a solution • The maintenance programmer should first consult the fault report file. • Contains all the fault reports currently not fixed • suggestions for how to deal with (i.e. bypass) them until the fault can be fixed. • If the fault has been previously reported, then any information in the fault report file should be given to the user. Maintenance

16. Fault Reports III - Towards a solution • If the fault appears to be a new fault • The maintenance programmer should study the problem and attempt to find the cause and a way to fix it. • A way should be found to work around the problem as it may take a long time (>6 months) before someone can be assigned to that particular problem. • Any conclusions reached by the maintenance programmer at this stage should be added to the file, together with documentation (e.g. listings, designs and manuals) used to arrive at those conclusions. • The fault report file should also contain the client’s request for perfective and adaptive maintenance. Maintenance

17. Reverse Engineering (reengineering) • Refers to maintenance when the only documentation available is the source code • One way to handle this problem is to start with the source code and attempt to recreate the design documents, or even the specifications. Maintenance

18. Reengineering II • CASE tools may be employed to • Display the code more clearly • Construct diagrams (flowcharts, structure charts) directly from the source code. • The end result is the production of a design document representative of the original design. Maintenance

19. Reengineering III • Two possible alternatives once the design is obtained: • Attempt to reconstruct the specifications, modify the reconstructed specifications to reflect the necessary changes and then re-implement the product in the usual way (forward engineering). • The reconstructed design is modified, and the modified design is then forward engineered. Maintenance

20. Reengineering IV • The second technique employed (in the case where the source code is lost) when only an executable is available uses a dissassembler (reverse compiler) • The goal is to try to recreate the original high-level language code Maintenance

21. Disassembler Problems • Variable names are lost due to the original compilation • Many compilers optimise the code making it difficult to recreate the source code • Constructs such as loops in the assembler could correspond to a number of different constructs in the source code. Maintenance

22. Practical Solution • Treat the executable as a black box • Reverse engineering is then used to deduce the specifications from the behaviour of the current product. • The reconstructed specifications are then modified as required, and the new version of the product is then forward engineered. Maintenance

23. Maintenance skills vs. Development Skills I • For corrective maintenance: • The ability to determine the cause of a failure of a large product is essential. • This skill is also necessary throughout the integration and product testing phases. • The ability to function effectively without adequate documentation. Maintenance

24. Maintenance skills vs. Development Skills II • For adaptive and perfective maintenance: • skills are needed with regards to specification, design, implementation and integration, and testing are essential. • Each of these areas requires specialised skills if they are to be performed correctly. Maintenance

25. Maintenance skills vs. Development Skills III - summary • The skills that a maintenance programmer needs are the same as those needed by software specialising in other phases of software production. • whereas the average developer can specialise in one area of software development such as design or testing, the software maintainer must be a specialist in virtually every area of software production. Maintenance