Software Engineering CHAPTER 2 SOFTWARE LIFE CYCLE MODELS

Software Engineering CHAPTER 2 SOFTWARE LIFE CYCLE MODELS by Farhad Mavaddat CS 430 Notes Modified from the notes of Jerry Breecher of Clark University & Stephen R. Schach, Vanderbilt University Chapter 2 A

Overview = = = = = Software development in theory Winburg mini case study Lessons of the Winburg mini case study Teal tractors mini case study Iteration and incrementation Winburg mini case study revisited Risks and other aspects of iteration and incrementation Managing iteration and incrementation Other life-cycle models Comparison of life-cycle models Chapter 2 A

2. 1 Software Development in Theory = Ideally, software is developed as described in Chapter 1 4 4 4 Linear Starting from scratch Called the Linear Model Requirements Analysis Design Implementation Chapter 2 A Figure 2. 1

Winburg Case Study – The Real World Is Different = Episode 1: The first version is implemented = Episode 2: A fault is found 4 The product is too slow because of an implementation fault 4 Changes to the implementation are begun = Episode 3: The requirements change 4 A faster algorithm is used = Episode 4: A new design is adopted 4 Development is complete = Epilogue: A few years later, these problems recur Chapter 2 A

Evolution-Tree Model = Winburg Mini Case Study Development Maintenance Requirements Analysis Design Implementation Chapter 2 A Figure 2. 2

Waterfall Model = The linear life cycle model with feedback loops 4 The waterfall model cannot show the order of events Requirements Analysis Design Implementation Development Maintenance Chapter 2 A Figure 2. 3

2. 4 Teal Tractors Mini Case Study = While the Teal Tractors software product is being constructed, the requirements change = The company is expanding into Canada = Changes needed include: 4 Additional sales regions must be added 4 The product must be able to handle Canadian taxes and other business aspects that are handled differently 4 Third, the product must be extended to handle two different currencies, USD and CAD These changes may be 4 Great for the company; but 4 Disastrous for the software product A change in the requirements while the software product is being developed = = Chapter 2 A

Moving Target Problem (contd) = Even if the reasons for the change are good, the software product can be adversely impacted 4 Dependencies will be induced = Any change made to a software product can potentially cause a regression fault 4 A fault in an apparently unrelated part of the software = If there are too many changes 4 The entire product may have to be redesigned and re-implemented = Change is inevitable 4 Growing companies are always going to change 4 If the individual calling for changes has sufficient clout, nothing can be done about it = Chapter 2 A There is no solution to the moving target problem

2. 5 Iteration and Incrementation = In real life, we cannot speak about “the analysis phase” 4 Instead, the operations of the analysis phase are spread out over the life cycle = The basic software development process is iterative 4 Each successive version is intended to be closer to its target than its predecessor Chapter 2 A

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 4 Concentrate on the aspects that are currently the most important 4 Postpone aspects that are currently less critical 4 Every aspect is eventually handled, but in order of current importance = This is an incremental process Chapter 2 A

2. 5 Iteration and Incrementation Work Quantity In Each Increment A Increment B Increment C Increment D Requirements Workflow High Medium Low None Analysis Workflow Medium High Low Design Workflow Low High Low Implementatio n Workflow Low Medium High Low Test Workflow Low Medium High = Iteration and incrementation are used in conjunction with one another 4 There is no single “requirements phase” or “design phase” 4 Instead, there are multiple instances of each phase Chapter 2 A

Iteration and Incrementation (contd) = = Iteration and incrementation are used in conjunction with one another 4 There is no single “requirements phase” or “design phase” 4 Instead, there are multiple instances of each phase The number of increments will vary—it does not have to be four Development Maintenance Requirements Analysis Design Implementation Chapter 2 A

Workflows = All five core workflows are performed over the entire life cycle = However, at most times one workflow predominates = Examples: 4 At the beginning of the life cycle n The requirements workflow predominates 4 At the end of the life cycle n The implementation and test workflows predominate = Planning and documentation activities are performed throughout the life cycle Chapter 2 A

2. 8 Managing Iteration and Incrementation = The iterative-and-incremental life-cycle model is as regimented as the waterfall model … = … because the iterative-and-incremental life-cycle model is the waterfall model, applied successively = Each increment is a waterfall mini project Chapter 2 A

2. 9 Other Life-Cycle Models = The following life-cycle models are presented and compared: 4 Code-and-fix life-cycle model 4 Waterfall life-cycle model 4 Rapid prototyping life-cycle model 4 Extreme programming and agile processes 4 Synchronize-and-stabilize life-cycle model 4 Spiral life-cycle model Chapter 2 A

2. 9. 1 Code-and-Fix Model = = No design No specifications 4 Maintenance nightmare = = = The easiest way to develop software The most expensive way Typically used by a start-up. Implement the 1 st Version Modify until client is satisfied Postdelivery Maintenance Development Maintenance Figure 2. 7 Chapter 2 A

2. 9. 2 Waterfall Model = Characterized by 4 Feedback loops 4 Documentation-driven = Advantages 4 Documentation 4 Maintenance is easier = Disadvantages 4 Specification document n Joe and Jane Johnson n Mark Marberry Chapter 2 A Figure 2. 8

2. 9. 3 Rapid Prototyping Model = Linear model = “Rapid” Chapter 2 A Figure 2. 9

2. 9. 4 Extreme Programming and Agile Processes = = Somewhat controversial new approach Stories (features client wants) 4 Estimate duration and cost of each story 4 Select stories for next build 4 Each build is divided into tasks 4 Test cases for a task are drawn up first Pair programming Continuous integration of tasks Unusual Features of XP = = = The computers are put in the center of a large room lined with cubicles A client representative is always present Software professionals cannot work overtime for 2 successive weeks No specialization Refactoring (design modification) Chapter 2 A

Agile Processes = A collection of new paradigms characterized by 4 Less emphasis on analysis and design 4 Earlier implementation (working software is considered more important than documentation) 4 Responsiveness to change 4 Close collaboration with the client = XP has had some successes with small-scale software development 4 However, medium- and large-scale software development is very different Chapter 2 A

Evaluating Agile Processes and XP (contd) = The key decider: the impact of agile processes on post-delivery maintenance 4 Refactoring is an essential component of agile processes 4 Refactoring continues during maintenance 4 Will refactoring increase the cost of post-delivery maintenance, as indicated by preliminary research? = Agile processes are good when requirements are vague or changing = It is too soon to evaluate agile processes 4 There are not enough data yet = Even if agile processes prove to be disappointing 4 Some features (such as pair programming) may be adopted as mainstream software engineering practices Chapter 2 A

2. 10 Comparison of Life-Cycle Models = Different life-cycle models have been presented 4 Each with its own strengths and weaknesses = Criteria for deciding on a model include: 4 The organization 4 Its management 4 The skills of the employees 4 The nature of the product = Best suggestion 4“Mix-and-match” life-cycle model Chapter 2 A

Comparison of Models (According to Schach) Life-Cycle Model Strengths Weaknesses Evolution tree model Closely models real-world software production. Equivalent to the iterative and increment model. Iterative and incremental model Closely models real-world software production. Underlies the unified process. Code and fix model Fine for short programs that require no maintenance. Unsatisfactory for nontrivial programs. Waterfall model Disciplined approach – document driven. Product may not meet client’s needs. Rapid Prototyping model Ensures delivered product meets the client’s need. Not yet proven beyond all doubt. Extreme programming model Works well when the requirements are vague. Appears to work on only small scale projects. Chapter 2 A