160 likes | 274 Views
ITEC 370. Lecture 22 Maintenance. Review. Questions? Project update on F, next F give prototype demonstration Interface testing Checklist of design features Users. Objectives. Maintenance What do you do once it is delivered???. Fin. Congrats, you just delivered your product.
E N D
ITEC 370 Lecture 22 Maintenance
Review • Questions? • Project update on F, next F give prototype demonstration • Interface testing • Checklist of design features • Users
Objectives • Maintenance • What do you do once it is delivered???
Fin • Congrats, you just delivered your product
Now what • Decide on the style of maintenance you want to follow • Reactive • Proactive
Reactive • Status quo and keeping it • Only react when a client requests a fix • Corrective maintenance • Benefits • Less attention required to details • Retraining less of an issue • Downsides • Not good for publicity of product • Miss opportunities
Example • DGL – software created for my dissertation • Used by NIST / VT on a daily basis for 5+ years • No new major development for 5+ years • Bug fixes when a particular problem occurs with an application • No new adopters
When • Good for when clients are not apt to change • Expensive retraining • Manufacturing lines • Call centers • You don’t have the resources to do anymore than is necessary • Buggy updates are bad…
Active • Anticipate what is coming down the road • New software versions and compatibility • Preventative maintenance • Competitors products • Improve on what you currently have • Graphics card drivers
iOS software • App store provides millions of users a chance to find software that smaller developers probably wouldn’t ever have been able to put in front of users • AngryBirds anyone? • Requires a lengthy “validation” by Apple beforehand • Apple changes their platform constantly
Betting on maintenance • World of Warcraft • November 23rd 2004 • Team Fortress 2 • Since 2007, would you like a hat with that? • Halloween themed levels
Numbers • Typically • 25% Adaptive • 20% Corrective • 55% Preventative • In other words, time moves on and so must your software
Lehman’s laws • Continuing change • Increasing complexity • Conservation of familiarity • Continuing growth • Declining quality • Feedback system
Environments • Remember the user’s environment may be different than what you use • Remember your environment’s quirks • Remember staging is your best friend
Update testing • Remember, change causes issues • Deleting/corrupting user data • Clean install • Over-write information • Do you force an overwrite? • Only update the pieces needed?
Review • Reactive • Active