1. Chapter 18 Maintaining Information Systems
Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich
Chapter 18
Maintaining Information Systems
18.1
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

2. Process Modeling
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

3. Verification vs validation
Verification: "Are we building the product right”.
The software should conform to its specification.
Validation: "Are we building the right product”.
The software should do what the user really requires.

4. V & V confidence
Aim of V & V is to establish confidence that the system is ‘fit for purpose’.
Depends on system’s purpose, user expectations and marketing environment
Software purpose
The level of confidence depends on how critical the software is to an organization.

5. Marketing environment
User expectations
Users may have low expectations of certain kinds of software.
Marketing environment
Getting a product to market early may be more important than finding defects in the program.

6. Software change Software change is inevitable. Why? reasons:
New requirements emerge when the software is used;
The business environment changes;
Errors must be repaired;
New computers and equipment is added to the system;
The performance or reliability of the system may have to be improved.
A key problem for all organizations is implementing and managing change to their existing software systems.

7. Importance of evolution
Organizations have huge investments in their software systems - they are critical business assets.
To maintain the value of these assets to the business, they must be changed and updated.
The majority of the software budget in large companies is devoted to changing

8. Evolution and servicing
and evolving existing software rather than developing new software.
Evolution
The stage in a software system’s life cycle where it is in operational use and is evolving as new requirements are proposed and implemented in the system.

9. Servicing
At this stage, the software remains useful but the only changes made are those required to keep it operational i.e. bug fixes
and changes to reflect changes in the software’s environment. No new functionality is added.
Phase-out
The software may still be used but no further changes are made to it.

10. Evolution processes Software evolution processes depend on
The type of software being maintained;
The development processes used;
The skills and experience of the people involved.
Proposals for change are the driver for system evolution.

11. Should be linked with components that are affected by the change, thus allowing the cost and impact of the change to be estimated.
Change identification and evolution continues throughout the system lifetime.

12. Urgent change requests
Urgent changes may have to be implemented without going through all stages of the software engineering process
If a serious system fault has to be repaired to allow normal operation to continue;
If changes to the system’s environment (e.g. an OS upgrade) have unexpected effects;

13. Change is inevitable
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 changed if they are to remain useful in an environment.

14. Software maintenance
Modifying a program after it has been put into use.
The term is mostly used for changing custom software. Generic software products are said to evolve to create new versions. [turnkey]
Maintenance does not normally involve major changes to the system’s architecture.

15. Changes are implemented by modifying existing components and adding new components to the system.

16. Types of maintenance Corrective maintenance
Changes made to a system to repair flaws and correct deficiencies in the way it meets its requirements. Changes in its design, coding, or implementation.
Adaptive maintenance to adapt software to a different operating environment
Changes made to a system to evolve its functionality to changing business needs or technologies.
so that it operates in a different environment (computer, OS, etc.) from its initial implementation.

17. Types of maintenance(cont)
Perfective maintenance
Changes made to a system to add new features or to improve performance or modify the system’s functionality.
Preventive maintenance
Changes made to a system to avoid possible future problems.
Modifying the system to satisfy new requirements.

18. Maintenance costs
Usually greater than development costs (2* to 100* depending on the application).
Affected by both technical and non-technical factors.
Increases as software is maintained. Ageing software can have high support costs (e.g. old languages, compilers etc.).

19. Factors that affect Maintenance cost
Team stability and Number of customers
Maintenance costs are reduced if the same staff are 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 are often inexperienced and have limited domain knowledge.
Program age and structure: As programs age, their structure is degraded and they become harder to understand and change.
Latent defects
Quality of system documentation

20. Who carry out maintenance?
Three possible groups:
Separate: Maintenance group consists of different personnel than development group
Combined: Developers also maintain systems
Functional: Maintenance personnel work within the functional business unit

21. Preventative maintenance by refactoring
Refactoring is the process of making improvements to a program to slow down degradation through change.
You can think of refactoring as ‘preventative maintenance’ that reduces the problems of future change.

22. Refactoring involves modifying a program to improve its structure, reduce its complexity or make it easier to understand.
When you refactor a program, you should not add functionality but rather concentrate on program improvement.

23. Refactoring and reengineering
Re-engineering takes place after a system has been maintained for some time and maintenance costs are increasing. You use automated tools to process and re-engineer a legacy system to create a new system that is more maintainable.

24. Refactoring is a continuous process of improvement throughout the development and evolution process. It is intended to avoid the structure and code degradation that increases the costs and difficulties of maintaining a system.

25. Measures for Maintenance Effectiveness
Number of failures
Time between each failure
Type of failure
Mean time between failures (MTBF)
A measurement of error occurrences that can be tracked over time to indicate the quality of a system

26. Configuration Management
The process of assuring that only authorized changes are made to the system.
Baseline modules
Software modules that have been tested, documented, and approved to be included in the most recently created version of a system
System librarian
A person responsible for controlling the checking out and checking in of baseline modules when a system is being developed or maintained
18.26

27. It includes the installed operating system plus other supporting software such as a database management system or, for development platforms, an interactive development environment.
Development platform usually has different installed software than execution platform; these platforms may have different architectures.

28. Integrated development environments (IDEs)
Software development tools are often grouped to create an integrated development environment (IDE).
An IDE is a set of software tools that supports different aspects of software development, within some common framework and user interface.

29. IDEs are created to support development in a specific programming language such as Java.

30. Website Maintenance Special considerations 24 X 7 X 365
Nature of continuous availability makes maintenance challenging
Pages under maintenance can be locked
Date and time stamps
Check for broken links
HTML Validation
Pages should be processed by a code validation routine before publication.
18.30

31. Website Maintenance Re-registration Future Editions
When content significantly changes, site may need to be re-registered with search engines
Future Editions
Consistency is important to users
Post indications of future changes to the site.
18.31

32. Summary Maintenance Cost of maintenance Managing Maintenance
Corrective
Adaptive
Perfective
Preventive
Cost of maintenance
Managing Maintenance
Measuring effectiveness of maintenance
18.32