University of Toronto University of Toronto Department of Computer Science Department of Computer Science Outline Lecture 11 Evolving Requirements Last Last Week Week Specification Specification Validation Validation Document DocumentStandards Standards Inspections Inspections Prototyping Prototyping Prioritization Prioritization Laws of software evolution Baselines Change Requests and Configuration Management Beyond specification singularity Software Families The product line approach This This Week Week Evolving Evolving Requirements Requirements Change Changemanagement management Product ProductFamilies Families Traceability Traceability Inconsistency Inconsistencymanagement management Inconsistency Management Basics of viewpoints Expressing consistency rules Reasoning in the presence of inconsistency Next Next Week Week 2000 2004 Steve Easterbrook 1 University of Toronto Requirements Traceability Importance of traceability Traceability tools Contribution structures How Howmuch muchFormality Formality Appropriate Appropriateuse useof of Formal Formalmethods methodsininRE RE Department of Computer Science Program Types 2000 2004 Steve Easterbrook 2 University of Toronto may relate to 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 formal statement of problem real world maybe of interest to 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 change 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 solution real world P type abstract view of world provides S type real world compare change requirements specification solution PROGRAM PROGRAM abstract view of world requirements specification model changes in the software and the world affect each other 2000 2004 Steve Easterbrook change E type because the solution is never perfect and can be improved because the real world changes and hence the problem changes controls the production of PROGRAM A change to the specification defines a new problem hence a new program Department of Computer Science Source Adapted from Lehman 1980 pp1061 1063 Source Adapted from Lehman 1980 pp1061 1063 Basics of Software Evolution 3 2000 2004 Steve Easterbrook 4 1 University of Toronto Department of Computer Science Laws of Program Evolution Requirements Growth Source Adapted from Davis 1988 pp1453 1455 Source Adapted from Lehman 1980 pp1061 1063 Continuing Change Davis s Any software that reflects some external reality undergoes continual change or becomes progressively less useful Imagine a graph showing growth of needs over time May not be linear or continuous hence no scale shown Increasing Complexity Traditional development always lags behind needs growth As software evolves its complexity increases unless steps are taken to control it 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 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 model User needs evolve continuously change continues until it is judged more cost effective to replace the system The amount of change in successive releases is roughly constant 2000 2004 Steve Easterbrook 5 Functionality Functionality User needs shaded area Shortfall Adaptability Lateness Longevity slope of line Time 6 University of Toronto Alternative lifecycle models Source Adapted from Davis 1988 pp1455 1459 Inappropriateness 2000 2004 Steve Easterbrook Department of Computer Science Throwaway Prototyping User needs conventional development d ts re se se en e ce live ha ha m as la le tp t p rep de ire e n n u e q nt d t r eme m re rs an me ce c y fi an an ze lace tif h h e n n n e p e e e fr re id Conservation of Familiarity University of Toronto Department of Computer Science Functionality University of Toronto Department of Computer Science Software maintenance Evolutionary Prototyping Source Adapted from Blum 1992 p492 495 User needs 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 Incremental Development User needs Time Functionality Functionality Time 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 Automated Software Synthesis User needs 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 Time 2000 2004 Steve Easterbrook Time 7 2000 2004 Steve Easterbrook 8 2 University of Toronto University of Toronto Department of Computer Science Traditional Change Management Beyond Product Singularity Managers need to respond to requirements change Add new requirements during development Most RE techniques focus on individual models Build a model get it consistent and complete then validate it Assumes that RE is a process with a single definite output But not succumbing to feature creep Modify requirements during development The output is a complete consistent valid specification of the requirements Because development is a learning process Remove requirements during development requirements scrub for handling cost schedule slippage This ignores reality Requirements Engineering isn t just about obtaining a specification Requirements are volatile changes need to be managed continuously The specification is never complete anyway Elements of Change Management Configuration Items There is never just one model Each distinct product during