CS 325: Software Engineering April 2, 2015 Software Maintenance Software Bugs & Sugs Maintenance Categories Maintenance Process Models Software Reengineering

Software Bugs As a faculty member at Harvard in 1946, Grace Murray Hopper traced an error to a moth trapped in a relay, the first documented case of a software “bug”. CS 325 April 2, 2015 Page 213

Software Bugs How do you plan to deal with problems once your software is released? Provide users with the means to report bugs Include fields for version, platform, component, severity, and description Status Resolution Unconfirmed New Assigned Reopened Unresolved Resolved Verified Closed Fixed Invalid Won’t Fix Not Reproducible Part Of Other Bug - Moved To Other Bug Database CS 325 April 2, 2015 Page 214

Software Sugs What features might users want in your next software release? Feature request information is similar to bug report information (i.e., version, platform, component, severity, and description). Warn users that any ideas they provide in a feature report belong to your team, not to the reporting user! CS 325 April 2, 2015 Page 215

Corrective Maintenance Perfective Maintenance Emergency Maintenance Maintenance Categories The IEEE splits software maintenance into four categories: Corrective Maintenance When problems are discovered after the software is delivered, repairs must be made so the system will satisfy its requirements. Adaptive Maintenance When the software environment (e.g., the operating system) changes after delivery, the software may need to be upgraded, too. Perfective Maintenance Latent faults in the software may need to be addressed before they manifest themselves as performance failures. Emergency Maintenance Unscheduled modifications may be needed pending more permanent corrective measures. CS 325 April 2, 2015 Page 216

Maintenance Process Models Modified systems are often viewed as new systems that reuse parts of the original system. Quick-Fix Model Take the source code of the original system, make the necessary changes, update the requirements and the design, and then test the modified code. Old System Requirements Design Code Test New System Requirements Design Code Test Iterative Enhancement Model Analyze the old system to identify needed updates to the requirements, then repeat the development life cycle until the desired system is produced. Old System Requirements Design Code Test New System Requirements Design Code Test Full Reuse Model Store old system components in a reusable repository and replace components as needed. Old System Requirements Design Code Test Repository Ri Di Ci Ti New System Requirements Design Code Test CS 325 April 2, 2015 Page 217

Software Reengineering To improve a software system, it is sometimes necessary to restructure the system or some of its components. Motivations for reengineering software systems include: Reducing the system’s complexity Improving the system’s modifiability Improving performance, efficiency, or resource utilization Improving the system’s maintainability CS 325 April 2, 2015 Page 218