Download
itec 370 n.
Skip this Video
Loading SlideShow in 5 Seconds..
ITEC 370 PowerPoint Presentation

ITEC 370

104 Vues Download Presentation
Télécharger la présentation

ITEC 370

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