Development Techniques CSE301 University of Sunderland Harry R. Erwin, PhD

Sources Boehm, 1981, Software Engineering Economics, Prentice- Hall. Stephens and Rosenberg, 2003, Extreme Programming Refactored: The Case Against XP, Apress. Fowler, 2000, Refactoring: Improving the Design of Existing Code, Addison-Wesley. Martin, 2003, Agile Software Development: Principles, Patterns, and Practices, Prentice-Hall. Extensive discussions on comp.object Ebert 2000,

Three Techniques Discussed Here Waterfall (Royce, 1970) Spiral Model (Boehm, 1988) Extreme Programming (XP, Beck, 1996+) XP is an example of an agile method that we will study in detail.

Waterfall Reqs Arch Design Code Intg Accept

Waterfall Elements Feasibility Analysis (not included in estimate) Requirements Definition (20% of costs) Architectural Design (20% of costs) Detailed Design (20% of costs) Code/Unit Test (20% of costs) Integration (20% of costs) Acceptance Test (20% of costs) Operations and Maintenance (100+% of costs) Note these costs sum to more than 100%! Feasibility analysis, requirements definition, and operations and maintenance are usually not included in the quoted cost!

Waterfall Tradeoffs Advantages: –Economical –Fast Disadvantages: –Requirements must be known up front. –No mechanism for risk buy-down. –Cost to repair requirements errors is high, especially missing requirements.

Waterfall Costs Rough Order of Magnitude (ROM)! For life-critical or good quality commercial software: about 320 software lines of code per man-month. For prototype or post-graduate student coding: about 1000 software lines of code per man- month. The ROM estimates are for tested and fully documented code. For better estimates, use Boehm (1981).

Waterfall Variants Incremental Development –Based on Brooks’ build-it-twice approach. “Software should be built in increments of functional capability.” –Has worked on very large programs. Advancemenship Anticipatory documentation Software scaffolding –Reduces overall costs and front-loads the software labor distribution –Often builds software that is never used, though.

Spiral Model

Spiral Model Approach Prior to a final waterfall, risks are explored by incremental changes to a prototype. The stakeholders always have the option of rejecting an increment and redirecting the program. Costs more than Waterfall and takes longer, but has reduced risks.

Extreme Programming (Beck, 1998, in Cunningham’s wiki) Is defined by the following: –Values –Practices –Activities –Roles Intended to flatten the cost of change curve.

XP Values Communication—verbal, with a collocated team. Simplicity—always do the simplest thing that can possibly work. Feedback—continuous from the customer. Courage—willingness to change.

XP Practices Test-driven development User stories The planning game Whole team Short cycles Metaphor Simple design Refactor mercilessly Collective ownership Pair programming Continuous integration Sustainable pace Coding standards Acceptance tests (Emergent design)

XP Activities Coding Testing Listening Designing

XP Roles Programmer Tester Tracker Coach Consultant Big boss

XP Life Cycle Evolutionary development –Coding is continuous –Iterations of 1-3 weeks Design -> Code -> Integrate -> Test –Repeated several times a day Based on ‘stories’

Problems Targeted by XP Lack of communication Requirements volatility Software development that isn’t used. Out of date documentation Obsolescence

Interaction Between Practices XP is believed to work only when all practices are followed. Then the weaknesses of one practice are covered by the strengths of others. For example: –Use of emergent design is well-known to be risky. Constant refactoring protects against that risk. –Constant refactoring is a time sink and a source of bugs—extensive unit testing protects against that. –Reliance on unit tests does not validate the design. Pair programming protects against design errors.

Test-Driven Development ‘The test-driven development is the method of software development where tests specify interfaces of implementation and all code must have passed the tests.’ (Wikipedia)

How Bob Martin Describes It (personal communication) Erwin: TDD as I understand it: 1. Write a test for a bit of functionality. 2. Show that it fails. 3. Write the code to make the test pass. Martin: A good summary, but there's more. 1. We do not write production code until there is a failing test. 2. We write the simplest possible production code to get the test to pass. 3. We do not write more tests when we have a failing test. 4. We do not add to a failing test.

Martin Comments Further If you watched someone doing TDD you would see them oscillating between test code and production code once every minute or so. During each oscillation the programmer would add a few lines to his test code, thus making it fail (or not compile) and then add just a few lines to his production code in order to make the test pass (or compile). Each oscillation is so simple that it's not worth taking. Each oscillation is so simple that the risk of error is close to zero. If you walk into a room of people working this way, and chose anyone at random, a minute ago all his code would have been working.

Pair Programming Pair Programming (ExtremeProgrammingPractice) requires two engineers to participate in one development effort at one workstation. Each member performs the action the other is not currently doing: While one types in unit tests the other thinks about the class that will satisfy the test, for example. Studies have shown that, after training for the "PeopleSkills" involved two programmers are more than twice as productive as one for a given task. (Wikipedia)

The Planning Game Planning is an emotional minefield. Of course Development would like to program faster. Of course the project manager would like to be able to say exactly how fast Development can go. Of course Business would like to be able to say exactly what they want. Of course Business would rather not change its mind. When any of the participants in planning begin acting these wishes (or rather in accordance with the fears that lie behind each wish), then planning doesn't work well. (Wikipedia)

How to Plan Maintain velocity. Merging and splitting stories: User stories should be ‘right-sized’. Prototyping sessions are called ‘spikes’. These allow the team’s velocity to be estimated.

Refactoring Deals with code ‘rot’. Refactoring is a technique to restructure code in a disciplined way. For a long time it was a piece of programmer lore, done with varying degrees of discipline by experienced developers, but not passed on in a coherent way. (Fowler)

Simple Design The simplest design that can meet the current set of user stories. “You aren’t going to need it.” Once and only once—no code duplication.

What do I recommend? If you already know what you need to do, use Waterfall. If you need to control risks and clarify requirements, use Spiral Model. If you don’t know where you’re going (or your customer doesn’t), use XP.

What Practices are Simply Good? These practices should be followed independently of development model: –Test-driven development –Short cycles (early warning) –Metaphor (leadership) –Simple design (KISS) –Refactor mercilessly (isn’t Eclipse wonderful?) –Pair programming* (more productive than alone) –Sustainable pace (ever been ‘fried’?) –Coding standards (for yourself if noone else) *except on homework projects…