1 / 12

Software Change

Software Change. Strategies: Software maintenance Code changes, but fundamental structure constant Architectural transformation Significant changes to system architecture

calliope
Download Presentation

Software Change

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 Change Strategies: • Software maintenanceCode changes, but fundamental structure constant • Architectural transformationSignificant changes to system architecture • Software re-engineeringModifications so system is easier to understand, maintain (not motivated by need to add specific functionality) Ch.27 - Software Change

  2. Lehman’s “Laws” • Change is inevitable • As systems change, complexity increase & structure degrades • In large systems, evolution controlled not by management decisions, but by organizational factors. • Evolution is fairly constant, generally unrelated to changes in resources • Rate at which new functionality can be introduced limited [Lehman & Belady (1985)] Ch.27 - Software Change

  3. Forms of Software Maintenance • Repairing software faults • Adaptation to new environment • Addition/modification of functionality Ch.27 - Software Change

  4. Forms of Software Maintenance • Repairing software faults (17%) • Adaptation to new environment (18%) • Addition/modification of functionality (65%) [Leintz & Swanson (1980)] [also Nosek & Palvia (1990)] Lesson: Plan ahead! Ch.27 - Software Change

  5. Spiral Maintenance Model Ch.27 - Software Change

  6. Costs of Software Maintenance • Higher costs due to: • Team (in)stability • Contractual failings • Staff skills • maintenance is less “sexy” • System structure degradation Ch.27 - Software Change

  7. Reaction instead of “proaction” • Emergency bug fixes age system unnecessarily fast • Fixing the fault (at any cost) is highest priority • Cleaning the mess up afterwards ends up as (too) low priority Ch.27 - Software Change

  8. Architectural EvolutionCentralized  Distributed systems Example: migration from a (1980s-style) centralized to a (modern) distributed system Pressures: • Hardware costs mainframes $$$ • User interface expectationsText forms vs. GUIs, mice, etc. • Remote/distributed accessMultiple company sites, Internet Ch.27 - Software Change

  9. Architectural EvolutionCentralized  Distributed systems • Keep old system, but wrap new (distributed) components around it • Legacy system stays on legacy environment • Offloads work, increases traffic support • Can distribute data processing, UI processing • see §27.3 for elaboration Ch.27 - Software Change

  10. Legacy Systems • Old, existing systems that are well-established components of business • Tricky to replace, because: • lack of complete specification • intertwined with business process • may include embedded business rules • replacement software risky Ch.27 - Software Change

  11. Legacy SystemsAssessment Options: • Discard • Continue to maintain • Transform (improve maintainability) • Replace Ch.27 - Software Change

  12. Legacy SystemsAssessment Assessments: • Low quality, low business valueCandidate for discarding • Low quality, high business valueExpensive to maintain: transform or replace • High quality, low business valueNot worth attention: maintain or discard • High quality, high business valueIdeal: continue regular maintenance Ch.27 - Software Change

More Related