1. CSCI 3428: Software Engineering Tami Meredith Chapter 11 Maintaining the System

2. Waterfall Model

3. Software Maintenance Adapting to changes: More data, new Database, new business rules, new standards, new hardware,... Adding features Improvements, new features to support changes, keeping up with the competition, handling larger datasets than expected (performance issues) Repairing faults found during operation

4. Lehman's Laws of S/W Evolution A program undergoes continual change resulting in degradation: A system is never complete Architectural drift due to maintenance causes increased complexity Behaviour, trends, changes are consistent: nothing will stabilise Improved tools and techniques cause increased expectations on workers (invariant work rate) Impact of changes decreases over time as functionality plateaus leading to software becoming out of date

5. Kinds of Maintenance A. Corrective: Fixing things B. Adaptive: Reacting to change C. Perfective: Improving the system D. Preventative:Avoiding possible failures Consider System Evolution vs. System Decline Should the system be adapted/improved or is it better to replace it?

6. Tasks in Maintenance Understanding the system! (Program comprehension) Managing documentation Extending existing code Adding new code/features Locating and correcting faults – Debugging! Restructuring/Redesign – Refactoring Deleting dead code... NEVER! Don't do it!

7. Factors in Maintenance Lack of understanding Management priorities Lack of budget Morale Code/design may facilitate needed changes Testing difficulties as system is live Distribution of changes OOP makes programs harder to understand and trace

8. Compromise During Repair Type of failure Criticality and severity Complexity and difficulty of the repair Scope of the changes Available resources (time, budget, etc.) Client pressures (time, budget)

9. Factors in Maintenance Application type (RT, Embedded) System size System novelty System age Knowledge of software history Availability of original developers, documentation Hardware characteristics Design, code, & documentation quality Stability of usage environment

10. Program Comprehension Top Down: Going from general to specfics Bottom Up: Going from specifics to generality Opportunistic: What we really do! Best code analysts are those who switch approaches the most. Code reading Control flow tracing (calling behaviour) Data dictionaries & symbol tables Application of analysis tools

11. Reverse Engineering Recovering information from the source code Can be partly automated More common than expected (due to loss of personnel, documents) Done also for espionage, obtaining legal evidence, linking to other systems to extend them

12. Terms Impact Analysis: evaluation of risks associated with a change Cyclomatic Number (McCabe's cyclomatic complexity): measures code complexity based on cycles in the CF graph Legacy System: An older system (build for previous requirements) Traceability: Matching of code components to design and SRS

13. Famous Moments in Software Engineering Space Flight A booster went off course during launch, resulting in the destruction of Mariner 1. A programmer failed to notice an overbar in a written specification for the guidance program, resulting in the coding of an incorrect formula in its FORTRAN software. (July 22, 1962). [ [ Russia's Phobos 1 deactivated its attitude thrusters and could no longer properly orient its solar arrays or communicate with Earth, eventually depleting its batteries (Sept. 10, 1988). ESA's Ariane 5 $1 billion USD explosion (June 4, 1996). The Mars Polar Lander was destroyed because its flight software mistook vibrations due to atmospheric turbulence for evidence that the vehicle had landed and shut off the engines 40 meters above the Martian surface (Dec. 3, 1999). Its sister spacecraft Mars Climate Orbiter was destroyed, due to software on the ground generating commands in pound-force while the orbiter expected newtons. An erroneous command from Earth caused the Mars Global Surveyor to incorrectly assume that a motor had failed, causing it to point one of its batteries at the sun – subsequently overheating it (Nov. 2, 2006). NASA's Spirit rover became unresponsive a few weeks after landing on Mars (Jan. 21, 2004). Too many files had accumulated in the rover's flash memory – deleting unnecessary files restored it to working condition.