Maintenance Framework Steve Chenoweth CSSE 375, Rose-Hulman Based on Don Bagert’s 2006 Lecture Ref M 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 Definition A framework is a set of ideas, conditions or assumptions that determines how something will be approached, perceived on understood

Discussion: Who and what need to be involved in software maintenance?

5 Software Maintenance Framework Components User Requirements Organizational Environment Operational Environment Maintenance Process Software Product Maintenance Personnel

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 Organizational Environment Change in Policies –FDA – compliance –Banking, Insurance, … Competition –They announce the iPhone Add - Internal management changes –Your group is merged with another group, under their old management

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 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 Maintenance Process - Error detection and correction

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

Discussion: What relations and interactions with the product are the most important in maintenance?