University of Toronto Source Adapted from Lehman 1980 pp1061 1063 S type Programs Specifiable problem can be stated formally and completely Basics of Software Evolution acceptance Is the program correct according to its specification This software does not evolve Laws of software evolution A change to the specification defines a new problem hence a new program Requirements Growth Software Aging Department of Computer Science Program Types Lecture 21 Software Evolution University of Toronto Department of Computer Science Basics of Change Management P type Programs Problem solving imprecise statement of a real world problem acceptance Is the program an acceptable solution to the problem Baselines Change Requests and Configuration Management Software Families The product line approach Requirements Traceability 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 Importance of traceability E type Programs Embedded A system that becomes part of the world that it models Traceability tools acceptance depends entirely on opinion and judgement This software is inherently evolutionary changes in the software and the world affect each other 1 Easterbrook 2004 University of Toronto University of Toronto Department of Computer Science formal statement of problem real world maybe of interest to controls the production of Source Adapted from Lehman 1980 pp1061 1063 change PROGRAM solution real world P type change continues until it is judged more cost effective to replace the system compare change unless steps are taken to control it change solution with statistically determinable trends and invariants abstract view of world Conservation of Organizational Stability During the active life of a software system the work output of a development project is roughly constant regardless of resources model Easterbrook 2004 Fundamental Law of Program Evolution Software evolution is self regulating PROGRAM PROGRAM requirements specification Increasing Complexity As software evolves its complexity increases requirements specification E type real world Continuing Change Any software that reflects some external reality undergoes continual change or becomes progressively less useful abstract view of world provides S type Department of Computer Science Laws of Program Evolution Source Adapted from Lehman 1980 pp1061 1063 may relate to 2 Easterbrook 2004 Conservation of Familiarity The amount of change in successive releases is roughly constant 3 Easterbrook 2004 4 1 University of Toronto Department of Computer Science Requirements Growth Alternative lifecycle models Source Adapted from Davis 1988 pp1455 1459 Traditional development always lags behind needs growth User needs Throwaway Prototyping User needs Easterbrook 2004 University of Toronto Time Incremental Development User needs Time Automated Software Synthesis User needs Time 5 Time 6 Easterbrook 2004 University of Toronto Department of Computer Science Software maintenance Department of Computer Science Software Aging Source Adapted from Blum 1992 p492 495 Source Adapted from Parnas 1994 Maintenance philosophies throw it over the wall someone else is responsible for maintenance Causes of Software Aging Failure to update the software to meet changing needs investment in knowledge and experience is lost maintenance becomes a reverse engineering challenge Customers switch to a new product if benefits outweigh switching costs Changes to software tend to reduce its coherence mission orientation development team make a long term commitment to maintaining enhancing the software User needs shaded area Shortfall first release implements only part of the original requirements Adaptability functional enhancement adds new Lateness slope of line functionality Longevity eventually further enhancement becomes too costly and a replacement is planned Time d ts re se the replacement also only se en ce l i v e se ha ha m a a p l p e e implements part of its e p l t t ir re t d re en en qu n t requirements d re em em rs an e m e y fi nc nc f e and so on i a c a z t h h ee p l a en en en fr r e id Evolutionary Prototyping Inappropriateness Functionality Imagine a graph showing growth of needs over time May not be linear or continuous hence no scale shown conventional development Functionality User needs evolve continuously Functionality model Functionality Source Adapted from Davis 1988 pp1453 1455 Davis s Department of Computer Science Functionality University of Toronto Costs of Software Aging Owners of aging software find it hard to keep up with the marketplace Basili s maintenance process models Deterioration in space time performance due to deteriorating structure Quick fix model Aging software gets more buggy changes made at the code level as easily as possible rapidly degrades the structure of the software Each bug fix introduces more errors than it fixes Iterative enhancement model Changes made based on an analysis of the existing system attempts to control complexity and maintain good design Ways of Increasing Longevity Design for change Document the software carefully Full reuse model Requirements and designs should be reviewed by those responsible for its maintenance Starts with requirements for the new system reusing as much as possible Needs a mature reuse culture to be successful Software Rejuvenation Easterbrook 2004 7 Easterbrook 2004 8 2 University of Toronto University of Toronto Department of Computer Science Managing Requirements Change Change Management Managers need to respond to requirements change Add new requirements during development Configuration Management Each distinct product is a Configuration Item CI But not succumbing to feature creep Each configuration item is placed under version control Modify requirements during development Control which version of each CI belongs in which build of the system Because development is a learning process Remove requirements during development requirements scrub for handling cost schedule slippage Department of Computer Science Baselines A baseline is a stable version of a document or system Safe to share among the team Key techniques Formal approval process for changes to be incorporated into the next baseline Change Management Process Release Planning Requirements Prioritization previous lecture Requirements Traceability Change Management Process All proposed changes are submitted formally as
View Full Document
Unlocking...