development techniques l.
Skip this Video
Loading SlideShow in 5 Seconds..
Development Techniques PowerPoint Presentation
Download Presentation
Development Techniques

Loading in 2 Seconds...

play fullscreen
1 / 28

Development Techniques - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Development Techniques' - Rita

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
development techniques

Development Techniques


University of Sunderland

Harry R. Erwin, PhD

  • 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
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 elements
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
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, especiallymissing requirements.
waterfall costs
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
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 approach
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
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
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


Simple design

Refactor mercilessly

Collective ownership

Pair programming

Continuous integration

Sustainable pace

Coding standards

Acceptance tests

(Emergent design)

XP Practices
xp activities
XP Activities
  • Coding
  • Testing
  • Listening
  • Designing
xp roles
XP Roles
  • Programmer
  • Tester
  • Tracker
  • Coach
  • Consultant
  • Big boss
xp life cycle
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
Problems Targeted by XP
  • Lack of communication
  • Requirements volatility
  • Software development that isn’t used.
  • Out of date documentation
  • Obsolescence
interaction between practices
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
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
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
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
  • 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
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
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.
  • 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
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
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
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…