DOC PREVIEW
Toronto CSC 340 - Lecture 21 - Software Evolution

This preview shows page 1-2 out of 5 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1University of TorontoDepartment of Computer Science© Easterbrook 20041Lecture 21:Software Evolution Basics of Software Evolution Laws of software evolution Requirements Growth Software Aging Basics of Change Management Baselines, Change Requests and Configuration Management Software Families - The product line approach Requirements Traceability Importance of traceability Traceability toolsUniversity of TorontoDepartment of Computer Science© Easterbrook 20042Program Types S-type Programs (“Specifiable”) problem can be stated formally and completely acceptance: Is the program correct according to its specification? This software does not evolve. A change to the specification defines a new problem, hence a new program P-type Programs (“Problem-solving”) imprecise statement of a real-world problem acceptance: Is the program an acceptable solution to the problem? This software is likely to evolve continuously because the solution is never perfect, and can be improved because the real-world changes and hence the problem changes E-type Programs (“Embedded”) A system that becomes part of the world that it models acceptance: depends entirely on opinion and judgement This software is inherently evolutionary changes in the software and the world affect each otherSource: Adapted from Lehman 1980, pp1061-1063University of TorontoDepartment of Computer Science© Easterbrook 20043realworldrequirementsspecificationPROGRAMabstractview of worldsolutioncompareP-typereal worldPROGRAMabstractview of worldrequirementsspecificationmodelE-typeformalstatementof problemPROGRAMsolutionrealworldcontrols theproductionofprovidesmaybe ofinterest tomayrelatetochangechangechangeS-typeSource: Adapted from Lehman 1980, pp1061-1063University of TorontoDepartment of Computer Science© Easterbrook 20044Source: Adapted from Lehman 1980, pp1061-1063Laws of Program Evolution Continuing Change Any software that reflects some external reality undergoes continual changeor becomes progressively less useful change continues until it is judged more cost effective to replace the system Increasing Complexity As software evolves, its complexity increases… …unless steps are taken to control it. Fundamental Law of Program Evolution Software evolution is self-regulating …with statistically determinable trends and invariants Conservation of Organizational Stability During the active life of a software system, the work output of adevelopment project is roughly constant (regardless of resources!) Conservation of Familiarity The amount of change in successive releases is roughly constant2University of TorontoDepartment of Computer Science© Easterbrook 20045Requirements GrowthDavis’s model:User needs evolve continuously Imagine a graph showing growthof needs over time May not be linear or continuous(hence no scale shown)Traditional development alwayslags behind needs growth first release implements onlypart of the original requirements functional enhancement adds newfunctionality eventually, further enhancementbecomes too costly, and areplacement is planned the replacement also onlyimplements part of itsrequirements, and so on...TimeFunctionalityUser needsidentify requirementsfirst releaseenhancement phasefreeze and replacereplacement deliveredenhancement phaseconventionaldevelopmentLatenessShortfallInappropriatenessLongevityAdaptability(shaded area)(slope of line)Source: Adapted from Davis 1988, pp1453-1455University of TorontoDepartment of Computer Science© Easterbrook 20046Alternative lifecycle modelsTimeFunctionalityUser needsThrowaway PrototypingTimeFunctionalityUser needsEvolutionary PrototypingTimeFunctionalityUser needsIncremental DevelopmentTimeFunctionalityUser needsAutomated Software SynthesisSource: Adapted from Davis 1988, pp1455-1459University of TorontoDepartment of Computer Science© Easterbrook 20047Software “maintenance” Maintenance philosophies “throw-it-over-the-wall” - someone else is responsible for maintenance investment in knowledge and experience is lost maintenance becomes a reverse engineering challenge “mission orientation” - development team make a long term commitment tomaintaining/enhancing the software Basili’s maintenance process models: Quick-fix model changes made at the code level, as easily as possible rapidly degrades the structure of the software Iterative enhancement model Changes made based on an analysis of the existing system attempts to control complexity and maintain good design Full-reuse model Starts with requirements for the new system, reusing as much as possible Needs a mature reuse culture to be successfulSource: Adapted from Blum, 1992, p492-495University of TorontoDepartment of Computer Science© Easterbrook 20048Software Aging Causes of Software Aging Failure to update the software to meet changing needs Customers switch to a new product if benefits outweigh switching costs Changes to software tend to reduce its coherence Costs of Software Aging Owners of aging software find it hard to keep up with the marketplace Deterioration in space/time performance due to deteriorating structure Aging software gets more buggy Each “bug fix” introduces more errors than it fixes Ways of Increasing Longevity Design for change Document the software carefully Requirements and designs should be reviewed by those responsible for itsmaintenance Software Rejuvenation…Source: Adapted from Parnas, 19943University of TorontoDepartment of Computer Science© Easterbrook 20049Managing Requirements Change Managers need to respond to requirements change Add new requirements during development But not succumbing to feature creep Modify requirements during development Because development is a learning process Remove requirements during development requirements “scrub” for handling cost/schedule slippage Key techniques Change Management Process Release Planning Requirements Prioritization (previous lecture!) Requirements Traceability Architectural Stability (next week’s lecture)University of TorontoDepartment of Computer Science© Easterbrook 200410Change Management Configuration Management Each distinct product is a Configuration Item (CI) Each configuration item is placed under


View Full Document

Toronto CSC 340 - Lecture 21 - Software Evolution

Documents in this Course
Scoping

Scoping

10 pages

Load more
Download Lecture 21 - Software Evolution
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 21 - Software Evolution and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 21 - Software Evolution 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?