1 / 16

Software Maintenance: Balancing Features, Bugs, and Quality in Development Projects

This lecture reviews the essential aspects of software maintenance, emphasizing the distinction between reactive and proactive strategies. It discusses when to add new features to existing products, the implications of charging for those features, and how to allocate workforce resources among bug fixing, feature development, and documentation. The relationship between maintenance and software quality is explored, alongside the importance of testing and documentation. The discussion includes debates on promotions and the impact of maintenance on software reputation and stability.

mariah
Télécharger la présentation

Software Maintenance: Balancing Features, Bugs, and Quality in Development Projects

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ITEC 370 Lecture 23 Maintenance

  2. Review • Questions? • Project update on F, next F give prototype demonstration • Maintenance • Reactive • Proactive

  3. Halloween • CS version of trick or treating

  4. Objectives • Maintenance • Beyond just making it continue working…

  5. Questions • When should you add new features to an existing product? • When should you charge for said features? • What % of workforce would you devote to • Fixing bugs • Adding new features • Writing more documentation

  6. Debate • How would you handle promotions / raises for • Developer working on latest new project • Developer maintaining an old profitable system • Developer splitting their time between the two

  7. Issues • Software that requires considerable corrective maintenance (i.e. fixing bugs) is not good for your reputation • Probably shows that the testing plan is not being followed or is not comprehensive enough

  8. Issues • Maintenance preserves or enhances quality • Sometimes requires re-engineering • Code can get sloppy, disorganized, less readable • Enough of the above and a software project can be paralyzed • Re-write or reversion to main system sometimes necessary

  9. In short • Software is never perfect • Don’t’ try and write perfect software • Write software that is good enough • Cover your bases… 25. LIMITATION ON AND EXCLUSION OF DAMAGES. You can recover from Microsoft and its suppliers only direct damages up to the amount you paid for the software. You cannot recover any other damages, including consequential, lost profits, special, indirect or incidental damages.

  10. Maintenance • Can have ties / relationships with previous segments of the overall cycle • Requirements • Guarantee that changes keep fulfilling existing requirements • Ideas for new features • Design • Small / large scale changes and their impact on the design itself

  11. Implementation • Can get ugly • Reverse engineer what was done • How did Chuck do … • Documentation (software) is critical • Sometimes requires picking up dead end skills • Whoever thought smalltalk was going to be the greatest language ever… • Don’t forget static analysis

  12. Testing • Should be on the forefront of your mind when you are maintaining software… • Automatic testing is your friend • “Gold standard” • What are the effects of your changes?

  13. Testing • Need to extensively test your updates • Anti-virus update formatting HD instead… • Check version level of existing software before letting update be applied • V1 to V6 isn’t going to be same as V5 to V6 • Complete vs partial re-write • Easy for developer vs user

  14. Feedback • Collect data on bugs you find • Who created the software in the first place • Who tested the software • Who said it was releasable • Be careful • Sometimes making someone directly responsible isn’t the best idea • Dozens of variables, only gross negligence is easy to find

  15. Evolution • Remember this isn’t about creating version 2.0 • Evolution is different than maintenance • Need to have clear goals of • What is acceptable in maintenance • What is considered a new version • Don’t want to get stuck on v. 1.950

  16. Review • Reactive • Active

More Related