1 / 23

Software Evolution

Software Evolution. The Transition Phase The show hits the road: Deployment Maintenance Re-engineering A final word….

lola
Télécharger la présentation

Software Evolution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Evolution • The Transition Phase • The show hits the road: • Deployment • Maintenance • Re-engineering • A final word… • An airplane is nothing more than a collection of parts having an inherent tendency to fall to earth, and requiring constant effort and supervision to stave off that outcome. – K. Gorlen UNIX System V

  2. The Transition Phase • In the UP transition phase, the system is transferred to the user community. • It’s activities include: • Deployment • Technical support and training • Maintenance • Software Systems evolve over time.

  3. Relative Effort: Phases data from Schach, 2002

  4. System Deployment • Deployment is not the end of the road. • Packaging/distribution • Installation • Systems are deployed as an architecture of physical devices and software environments.

  5. Deployment Diagrams • Their physical architectures have the following elements: • Physical devices • Software execution environments • Software artifacts • Communication lines • UML Deployment Diagrams can be used to communicate these architectures.

  6. Example: Deployment Diagram Example adapted from Fowler, 2003

  7. Outline • Deployment Diagrams • Nodes • Artifacts • Associations • Using Deployment Diagrams

  8. Nodes • Deployment diagram nodes can represent: • Physical devices • Software execution environments • These stereotypes are helpful, but are not standardized.

  9. Artifacts • Artifacts are the physical manifestations of software components. • They are stored on/in nodes.

  10. Assocations • Associations represent communication paths and protocols.

  11. Using Deployment Diagrams • Use deployment diagrams to show: • what is deployed where; • how the communication flows. • Any non-trivial deployment can benefit from their use.

  12. Legacy Systems • Systems can eventually become legacy systems. • Legacy systems: • are entrenched; • have ceased to evolve; • continue to be used because their replacement cost is too high.

  13. System Maintenance • Maintenance sustains a software system throughout its life-cycle. • Software deteriorates as it evolves. • Reasons for post-delivery modification: • Corrective maintenance • Perfective maintenance • Adaptive maintenance

  14. Relative Effort: Maintenance Types data from: Schach et al, 2003

  15. The Joy of Maintenance • Maintenance is seen as • an after-the-fact activity • unrelated to the software development • Problems: • Users are usually dissatisfied. • Problems are frequently caused by someone else. • You’re on the bottom rung of the life-cycle food-chain. • There are limited support tools.

  16. Change Management Tools • Managing defects • Fixing defects • Testing fixes

  17. Regression Testing re·gres·sion  (re -greh shun) n. Relapse to a less perfect or developed state. • Changing software tends to break things. • Regression testing checks that the system still operates properly after change.

  18. Engineering for Evolution • Good software engineering should anticipate evolution. • Silver bullets? • “Heavy” software engineering? • Object-Oriented design? • Agile development?

  19. Re-Engineering • Re-implementing an existing system, with minimal analysis and design, e.g.: • Re-documenting a system • Re-structuring a system • Translating a system code to a newer language • Porting a system to a new platform • This can be cheaper than developing a new system or fixing an old one.

  20. Reasons to Re-Engineer • To support a more modern platform • To move to a better supported language • To improve efficiency • To make the system more understandable in order to support maintenance

  21. Types of Re-Engineering Automated Code conversion Manual program/data restructuring CheapExpensive Automated Program restructuring Manual architectural restructuring from: Sommerville, 2001

  22. Reverse Engineering • The process of deriving abstract formal specifications from the source code of a legacy system • This is used to support: • System re-engineering • System replacement

  23. What’s the Big Idea Fredrick P. Brooks (1931- )The Mythical Man-Month • Brooks considered evolution to be one of the essential characteristics of software systems. • He gives the following advice to young managers: Numquam incertus; semper apertus image from: http://www.unc.edu/

More Related