Software Life Span Models PDF

Department of Computer Engineering and Sciences CSE 2410 Software Engineering Software Life Span Models Read Chapter -2- Khaled Slhoub, PhD © 2...

Department of Computer Engineering and Sciences CSE 2410 Software Engineering Software Life Span Models Read Chapter -2- Khaled Slhoub, PhD © 2012 Václav Rajlich Software Engineering: The Current Practice 1  Staged Model of Software Life Span Stages through which software goes, from conception to the last day of use Stages may be very different Software = product – stages are similar to the stages in the life span of other products – names of stages are different © 2012 Václav Rajlich Software Engineering: The Current Practice 2  Product Life Span/Cycle Unique proprietary software but it follows the same above curve © 2012 Václav Rajlich Software Engineering: The Current Practice 3  Staged Model of Software Life Span Life span models offer a simplified and comprehensive view of the entire software engineering discipline © 2012 Václav Rajlich Software Engineering: The Current Practice 4  Initial Development It produces the first version of the software (start from scratch) Requirements Design Implementation – similar to waterfall, but of limited duration Fundamental decisions – technology programming language, tools, coding conventions, libraries,… – architecture components, interactions – program domain knowledge the knowledge is required for evolution © 2012 Václav Rajlich Software Engineering: The Current Practice 5  Evolution Adapts the application to the ever-changing user and operating environment Adds new features and corrects mistakes and misunderstandings Responds to both developer and user learning Responds to changes in technology Program usually grows during evolution The customers receive the results of software evolution in form of different software releases Software changes are the basic building blocks of software evolution © 2012 Václav Rajlich Software Engineering: The Current Practice 6  Evolution Ends Software stabilization – problem is solved – no reason to continue evolution – Some domains never achieve stability Managerial decision – business reasons to stop evolution – limit changes to a bare minimum. Code decay – complexity of the code gets out of hand – Loss of the software knowledge – © 2012 Václav Rajlich Software Engineering: The Current Practice 7  Servicing No additions of new functionality No longer make major changes – make only small repairs that keep the software usable Once software is in the servicing stage, it is very difficult and expensive to reverse – hard to return it back into the evolution stage – rare Reengineering a process that reverses code decay and returns software to the stage of evolution, but it is expensive and risky process – the knowledge of the software team must be recovered – not simply a technical problem © 2012 Václav Rajlich Software Engineering: The Current Practice 8  Phase-out Software is not worthy of any further repairs No more servicing is being undertaken – but the system still may be in production Users must work around any remaining defects © 2012 Václav Rajlich Software Engineering: The Current Practice 9  Close-down Software use is disconnected – current life of successful software: about 10-20 years – Recent studies have shown the average software program lifespan over the last 20 years to be around 6-8 years. – for larger programs, so that for extremely large complex programs (i.e., over a million Lines of Code) the average climbs as high as 12-14 years. Users are directed towards a replacement An ‘exit strategy’ is needed. – changing to another system requires retraining – what to do with long-lived data? © 2012 Václav Rajlich Software Engineering: The Current Practice 10  Variants of Staged Model Some software projects do not pass through all stages, but skip some of them – unsuccessful projects terminate prematurely – other projects terminate after several iterations of evolution Pure evolutionary projects start as an extension of an existing software and evolve it into a new and different one Small and short-lived projects may skip software evolution and go directly into servicing and consequent stages © 2012 Václav Rajlich Software Engineering: The Current Practice 11  Incomplete Lifespans Discontinued projects – stopped during initial development Development starts with evolution – a related old software is evolved into new one Stable domain – no need for evolution © 2012 Václav Rajlich Software Engineering: The Current Practice 12  Variants of Staged Model Initial development Evolution is the backbone of the process first running version evolution produces versions versions are serviced, phased-out, closed down evolution changes Evolution Version 1 servicing patches Servicing Version 1 evolution of new version evolution changes Phase-out Version 1 Evolution Version 2 servicing patches Close-down Version 1 Servicing Version 2 evolution of new version Phase-out Version 2 Close-down Version 2 Evolution Version... © 2012 Václav Rajlich Software Engineering: The Current Practice 13  Versioned Staged Model Versioned projects used by software with many users – Some users receive new versions as soon as they become available, – Others choose to retain their older versions. – Older versions no longer evolve (still serviced for some time) – It would be very complicated and wasteful to evolve several versions in parallel © 2012 Václav Rajlich Software Engineering: The Current Practice 14  Example - Mozilla Firefox Releases 2.0 3.0 3.5 version # Date x 2.0.0.12/ 2/7/2008 x 3.0b3/ 2/13/2008 x 3.0b4/ 3/11/2008 x 2.0.0.13/ 3/25/2008 The versions released in 2008 – 2009 x x 3.0b5/ 2.0.0.14/ 4/9/2008 4/15/2008 x 3.0rc1/ 5/15/2008 x 3.0rc2/ 6/4/2008 x 3.0rc3/ 6/11/2008 x 3.0/ 6/19/2008 Versions 2.0 and 3.0 x 2.0.0.15/ 6/23/2008 x 2.0.0.16/ 7/11/2008 x 3.0.1/ 7/16/2008 x 2.0.0.17/ 9/17/2008 – serviced in parallel till 12/18/2008 x x 3.0.2/ 3.0.3/ 9/22/2008 10/7/2008 x 2.0.0.18/ 11/11/2008 – version 2 moved into in phase-out x x 3.0.4/ 2.0.0.19/ 11/11/2008 12/15/2008 x 3.0.5/ 12/15/2008 x 2.0.0.20/ 12/18/2008 x 3.0.6/ 2/2/2009 x 3.0.7/ 3/3/2009 Version 3.5 introduced on 4/24/2009 x x x 3.0.8/ 3.0.9/ 3.5b4/ 3/27/2009 4/9/2009 4/24/2009 – while version 3.0 still being serviced x x x 3.0.10/ 3.5b99/ 3.0.11/ 4/27/2009 6/7/2009 6/10/2009 x 3.5rc1/ 6/16/2009 x 3.5rc2/ 6/17/2009 x 3.5rc3/ 6/24/2009 x 3.5/ 7/1/2009 x 3.5.1/ 7/17/2009 x 3.0.12/ 7/20/2009 x 3.5.2/ 7/30/2009 x 3.0.13/ 7/31/2009 x 3.5.3/ 8/24/2009 x 3.0.14/ 9/8/2009 x 3.5.4/ 10/19/2009 x 3.0.15/ 10/26/2009 © 2012 Václav Rajlich Software Engineering: The Current Practice 15  V Process Model maintenance requirements functional testing system design system testing unit design unit testing implementation © 2012 Václav Rajlich Software Engineering: The Current Practice 16  Prototyping Model requirements prototype corrected requirements design implementation maintenance © 2012 Václav Rajlich Software Engineering: The Current Practice 17  Spiral Model © 2012 Václav Rajlich Software Engineering: The Current Practice 18  Agile Approach The following are some of the methods to implement agile: 1.XP 2.Kanban 3.Lean 4.Scrum 5.Crystal 6.TDD © 2012 Václav Rajlich Software Engineering: The Current Practice 19