ABSTRACT

Soœware maintenance is about managing change. Such change to existing soœware releases is precipitated by actions taken to make adaptive (add new functions, address new platforms, etc.), corrective (repair defects), or perfective (make improvements in performance, etc.) updates to the previous soœware release. When making these changes, stakeholders requesting changes will be asked for justi§cation, impact, and risk assessments (related to not changing) and priorities. ­ey will also be asked for cost estimates especially when the change involves potential commercial o¥- the-shelf (COTS) hardware and soœware updates and replacements. Based on their answers to these questions and many discussions, stakeholders will try to reach consensus on what they believe the content of the new release should be. Because they cannot include everything in the release because of resources limitations (time, money, sta¥, facility hours, etc.), stakeholders submitting requests will have to prioritize them using a set of criteria that everyone believes is fair. Else, all requests for change will have the highest priority because stakeholders would not be submitting them unless they think that they were important.