Upload
kody-huddy
View
214
Download
1
Tags:
Embed Size (px)
Citation preview
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.
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,…)
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
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
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.
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.
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.
Challenges in Maintenance
1. 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. … ?
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?
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?
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.
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!).
Software Re-Engineering
Re-implement (part or whole). Translate to new programming language
(auto?). Refactor, restructure system. Improve algorithms. Add exception handling. Improve security.
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.
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.
User Experience Re-Engineering Beyond incremental requirements
enhancement. Changes in platform, user interface,
deployment, connections among users. Examples? Challenges? Advice?
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.
Guidelines for SW Maintenance6. Update documents.
Requirements, specs, V & V records
7. Control and release versions carefully.8. Allow user input via bug reports,
change requests.9. Use software tools to support the
process.