Department of Computer Science University of Toronto Lecture 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 tools 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 1 Department of Computer Science University of Toronto Program Types Source Adapted from Lehman 1980 pp1061 1063 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 other 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 2 Department of Computer Science University of Toronto Source Adapted from Lehman 1980 pp1061 1063 may relate to formal statement of problem real world maybe of interest to controls the production of change PROGRAM solution real world abstract view of world provides S type P type compare change requirements specification E type change real world solution PROGRAM PROGRAM abstract view of world requirements specification model 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 3 Department of Computer Science University of Toronto Laws of Program Evolution Source Adapted from Lehman 1980 pp1061 1063 Continuing Change Any software that reflects some external reality undergoes continual change or 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 a development project is roughly constant regardless of resources Conservation of Familiarity The amount of change in successive releases is roughly constant 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 4 Department of Computer Science University of Toronto Requirements Growth Source Adapted from Davis 1988 pp1453 1455 Davis s model conventional development Imagine a graph showing growth of needs over time May not be linear or continuous hence no scale shown Traditional development always lags behind needs growth first release implements only part of the original requirements functional enhancement adds new functionality eventually further enhancement becomes too costly and a replacement is planned the replacement also only implements part of its requirements and so on Functionality User needs evolve continuously User needs Inappropriateness shaded area Shortfall Adaptability Lateness slope of line Longevity t en s se e er d c e li v ha a l p e p r l nt nt ui re t d re e e q n t nd me re em em rs a i c c y f an an z e la c e t if h h e n e p e en en fr re id em s ea e a ph se 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license Time 5 Department of Computer Science University of Toronto Software Aging Source Adapted from Parnas 1994 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 its maintenance Software Rejuvenation 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 6 Department of Computer Science University of Toronto Software maintenance Source Adapted from Blum 1992 p492 495 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 to maintaining 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 successful 2004 5 Steve Easterbrook This presentation is available free for non commercial use with attribution under a creative commons license 7 University of Toronto Department of Computer Science Managing 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 2004 5 Steve
View Full Document
Unlocking...