160 likes | 276 Views
ITEC 370. Lecture 23 Maintenance. Review. Questions? Project update on F, next F give prototype demonstration Maintenance Reactive Proactive. Halloween. CS version of trick or treating. Objectives. Maintenance Beyond just making it continue working…. Questions.
E N D
ITEC 370 Lecture 23 Maintenance
Review • Questions? • Project update on F, next F give prototype demonstration • Maintenance • Reactive • Proactive
Halloween • CS version of trick or treating
Objectives • Maintenance • Beyond just making it continue working…
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
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
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
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
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.
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
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
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?
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
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
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
Review • Reactive • Active