Iterative Development

1
Iterative Development

• Week 4 Lecture

2
Agenda

• Iterative and evolutionary development
• Agile Methods Modeling
• Unified Process
• Extreme programming

3
The problem of requirements

• Requirements always change
• Requirements are incomplete
• Requirements are usually wrong
• Requirements ( and users) are misleading
• Requirements do not tell the whole story
• Requirements change because
• The users view of their needs changes after
  discussion with developer
• The developers view of the users problem domain
  changes as they get more familiar with the
  software they are developing
• The environment in which the software is being
  developed changes

4
Iterative and Evolutionary Development

• Iterative development
• Development is organized into a series of short,
  fixed-length mini-projects called iterations.
• The outcome of each is a tested, integrated, and
  executable partial system.
• Known as iterative and incremental development

5
Iterative and evolutionary development
6
Handle change on iterative project
7
How long should an iteration be?

• Most iterative methods recommend an iteration
  length between two and six weeks.
• Iteration are timeboxed, or fixed in length
• Date slippage is illegal
• If it seems difficult to meet the deadline, the
  recommended response is to de-scope remove
  tasks or requirements from the iteration, and
  include them in a future iteration

8
The oldest waterfall lifecycle

• Attempt to define all or most of the requirements
  before programming. To create a thorough design
  before programming
• Strongly associated with high rates of failure,
  lower productivity, and higher defect rates.
• 45 of the features in waterfall requirements are
  never used, early waterfall schedules and
  estimates vary up to 400 from the final actuals.

9
Mini workshop

• Which one of the following is true iterative
  development
• Ive done five iterations on requirement
  collection and the client finally satisfied and
  signed off the requirement document.
• We take iterative method to achieve good database
  design. After the first interview with the
  client, we make an initial design of the database
  and brought this to the client. We got valuable
  feedback from them and made according changes, we
  repeat this process for four times and now have
  our final version of the database design
• This iterations code is very buggy, well clean
  it up at the end

10
How to do iterative and evolutionary analysis and
design
11
Agile Methods and attitudes

• Agile development methods usually apply timeboxed
  iterative and evolutionary development, employ
  adaptive planning, promote incremental delivery
  and include other values and practices that
  encourage agility rapid, and flexible response
  to change.
• Example
• Programming in pairs
• Extreme programming
• test-driven development

12
Agile Modeling

• Adopting an agile method does not mean avoiding
  any modeling
• The purpose of modeling and models is primarily
  to support understanding and communication, not
  documentation
• Dont model or apply the UML to all or most of
  the software design
• Use the simplest tool possible

13
Agile modeling (cont)

• Dont model alone
• Create models in parallel
• Use good enough simple notation while sketching
  with a pen on white board
• Know that all models will be inaccurate
• Developers themselves should do the OO design
  modeling, for themselves, not to create diagrams
  that are given to other programmers to implement.

14
What is Unified Process

• A software development process describes an
  approach to building, deploying, and possibly
  maintaining software
• A popular iterative software development process
• Is flexible and open, can be applied in a
  lightweight and agile approach

15
What are UP Phases

• Inception Approximate vision, business case,
  scope, vague estimates
• Elaboration refined vision, iterative
  implementation of the core architecture,
  resolution of high risks, identification of most
  requirements and scope, more realistic estimates
• Construction iterative implementation of the
  remaining lower risk and easier elements, and
  preparation for deployment
• Transition beta tests, deployment

16
UP phases (cont)
17
UP Disciplines

• The UP describes work activities, within
  disciplines a set of activities ( and related
  artifact in one subject area )
• Artifact general term for any work product

18
UP Disciplines (cont)
19
UP Disciplines Vs. Phases
20
What is an agile UP

• Prefer a small set of UP activities and
  artifacts. All UP artifacts are optional
• Requirements and designs are not completed before
  implementation
• Agile modeling practices
• No detailed plan for the entire project
• Phase Plan high-level plan
• Iteration Plan only plans with greater detail
  one iteration in advance.

21
Understanding Requirements

• Capabilities and conditions to which the system
  and project must conform Jacobson et al., 1999
• Challenges find, communicate, record, manage
  the requirements
• Requirements always change, so effective
  management is critical

22
Evolutionary vs. Waterfall requirements

• UP embraces change in requirements as a
  fundamental driver on projects
• Start production-quality programming and testing
  long before most of the requirements have been
  analyzed or specified.

23
Factors that Challenge Projects
37 of the factorsrelated to problemswith
requirements!
24
The FURPS Model

• Functional features, capabilities, security
• Usability human factors, help, documentation
• Reliability failure frequency, recoverability
• Performance response times, throughput,
  accuracy, availability, resource utilization
• Supportability adaptability, maintainability,
  internationalization, configurability

25
The FURPS Model

• Implementation resource limitations,
  languages/tools, hardware
• Interface with legacy systems
• Operations sysop management
• Packaging delivery, installation
• Legal licensing, etc.

• Use FURPS as a global checklist when
  identifyingrequirements for a system you are
  designing

26
Other Terminology

• Quality Attributes, or -ilities
• Usability, reliability, supportability,
  performance (non-functional)
• Functional vs. Non-Functional
• Behavioral features vs. everything else
• The quality attributes have a strong influence on
  the architecture of a system

27
Requirements Samples

• Excerpt from functional requirements of SatWatch

28
Requirement Samples

• Quality requirements for SatWatch
• Any user who knows how to read a digital watch
  and understands international time zone
  abbreviations should be able to use SatWatch
  without the user manual. Usability requirement
• As the SatWatch has no buttons, no software
  faults requiring the resetting of the watch
  should occur. Reliability requirement
• SatWatch should display the correct time zone
  within 5 minutes of the end of a GPS blackout
  period. Performance requirement
• Constraints for SatWatch ( in FURPS model)
• All related software associated with SatWatch,
  including the onboard software, will be written
  using Java, to comply with current company policy
  Implementation requirement
• SatWatch complies with the physical, electrical
  and software interface defined by WebifyWatch API
  2.0 Interface requirement

29
Document Requirements

• Primarily, in the use case model
• functional requirements
• Also, Supplementary Specifications
• other requirements
• Glossary noteworthy terms
• Vision high-level requirements
• Business Rules Requirements or policies that
  transcend one software project many
  applications in the same domain may need to
  conform to them

30
Extreme Programming

• Extreme Programming (or XP) is a set of values,
  principles and practices for rapidly developing
  high-quality software that provides the highest
  value for the customer in the fastest way
  possible
• Core is 12 XPXtudes

31
XP Xtudes Planning Practices

• PlannnigGame
• Business and development cooperate to produce
  maximum business value as rapidly as possible
• Business write User Story
• Developers estimate efforts
• Business and Developers make commitment
• WholeTeam (used to be OnsiteCustomer)
• OnsiteCustomer JustaProgrammer QualityControl
  CustomerTeam WholeTeam
• Put as many of them in one room as possible
• SystemMetaphor
• Choose a system metaphor to keep the team on the
  same page by naming classes and methods
  consistently.

32
XP Xtudes -- Programming Practices

• PairProgramming
• TestDrivenDevelopment
• SimpleDesign
• DesignImprovement (used to call
  RefactorMercilessly)
• ContinuousIntegration
• SmallRelease
• CollectiveCodeOwnership
• CodingStandard
• SustainablePace (was FortyHourWeek)

33
Pair Programming

• Two Programmers sit at one workstation
• They take turns driving
• Pairs are short lived
• Pairing transmits knowledge to the team
• Pairing train newbies

34
Pairing keeps the pace

• When programming alone, you sometimes find
  yourself working at super speed.
• After awhile, you lose focus and drift away in
  the afterglow.
• Your partner keeps both from happening.

35
XP Xtudes -- Programming Practices

• PairProgramming
• TestDrivenDevelopment
• SimpleDesign
• DesignImprovement (used to call
  RefactorMercilessly)
• ContinuousIntegration
• SmallRelease
• CollectiveCodeOwnership
• CodingStandard
• SustainablePace (was FortyHourWeek)

36
TestDrivenDevelopment

• Before programmers add a feature, they write a
  test for it. When the suite runs, the job is done
• In Tiny (5 min) cycles
• Write a test case.
• Write the code that passes it.
• Repeat until program does what you want.

37
Test First Example
Test Code import junit.framework. public class
TestAutoMileageLog extends TestCase public
TestAutoMileageLog(String name)
super(name) public void
testCreateFuelingStationVisit()
FuelingStationVisit v new FuelingStationVisit()

Production Code public class FuelingStationVisit

38
This may seem useless.

• But it shows you that the test framework is
  functioning properly.
• It also gives you working base to continue from.
• We move, in tiny steps, from working base, to
  working base.

39
Test First Example
public void testCreateFuelingStationVisit()
Date date new Date() double fuel 2.0
// 2 liters. double cost 1.872 // Price
1.39 per liter int mileage 1000 //
odometer reading. double delta 0.0001
//fp tolerance FuelingStationVisit v
new FuelingStationVisit( date, fuel,
cost, mileage) assertEquals(date,
v.getDate()) assertEquals(1.872,
v.getCost(), delta) assertEquals(2,
v.getFuel(), delta) assertEquals(1000,
v.getMileage()) assertEquals(1.87,
v.getPrice(), delta)
40
Test First Example
public class FuelingStationVisit public
FuelingStationVisit(Date date, double fuel,
double cost, int
mileage) itsDate date itsFuel
fuel itsCost cost itsMileage
mileage public Date getDate() return
itsDate public double getFuel() return
itsFuel public double getCost() return
itsCost public double getPrice() return
itsCost/itsFuel public int getMileage()
return itsMileage
41
Test First Example
Green Bar
42
XUNIT

• Lightweight Unit Testing Framework
• www.junit.org
• Junit
• Cppunit
• Pyunit
• Etc.

43
XP Xtudes -- Programming Practices

• PairProgramming
• TestDrivenDevelopment
• SimpleDesign
• DesignImprovement (used to call
  RefactorMercilessly)
• ContinuousIntegration
• SmallRelease
• CollectiveCodeOwnership
• CodingStandard
• SustainablePace (was FortyHourWeek)

44
Simple Design DesignImprovement

• Always use the simplest possible design that gets
  the job done.
• Keep improving design
• After getting something to work we refactor.
• Tiny (5 min) improvements
• Followed by running all the tests.
• Build and test time must be very very fast.
• We cannot check in our code until
• All tests are green.
• All duplication has been removed
• The code is as expressive as we can make it.
• The code is as simple as we can make it.

45
XP Xtudes -- Programming Practices

• PairProgramming
• TestDrivenDevelopment
• SimpleDesign
• DesignImprovement (used to call
  RefactorMercilessly)
• ContinuousIntegration
• SmallRelease
• CollectiveCodeOwnership
• CodingStandard
• SustainablePace (was FortyHourWeek)

46
ContinuousIntegration SmallRelease

• Daily builds are not enough.
• Build, end to end, at every check in.
• Check in frequently.
• Put resources on speeding build time.
• Put resources on speeding test time.
• Small Release
• Start with the smallest useful feature set.
  Release early and often, adding a few features
  each time.

47
XP Xtudes -- Programming Practices

• PairProgramming
• TestDrivenDevelopment
• DesignImprovement (used to call
  RefactorMercilessly)
• ContinuousIntegration
• SimpleDesign
• SmallRelease
• CollectiveCodeOwnership
• CodingStandard
• SustainablePace (was FortyHourWeek)

48
CollectiveCodeOwnership

• Anyone can improve any part of the code at any
  time.
• No one acts as the gatekeeper for any part of the
  code.
• This includes schemas
• And libraries
• And everything else thats different

49
XP Xtudes -- Programming Practices

• PairProgramming
• TestDrivenDevelopment
• DesignImprovement (used to call
  RefactorMercilessly)
• ContinuousIntegration
• SimpleDesign
• SmallRelease
• CollectiveCodeOwnership
• CodingStandard
• SustainablePace (was FortyHourWeek)

50
Coding Standard

• A group of conventions that everyone agrees to.
• Emerges over time.
• Continuously evolves.
• The team rules.

51
XP Xtudes -- Programming Practices

• PairProgramming
• TestDrivenDevelopment
• DesignImprovement (used to call
  RefactorMercilessly)
• ContinuousIntegration
• SimpleDesign
• SmallRelease
• CollectiveCodeOwnership
• CodingStandard
• SustainablePace (was FortyHourWeek)

52
SustainablePace (was FortyHourWeek)

• Programmer welfare
• Programmers go home on time.
• One sure thing that will kill any project is the
  belief that you must give yourself utterly to it
• You cant do your best when you are tired.
• When you dont do your best, you make messes.
• Messes slow everyone down
• So you must be rested
• Occasionally, you may work one week of moderate
  overtime.

53
The worth of your development project

• What is the most important thing you delivered to
  your client?
• Prototype? Design? Analysis? Idea? Documents?
• How you client may use your deliverable?
• You are a temporary group
• Not able to provide long-term services
• Consider Maintainability and Reusability of your
  code

54
Where to go for more info

• XP FAQ (http//www.jera.com/techinfo/xpfaq.html)
• XP Wiki entries (http//c2.com/cgi/wiki?ExtremePro
  gramming)