Software Maintenance

28
SOFTWARE MAINTENANCE 24 March 2013 William W. McMillan

description

Software Maintenance. William W. McMillan. 24 March 2013. Who wants to do software maintenance? If this is not your cup of tea, why not?. Software “Evolution”. Term is a good one. But can be confused with “evolutionary development.” - PowerPoint PPT Presentation

Transcript of Software Maintenance

Page 1: Software Maintenance

SOFTWARE MAINTENANCE

24 March 2013 William W. McMillan

Page 2: Software Maintenance

Who wants to do software maintenance?

If this is not your cup of tea, why not?

Page 3: Software Maintenance

Software “Evolution” Term is a good one. But can be confused with “evolutionary

development.” Focus here is on what happens to

software after initial delivery. Yes, it evolves, but only after it was

created intentionally. “Maintenance” has been most common

term.

Page 4: Software Maintenance

Most Software Effort is Here Systems may be around for decades. Adding functional increments much

harder in older systems than in brand new.

Have to deal with loss of: Tools and platforms Knowledge (developers, management,

users) Ways of working (e.g. plan-based to agile) Conducive environment (leadership, access

to users, team energy,…)

Page 5: Software Maintenance

What difficulties have you had in changing software after initial creation?

Page 6: Software Maintenance

Kinds of Maintenance (Old)

Corrective (~ 20%) Fixing errors

Adaptive (up to 25%) New software or hardware environment

“Perfective” (50% +) Enhancements, changes in requirements

Preventative (~ 0%) Cleaning house, tidying up, documenting

Page 7: Software Maintenance

Kinds of Maintenance (Newer)

Fault repair (17%) Fixing errors

Environmental adaptation (18%) New software or hardware environment

Functionality addition, modification (65%) Enhancements, changes in requirements

Preventative (~ 0%) Cleaning house, tidying up, documenting

Page 8: Software Maintenance

What could be done to encourage preventative maintenance?

Page 9: Software Maintenance

The Payoff for Good Engineering Most of software engineering supports

maintenance. More effort early leads to easier

maintenance. One estimate:

over 80% of maintenance effort caused by incorrect requirements and specs.

Key in getting management support for software engineering.

Page 10: Software Maintenance

Cost of Maintenance Proportion of code changed per year

times original cost of system. Annual maintenance effort =

annual change traffic * software development time

AME = ACT * SDT (in person-months) Oversimplification – need to consider all

other COCOMO factors.

Page 11: Software Maintenance

What Has To Be Maintained Code. Databases. Documents:

Requirements, user manuals, help files, design documents.

Installations: Workstations, mobile devices, embedded systems.

V & V records, test data sets. Archives

Past system configurations, management docs, changes.

Page 12: Software Maintenance

Why is maintenance hard?

Page 13: Software Maintenance

Challenges in Maintenance1. Hard to get resources for good software

engineering to begin with.2. Hard to get resources to maintain old

stuff.3. Lose knowledge of system and domain

expertise.4. People don’t like to do it.5. … ?

Page 14: Software Maintenance

Lehman & Belady’s “Laws” Continuing change

Nothing in software is static: OSs, needs, delivery modes…

Increasing complexity When has a system ever gotten simpler?

Continuing growth Need growing functionality to satisfy users

and clients. Declining quality

Counter-examples?

Page 15: Software Maintenance

Lehman & Belady’s “Laws” Large program evolution is “self-

regulating” Can’t push change beyond a natural limit.

Conservation of familiarity Systems maintain their basic character … any examples of those that change

drastically?

Page 16: Software Maintenance

Any other software “laws” you can think of?

Page 17: Software Maintenance

Software Re-Engineering Reimplementation of major parts or all. Legacy systems have old..

languages, hardware, OSs, coding practices, algorithms, interfaces

Over 1011 lines of code in existence. Heavy reliance on old systems.

Page 18: Software Maintenance

Software Re-Engineering Understand intent of present system.

Documents, domain, context of use Recover architecture and abstractions. Use reverse engineering tools. Find interactions, dependencies,

coupling, redundancies. Understand algorithms.

Especially if speed, memory use or similar at issue.

Interviewing people is critical (if they’re around!).

Page 19: Software Maintenance

Software Re-Engineering Re-implement (part or whole). Translate to new programming language

(auto?). Refactor, restructure system. Improve algorithms. Add exception handling. Improve security.

Page 20: Software Maintenance

Software Re-Engineering Switch paradigm, say to object-oriented

or functional. Improve robustness and quality (reduce

coupling, better style, etc.). Improve V & V. Update documents.

Page 21: Software Maintenance

Have you ever had to recover software architecture from code alone?

Page 22: Software Maintenance

Data Re-Engineering Newer file formats, directory structures. Change field types, sizes, etc. Improve numeric precision. Improve validation rules. Establish or change default values. Change units of measurement. Implement new data model (e.g.,

relational). Modify database keys & indexing. Normalize database.

Page 23: Software Maintenance

What data re-engineering has been necessary in recent years for many systems?

Page 24: Software Maintenance

User Experience Re-Engineering Beyond incremental requirements

enhancement. Changes in platform, user interface,

deployment, connections among users. Examples? Challenges? Advice?

Page 25: Software Maintenance

Guidelines for SW Maintenance

1. Expect it, plan for it.2. Use good people and pay them well.3. Understand the system thoroughly:

Architecture, algorithms, V & V done, domain.

4. Isolate changes, change minimally.5. Use regression testing.

Page 26: Software Maintenance

Guidelines for SW Maintenance6. Update documents.

Requirements, specs, V & V records7. Control and release versions carefully.8. Allow user input via bug reports,

change requests.9. Use software tools to support the

process.

Page 27: Software Maintenance

Other maintenance guidelines?

Page 28: Software Maintenance

Exercise

Your software engineering group is called in to help a company evaluate its software maintenance operation. What six to 12 indicators would you look at to assess the state of their operation? If you can, give quantitative measures you would like to see.