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

213. 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

214. 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

215. 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

216. 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

217. 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

218. 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