University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1Lecture 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© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2Program 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© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3realworldrequirementsspecificationPROGRAMabstractview of worldsolutioncompareP-typereal worldPROGRAMabstractview of worldrequirementsspecificationmodelE-typeformalstatementof problemPROGRAMsolutionrealworldcontrols theproductionofprovidesmaybe ofinterest tomayrelatetochangechangechangeS-typeSource: Adapted from Lehman 1980, pp1061-1063University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 4Source: 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 constantUniversity of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 5Requirements GrowthDavis’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© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 6Software 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, 1994University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 7Software “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© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 8Managing Requirements Change Managers need to respond to requirements change Add new requirements during development But not succumbing to feature
View Full Document
Unlocking...