Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

CSSE375-03-framework.ppt

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Nächste SlideShare
lecture_Analysis Phase.ppt
lecture_Analysis Phase.ppt
Wird geladen in …3
×

Hier ansehen

1 von 13 Anzeige

Weitere Verwandte Inhalte

Ähnlich wie CSSE375-03-framework.ppt (20)

Anzeige

Aktuellste (20)

CSSE375-03-framework.ppt

  1. 1. Maintenance Framework Steve Chenoweth CSSE 375, Rose-Hulman Based on Don Bagert’s 2006 Lecture Ref M 2
  2. 2. 2 Today • Turn in last Friday’s quiz, if not already… • Any Q on “one minute talk” for Thurs (& turn-in on Angel Wed night)? • Finish off yesterday’s stuff – Intro to Maint & Constr • Today’s topic – this • Maybe just a start on Thursday’s topic – Software Change
  3. 3. 3 Definition • A framework is a set of ideas, conditions or assumptions that determines how something will be approached, perceived on understood
  4. 4. Discussion: Who and what need to be involved in software maintenance?
  5. 5. 5 Software Maintenance Framework Components • User Requirements • Organizational Environment • Operational Environment • Maintenance Process • Software Product • Maintenance Personnel
  6. 6. 6 User Requirements • Requests for additional features – Usually – Wait for next release – Specials for key customers or submarkets • Correction of defects (bugs) – Fix now – Wait for next release • Other support (e.g. training, help desk) – Should developers take a turn at the help desk?
  7. 7. 7 Organizational Environment • Change in Policies – FDA – 13485 compliance – Banking, Insurance, … • Competition – They announce the iPhone • Add - Internal management changes – Your group is merged with another group, under their old management
  8. 8. 8 Operational Environment • New Platform – Hardware – Operating System – Third Party Software • Nasty scenario – One of the components you use forces you to do an expensive upgrade • Nastier – That upgrade won’t work with other components you have to use
  9. 9. 9 Maintenance Process • Capturing requirements / maintenance requests • Investigating and prioritizing those requests – Creativity and undocumented assumptions • Variation in programming practice – Coding and documentation standards • Paradigm shift – Programs with “old structures” that are now indecipherable • Dead paradigms for living systems – Legacy code issues – Fixed Point Theorem for Info Systems • Error detection and correction – Finding the root cause of software errors… growing cost as the system is developed – and used! 
  10. 10. 10 Maintenance Process - Error detection and correction
  11. 11. 11 Software Product • Application domain issues – domains mature • Documentation quality – causes support issues • Code flexibility – No clear standards for code changes (vs the rest of engineering) • Code complexity – keeps getting worse • Program structure – ditto, unless refactored • Product quality – kinda like entropy
  12. 12. 12 Maintenance Personnel • Staff Turnover – A total killer of maintenance capability – Which often means, key people can never leave! • Application Domain Expertise – A critical intellectual property • Working Practices – The “attitude” thing. A long-term focus is required of the people
  13. 13. Discussion: What relations and interactions with the product are the most important in maintenance?

×