ch02.ppt

CP317 Software Engineering Chapter 2: Stephen R. Schach Software Life cycle Models Life-Cycle Models Life-cycle models presented and compared:  Evolution-tree life-cycle model  Iterative-and-incremental life-cycle model  Code-and-fix life-cycle model  W...

CP317 Software Engineering Chapter 2: Stephen R. Schach Software Life cycle Models Life-Cycle Models Life-cycle models presented and compared:  Evolution-tree life-cycle model  Iterative-and-incremental life-cycle model  Code-and-fix life-cycle model  Waterfall life-cycle model  Rapid prototyping life-cycle model  Open source model  Extreme programming and agile processes  Synchronize-and-stabilize life-cycle model  Spiral life-cycle model 2 2.1 Software Development in Theory Ideally, software is developed as described in Chapter 1  Linear  Starting from scratch 3 Software Development in Practice In the real world, software development is totally different  We make mistakes  The client’s requirements change while the software product is being developed 4 2.2 Ex: Winburg Case Study The mayor of Winburg asks a software company to build a software for the fare machines in the buses of the public transportation system. Passengers drop a dollar bill in the machine. The software uses an image recognition algorithm to check the validity of the bill. Requirements set out by the mayor: 1. The average response time must be less than 1 second 2. The accuracy of the fare machine must be at least 98% 5 2.2 Winburg Case Study Episode 1: The first version is implemented Episode 2: A fault is found  The product is too slow because of an implementation fault  Changes to the implementation are begun Episode 3: The requirements change  A faster algorithm is used Episode 4: A new design is adopted  Development is complete 6 Evolution-Tree Model Winburg Case Study 7 Evolution-Tree Model The explicit order of events is shown At the end of each episode  We have a baseline, a complete set of artifacts (constituent components) Example:  Baseline at the end of Episode 4: Requirements3, Analysis3, Design4, Implementation4 8 2.3 Lessons of Winburg Case Study Changes are always needed  A software product is a model of the real world, which is continually changing  Software professionals are human, and therefore make mistakes 9 Moving Target Problem A change in the requirements while the software product is being developed Any change made to a software product can potentially cause a regression fault  A fault in an apparently unrelated part of the software If there are too many changes  The entire product may have to be redesigned and reimplemented 10 2.5 Iteration and Incrementation Software development process is iterative  Each successive version is intended to be closer to its target than its predecessor Software development process is incremental  In real life, we cannot speak about “the phase”  Instead, the operations of that phase are spread out over the life cycle Browsing courses Room allocation Registering University Registration Exam scheduling System with very broad scope Fee payment 11 Miller’s Law At any one time, we can concentrate on only approximately seven chunks (units of information) To handle larger amounts of information, use stepwise refinement  Concentrate on the most important aspects  Postpone aspects that are currently less critical  Every aspect is eventually handled in order of importance This is an incremental process 12 2.5 Iteration and Incrementation The number of increments will vary—it does not have to be four 13 2.5 Iteration and Incrementation The number of increments will vary—it does not have to be four 14 Classical Phases versus Workflows Sequential phases do not exist in the real world Instead, the five core workflows (activities) are performed over the entire life cycle  Requirements workflow  Analysis workflow  Design workflow  Implementation workflow  Test workflow 15 Workflows However, at most times, one workflow predominates Examples:  At the beginning of the life cycle The requirements workflow predominates  At the end of the life cycle The implementation and test workflows predominate Planning and documentation activities are performed throughout the life cycle 16 Iteration and Incrementation (contd) Iteration is performed during each increment Each iteration involves all five workflows 17 Iteration and Incrementation (contd) Complete diagram 18 2.7 Strengths of Iterative-and-Incremental Model There are multiple opportunities for checking that the software product is correct  Every iteration incorporates the test workflow  Faults can be detected and corrected early The robustness of the architecture can be determined early in the life cycle  Architecture — the various component modules and how they fit together  Robustness — the property of being able to handle extensions and changes without falling apart 19 Strengths of Iterative-and-Incremental Model (contd) We can mitigate (resolve) risks early  Risks are invariably involved in software development and maintenance We have a working version of the software product from the start  The client can experiment with that version and determine changes needed for the next version  Prototype: The first iteration (of the 1st increment) 20 2.9.1 Code-and-Fix Model The product is implemented without requirements, specifications, or design. 21 Code-and-Fix Model (contd) The easiest way to develop software The most expensive way Maintenance is a nightmare! 22 2.9.2 Waterfall Model Characterised by  linear model  feedback loops.  Documentation driven 23 2.9.2 Waterfall Model (contd) Advantages  Documentation driven  No phase is complete until the documentation for that phase has been completed, and the products of that phase have been approved by the software quality assurance (SQA) group.  Maintenance is easier 24 2.9.2 Waterfall Model (contd) Disadvantages  Specification documents are generally long & complex  Not incremental The first time that the client sees a working product is only after the entire product has been coded. Waterfall Model Iterative & Incremental Model 25  2.9.3 Rapid Prototyping Model Rapid prototype is a working model that is functionally equivalent to a subset of the product. The feedback loops are less likely needed. The rapid prototype is typically discarded after lessens learnt. Development Maintenance 26 2.9.4 Open-Source Life-Cycle Model Consists of two informal phases.  An individual builds an initial version and makes it available to public free of charge.  Then users become co-developers and perform corrective/perfective/adaptive maintenance There are generally no specifications or design Visit SourceForge.net and FreshMeat.net for many open-source products 27 Comparison of Life-cycle Models A common feature with code-and-fix, rapid prototyping, and open-source models is that an initial working version is produced.  In the rapid prototyping model, this initial version is discarded, and the target product is then specified and designed before being coded.  In both the code-and-fix and open-source models, the initial version is reworked until it becomes the target product. Code-and-fix model Open-source model Rapid prototyping model 28 Open-Source vs Closed-Source Software Closed-source software  Maintained by employees of the software organization  Users have no access to the source code  Hence, they can only submit failure reports, not fault reports (“fixes”). Open-source software  Maintained by unpaid volunteers who have access to the source code.  Users can submit fixes as well. 29 2.9.5 Extreme Programming and Agile Processes Somewhat controversial new approach; based on iterative-and-incremental model Stories (features client wants)  Estimate the duration and cost of each story  Select stories for the next build  Each build is divided into tasks  Test cases for a task are drawn up first Pair programming Build 1 Build 3 Continuous integration of tasks Browsing courses registerin Room g allocation Exam Fee payment scheduling Build 2 Example: Stories of University Registration System 30 Unusual Features of XP A client representative is always present No specialization Refactoring  no overall design step before the various builds are constructed  the design is developed incrementally, and the code is reorganized 31 Agile Processes A collection of new paradigms characterized by  Less emphasis on analysis and design  Earlier implementation (working software is considered more important than documentation)  Responsiveness to change  Close collaboration with the client XP is one of those new paradigms 32 Evaluating Agile Processes and XP There are some doubts about agile processes in the context of medium- and large-scale software products The key decider: the impact of agile processes on postdelivery maintenance  Refactoring is an essential component of agile processes  Refactoring may increase the cost of postdelivery maintenance, as indicated by preliminary research 33 2.9.6 Synchronize-and-Stabilize Model Microsoft’s life-cycle model Requirements analysis — interview potential customers A list of features of the highest priority is presented to the clients Draw up specifications Divide the project into 3 or 4 builds Each build is carried out by small teams working in parallel 34 Synchronize-and Stabilize Model (contd) At the end of the day — synchronize (test and debug) At the end of the build — stabilize (freeze the build) The repeated synchronization ensures that the components always work together 35 2.9.7 Spiral Model Key points of Spiral model  Risks involved in software development Examples of risks  Personnel may resign before documentation  The manufacture of the hardware goes bankrupt  A competitor may announce a cheaper package  The product components may not fit together when integration is performed.  The delivered product will not satisfy the client’s needs. 36 Spiral Model: Simplified Form Risk analysis at start of each cycle (phase) followed by  Rapid prototype  Models  Proof-of-concept prototype (simulation) If all risks cannot be mitigated, the project is immediately terminated 37 Full Spiral Model 38 Full Spiral Model Radial dimension: cumulative cost to date Angular dimension: progress through the spiral Each cycle of the spiral corresponds to a phase A phase begins by determining  Objectives, alternatives, and constraints  Risk analysis of achieving those objectives Follow each phase by  Evaluation  Planning of the next phase 39 Analysis of the Spiral Model Strengths  It is easy to judge how much to test  No distinction is made between development and maintenance Weaknesses  For large-scale software only  For internal (in-house) software only 40 2.10 Comparison of Life-Cycle Models Different life-cycle models were presented  Each with its own strengths and weaknesses Criteria for deciding on a model include:  The organization  Its management  The skills of the employees  The nature of the product Best suggestion: “Mix-and-match” life-cycle model 41 Comparison of Life-Cycle Models (contd) 42