Software Life Cycle Evolution and Maintenance Insights
Explore the evolution, maintenance, and perpetual development of software life cycles as advocated by experts like Dror Feitelson, David Lorge Parnas, and Meir Lehman. Discover Lehman's Laws that describe how software systems evolve over time.
Uploaded on | 0 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Software Life Cycles: Evolution, Maintenance, and Perpetual Development Dror Feitelson Hebrew University
David Lorge Parnas Major contributor to information hiding and modularization A sign that the Software Engineering profession has matured will be that we lose our preoccupation with the first release and focus on the long term health of our products. Advocate of software development as an engineering discipline Including good documentation! Opponent of star wars Fellow of ACM, IEEE Software Aging, ICSE 1994
Software Lifecycle Maintenance Construction Analysis Transfer Textbook view: Testing Design Req's
Software Lifecycle Maintenance Construction Analysis Transfer Testing Design Textbook view: Req's More realistic view: Construction Analysis Transfer Testing Design Req's EVOLUTION, MAINTENANCE, AND ADDITIONAL RELEASES
Software Lifecycle Maintenance Construction Analysis Transfer Testing Design Textbook view: Req's More realistic view: Construction Analysis Transfer Testing Design Req's EVOLUTION, MAINTENANCE, AND ADDITIONAL RELEASES
Meir (Manny) Lehman On team Building first computers in Israel in 1950s Worked at IBM studying OS/360 Father of software evolution Professor at Imperial College London Received Harlan Mills award Defined E-type systems that are ingrained with their environment Passed away 29.12.10 in Jerusalem Lehman's 8 Laws describe how such systems evolve
Lehman's Laws 1) Continuing change (adaptation) 2) Increasing complexity (unless refactored) 3) Self regulation (of rate of change) 4) Invariant work rate (inertia) 5) Conservation of familiarity (of users and developers) 6) Continuing growth (more features) 7) Declining quality (unless maintained) 8) Feedback system (at multiple levels)
All projects Terminating Evolutionary Project defined by its goals Requirements map to acceptance test Develop-deliver- maintain trajectory Goals are uncovered as project progresses Continue indefinitely as long as useful Multiple releases along the way
All projects Terminating Evolutionary Staged model Perpetual development Repeated cycles Each one is planned with well-defined goals Plan as you go Concurrent sub-projects Fuzzy long- term goals
All projects Terminating Evolutionary Feasibility Three Staged model Perpetual development Architecture milestones Operational Single delivery Multiple releases Continuous deployment
Timescales and Terminology Waterfall / unified process Evolutionary development Agile development Facebook Continuous deployment Once Months Weeks One day < Hour delivery } Release } Deployment (typical of web/cloud) Maintenance Evolution Requirements Feature requests
Maintenance Evolution Maintenance and evolution are sometimes used as synonyms Meaning everything that is done after delivery THIS IS WRONG Maintenance = things done to enable continued use of the existing system Fix bugs, security patches, new drivers Evolution = continue to develop new functionality and release new versions Analogy: building a new wing in a hospital is not maintenance
Categories of Maintenance Corrective bug fixes and emergency fixes Adaptive adapt to changes in environment Perfective improve performance, usability Preventive improve structure (refactor) [Further development (=evolution) sometimes included in perfective or adaptive] other adaptive perfective corrective We ll focus on corrective Schach et al. Emp. Softw. Eng8, 2003
Triage Given a defect report, what do you do? Check defect report Not reported before Enough details to understand / reproduce Prioritize How many users does it affect? How harmful is it? Assign to someone based on attributes and priority Not all issues will necessarily be handled
What Do You Do When Asked to Handle a Reported Defect? Note: This is a bug report from a user, not a bug you found using unit testing in the code you just wrote
What Do You Do When Asked to Handle a Reported Defect? Concept location Search for code implementing concepts related to the defect Keyword-based search (identifiers, documentation) Dependency-based search (follow method calls starting from anchor) Impact analysis Calling and called methods Shared data or propagated effects Actual fix
Evolution and Agile All software projects Terminating Agile can be terminating Agile implies a process Evolutionary Perpetual Agile Evolutionary/ perpetual may be process- less Staged e.g. Linux
Staged Model Each version passes conventional phases e.g. full cycles of Unified Process New versions branch in parallel to maintenance Rajlich & Bennett, Computer 2000
Perpetuity Part of evolutionary development (and many agile and open source projects) New mindset: project will go on forever Useless to make detailed long-range plans Needs to be sustainable Normal work rate Initial development becomes progressively smaller part of the project Maintenance is 75% of investment is meaningless Original Linux kernel <1% of current Linux kernel
Perpetual Development Lifecycle size time
Perpetual Development Lifecycle size Production use & maintenance time
Perpetual Development Lifecycle size feedback & requests Production use & maintenance time
Perpetual Development Lifecycle size Production use & maintenance users upgrade feedback & requests Production use & maintenance time
Perpetual Development Lifecycle feedback & requests size Production use & maintenance users upgrade feedback & requests Production use & maintenance time
Perpetual Development Lifecycle Production & maint. users upgrade feedback & requests size Production use & maintenance users upgrade feedback & requests Production use & maintenance time
Perpetual Development Lifecycle Production & maint. users upgrade feedback & requests size Production use & maintenance users upgrade feedback & requests Production use & maintenance time
How Would You Classify Programs You Use?
How Would You Classify Programs You Use? Windows, Word, Excel Android, WhatsApp, Angry Birds Gmail, Facebook, Amazon Bank account management system Traffic light control system Healthcare database system
Linux is evolution, not intelligent design -- Linus Torvalds
Eric Raymond: The Cathedral and the Bazaar Planning and management Evolution
Raymonds Main Insights Open-source developers are scratching a personal itch , so they know the requirements Having real users leads to real feedback with enough eyeballs, all bugs are shallow (Linus s Law) Users are co-developers, may come up with good ideas Release early, release often leads to the most rapid progress
Linux Old Release Model Distinction between versions Production is stable Development is current Distinction between releases Minor production release for bug/security fixes Minor development release every few days A major release is a major operation taking months Interval between major releases is long Two years of delaying new features
Linux New Release Model (2.6) Only production versions are released Development done separately in parallel New version every 2-3 months Merge window of 2 weeks ~2 months of stabilization and preparation Few minor releases as needed New merge window opened at time of release Maintain some long-term versions for stability
Software Growth Lehman s Law I: Continuing change Adapt to needs Lehman s Law VI: Continuing growth Add features Code is rarely removed Are you sure it is never needed? Hard to figure out exactly what is not needed any more Reluctance to throw away what took long to produce Change is achieved by growth
Software Growth Lehman and Turski: A system's complexity grows with time It is harder to modify a more complex system Assuming a constant effort per release, E = + s s + 1 i i 2 i s This leads to a diminished growth rate: si 3i
Software Growth Godfrey and Tu (2000): Linux (and other systems) is growing at a super-linear rate
More Data 1994 to 2011 78x growth (29% annual) Best models: Quad.-exponential Piecewise linear No theory 3541 l/d 1385 l/d 660 l/d
Growing Growth Rate Possible explanation: Positive feedback Successful project attracts more developers More developers produce more code Suggests exponential growth Contradicts Brooks sLaw ( adding manpower to a late project makes it later ) System is modular so don t need so much communication Good information dissemination via mailing lists etc. New developers are typically already experts, not novices
Complexity and Quality Lehman s Law II: Increasing complexity Interactions between more and more modules Lehman s Law VII: Declining quality Harder to improve less satisfying The tradeoff: Do it fast vs. do it right The compromise: Technical debt Fast-and-dirty = accumulate debt Refactoring = pay off debt (with interest) Cost-benefit decision of when (and if) to pay
Continuous Deployment Variant New software released in timescales of minutes, not days or weeks Each developer immediately deploys whatever he works on Based on passing a battery of automatic tests (unit + integration + regression) Requires strong framework to control releases and roll them back if needed Makes the whole notion of a version meaningless
Continuous Deployment Variant Popular mainly in web-based companies and applications Deploy to web site No need to download and install Immediately used by all Facilitates A/B testing Can be done at different granularities Facebook deploys front-end twice a day Amazon deploys update to some service every 11 seconds on average
Facebook Deployment Pipeline All code is reviewed Passes ~50,000 regression tests Used internally by all FB employees Deployed incrementally Controlled with gatekeeper
A/B Testing Randomly channel subsets of customers to two version of the system 1. A = old system 2. B = new version with some change Measure how they behave Time spent in system Conversion rate to buying something Decide whether to adopt the change Use experimental data instead of assumptions Applicable to large-volume web-based systems
Perpetual Development Benefits Lead time to first working version is short, and a working version is always available No danger of the project coming to nothing Real users doing real work are effectively brought into the development cycle Test functionality and identify bugs Use for A/B testing and honing functionality Prioritize further development according to what is really needed Ability to use new technology as it becomes available
Implications for Development No fixed goal that has to be reached Goal is to continually improve the system and maintain is usefulness Monitor system usage to identify inadequacies Prioritize according to user needs Don't plan too far ahead (YAGNI protection) Use contracts that take longevity into account Support for continued evolution Access to code if company becomes insolvent
