Chapter 2: Iterative, Evolutionary, and Agile

1
Chapter 2 Iterative, Evolutionary, and Agile

• 2.1 Introduction
• We decide on a software development process
  before we start a project (or at least, very
  early in a project).
• Iterative because the entire project will be
  composed of min-projects and will iterate the
  same activities again and again (but on different
  part of the project) until completion.
• Evolutionary (or incremental) because the
  software grows by increments (to be opposed to
  the traditional, and somewhat old-fashionned,
  Waterfall model of software development).
• Agile because we will use a light approach to
  software development rather than a very rigid one
  (which may be needed for a safety-critical system
  for example)
• This kind of approach seems better at treating
  software development as a problem solving
  activity also the use of objects makes it
  amenable.

2

• The Unified Process is a relatively popular
  iterative software development process.
• Iterative and evolutionary development involves
  relatively early programming and testing of a
  partial system, in repeated cycles. It typically
  also means that development starts before the
  exact software requirements have been specified
  in detail feedback is used to clarify, correct
  and improve the evolving specification this is
  in complete complete contrast to what we usually
  mean by engineering! (why?, why do you think it
  works better this way for software?)

3

• 2.2 What is the Unified Process and why?
• What
• By the authors of the UML Jacobson, Booch and
  Rumbaugh in 1999
• Not part of the UML !
• Why
• We need a process
• It is popular for OO project
• It is a good middle-of-the-road process
• The UP is very flexible and open and can include
  other practices from other methods such as
  Extreme Programming (X) or Scrum for example.
• E.g. XPs test-driven development, refactoring
  can fit within a UP project So can Scrums daily
  meeting.
• Being pragmatic in adapting a particular process
  to your needs is an important skill all
  projects are different.

4

• The OO skills and techniques that we will see are
  not specific to the UP
• They can be applied within any software
  development process
• The UP is just a framework for a project, it
  brings some structure to what we do.

5

• 2.3 What is Iterative and Evolutionary
  Development?
• An iteration is a time-boxed (say 3 weeks)
  mini-project during which an increment of the
  software is developed. The increment is
  integrated into the current project.
• Each iteration therefore is made up of the
  following sequential activities requirements
  analysis, design, implementation and testing.
• The software is enlarged by increments. It is
  also refined (and thus is evolves) as we go along
  via feedbacks Iterative and Evolutionary
  Development.
• Be careful! an increment is not a prototype
  that sometimes work and sometimes doesnt it
  should represent a properly analysed, designed,
  coded and tested chunk of the future software
  (otherwise?)
• See Fig 2.1 for better explainations

6
Fig 2.1 Iterative and Evolutionary Development
7

• Example of three-week agile iteration (may not
  always be suitable)
• The last iteration is debriefed and suggestion
  for process improvement are noted
• Feedback from previous demonstrations and
  subsequent requests for change are integrated in
  this iteration
• All the artefacts (use cases, UML diagrams, code
  ) from the previous iteration are updated and
  syncronised with each other
• Meeting clarifying the goals of the next
  iteration
• Use cases may need to be refined
• OOA is performed by the team working by pairs via
  the UML using whiteboard and capturing outcomes
  using a digital camera
• OOD is performed by the team again probably by
  pairs of staff members. Previous UML artefacts
  are updated
• Most of the remaining days are spent on
  implementation and testing (with may be re-design
  if necessary)
• The last day should be spent tidying up and
  documenting
• (Other project management activities such as
  demonstration, quality evaluation, personal
  issues etc. have not been detailed here)

8

• There should be no rush to code nor long
  drawn-out all-detailed design phase it is a
  project and team-dependent compromise.
• The result of each iteration is an executable
  (why is this important?) but incomplete system
• It should not be a hack nor a prototype
• For this approach to work we must not have to go
  back and change previous design decisions or code
  thats a hack
• Whatever we do within an increment must be
  thought as part of the final system it should
  be of high quality, suitable for release,
  production-grade code and documentation
• Of course the above remarks are very important
  but
• You will not always get it right changing a
  previous iterations code or design is inevitable
  and will happen all the time (the nature of the
  changes are imporatnt are you re-designing all
  the time or just tinckering the code?) it is
  unrealistic to believe that the code of an
  iteration will never change during an entire
  project
• Thats about handleing change during development

9

• Change will be needed during a project because
• What was done previously is not perfect (this is
  very common)
• The requirements were misunderstood (this is very
  common)
• The requirements change (this is very common)
• So change is common. The waterfall-way of dealing
  with this problem is to spend enough time during
  analysis to ensure that the requirements are
  prefect this is genrally impossible.
• The UP and all other iterative approaches (Agile
  or not) on the other hand try to embrace change
• As each iteration looks at only one aspect of the
  project but does so quickly and generates an
  executable at the end early feedback can be
  provided
• Also the entire detailed requirements do not need
  to be frozen each iteration and subsequent
  evaluation-feedback clarifies the requirements
  that were looked at in previous iterations and
  also sheds light on the requirements of the
  future iterations.
• The requirements are clarified as we go along a
  problem solving process.

10

• Hence Iterative, Evolutionary and Agile process
• Of course, for this to work the resulting changes
  must not be major all the time
• We mustnt make major blunders in our design
• Or completely misunderstand a requirement
• Or accept requirement changes (new feature
  please!) from external sources (client, marketing
  department etc.) that require a re-design.
• In general, changes get harder to accommodate as
  the project progresses.
• We must not fall into a chaotic process but
  properly managed iterations during which
  release-grade artefacts are produced can
  successfully accommodate change. Up to a point
• Fig 2.2 tries to illustrate the evolutionary
  nature of an iterative process.

11
Fig 2.2 Iterative feedback leads to an
evolutionary system closer to the real
requirements
12

• Benefits of iterative development
• Early progress that can be evaluated
• Early feedback, user engagement early
  clarifications of requirements that will bering
  us closer to the real requirements
• Complexity containment we proceed by chuck
• Early tackling of risks (technical, requirements,
  objectives, usability etc.)
• Late total project failure less likely
• Better productivity (especially when agile)
• Less defects
• Possible process improvement within a single
  project
• Potential problems of iterative development
• Going into a prototyping-hacking mode
• Poor documentation
• Bad overall architectural design
• Unsuitable for some software safety-critical
  (because safety properties must be proven true on
  the initial requirements)
• Must strive for good style all the time

13

• Each iteration should be time-boxed between 2 to
  6 weeks
• Longer rapid feedback and adaptation is lost,
  complexity of task is probably too great, falls
  into waterfall
• Shorter quality and documentation will suffer
• If the manager feels that a deadline will not be
  met a recommended response is to de-scope
  remove tasks or requirements from the iteration
  and schedule them to a future iteration, rather
  than slip the completion date (what do you
  think?)
• The need for feedback and adaptation
• Feedback from the early demonstrations as client
  and developers try to understand each other to
  define and clarify the requirements as a team
• Feedback from testing implies that previous code
  needs to change
• Feedback from previous iterations to refine
  schedule and all other estimates (such as?)
• Feedback from client and marketplace to change
  software emphasis (the marketplace does not stay
  still during software development )

14

• 2.4 How to do Iterative and Evolutionary Analysis
  and Design?
• Overview of a simple example on 20 iterations
  (over a year) project
• Before the first iteration, hold an initial
  requirements workshop with client and senior
  developers. In the UP this is the Inception Phase
  
• Define the objectives of the project
• Do high-level requirements analysis by
  identifying use cases (say 30 are found) and
  features
• Identify non-functional requirements (look and
  feel, efficiency etc.)
• Pick the 10 of the use cases that a blending of
• Architecturally Significant
• High marketing value
• High risk
• this leads to say 3 use cases UC2, UC11 and
  UC14
• Do a detailed analysis of the functional and
  non-functional requirements for these three use
  cases
• Review everything with everybody

15

• Then the developers alone hold an iteration
  planning meeting to define a subset of UC2, UC11
  and UC14 for the first iteration to fit within a,
  say, 4 weeks timebox (do not be too greedy!).
  Document the subset. Maybe tentatively schedule
  2nd and 3rd iterations
• Iteration 1 (in UP terms this is the start of the
  Elaboration Phase)
• Perform OOA documenting the Domain Model using
  UML review by all developers (eg 3 days)
• Perform OOD documention the Design Model using
  UML in pairs, review by all (eg. 2 days)
• Start programming, integrating and testing using
  previous UML models as starting points Try to
  update models hold daily stand-up meetings (eg.
  2 weeks)
• One week before the end review and de-scope if
  necessary
• On Tuesday of the last week code freeze to
  provide increment
• On Wednesday demo partial system to external
  stakeholders get and document feedback
• 2nd requirements workshop refine previous
  workshop document and detail another important
  10-15 of the use cases

16

• Iteration 2 similar steps
• Repeat for four iterations and five requirements
  workshops so tha tat the end of iteration 4,
  perhaps 80 or 90 of the requirements have been
  written in details but only 10 of the system has
  been implemented
• The end of the Elaboration Phase when most of the
  requirements have been detailed by iterations and
  some the system is available. All estimates
  should be reviewed
• The UP Construction Phase can start many more
  iterations, major requirements change is less
  likely during this period. Can be more ambitious
  on the amount of work to be performed. Keep
  learning and getting feeback
• In the UP the last phase is the Transition Phase
  beta tests and deployment
• See Fig 2.4 for an illustration of this iterative
  process.

17
Fig 2.4
18

• 2.5 What is Risk-Driven and Client-Driven
  Iterative Planning?
• Can you guess? It is about which use cases to
  schedule in the elaboration phase, at the
  beginning of a project. We should select use
  cases according to
• Risks to drive down the highest risks early on
• Client needs to build visible features that the
  client cares most about
• How does this applies to games development?
• Risk-driven iterative development includes the
  practice of architecture-centric iterative
  development early iterations focus on building,
  testing and stabilising the core architecture
  why?

19

• 2.6 What are Agile Methods?
• Agile development usually apply time-boxed
  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).
• Examples of practices include
• Common project workroom (from Scrum)
• Self-organising teams (from Scrum)
• Programming in pairs (from XP)
• Test driven development (from XP)
• while we will not have the time to review every
  techniques we will keep an agile point-of-view
  in our process.
• The Agile Alliance has issued a manifesto and a
  set of principles

20

• The Agile Manifesto
• We are uncovering better ways of developing
  software by doing it and helping others do it.
  Through this work we have come to value
• Individuals and interactions over processes and
  tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• That is, while there is value in the items on the
  right, we value the items on the left more.
• The Agile Principles
• Our highest priority is to satisfy the customer
  through early and continuous delivery of valuable
  software.
• Welcome changing requirements, even late in
  development. Agile processes harness change for
  the customer's competitive advantage.
• Deliver working software frequently, from a
  couple of weeks to a couple of months, with a
  preference to the shorter timescale.

21

• Business people and developers must work together
  daily throughout the project.
• Build projects around motivated individuals. Give
  them the environment and support they need, and
  trust them to get the job done.
• The most efficient and effective method of
  conveying information to and within a development
  team is face-to-face conversation.
• Working software is the primary measure of
  progress.
• Agile processes promote sustainable development.
• The sponsors, developers, and users should be
  able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and
  good design enhances agility.
• Simplicity-the art of maximizing the amount of
  work not done-is essential.
• The best architectures, requirements, and designs
  emerge from self-organizing teams.
• At regular intervals, the team reflects on how to
  become more effective, then tunes and adjusts its
  behavior accordingly.

22

• 2.7 What is Agile Modelling?
• The purpose of modeling is primarily to
  understand, not to document.
• The waterfall-way calls for very detailed OO
  design documents that are handed to a programmer
• But modeling is still necessary
• The models (UML diagrams) created are also very
  good communication tools (face to face
  preferably)
• Dont model everything simple issues can be left
  at programming-time
• Use the simplest tools as possible prefer
  sketching UML diagrams on whiteboards and capture
  the result with a digital camera UML case tools
  can be used later to tidy things up if necessary
• Do not model alone, or at least review by all
• Create models in parallel (e.g. interaction
  diagrams and class diagrams)
• All models are likely to be inaccurate in some
  respect
• Best if whoever models is also responsible for
  coding

23
Fig 2.5 Group-developed UML Sequence Diagram
Sketch
24

• 2.8 What is an Agile UP?
• The UP can be used in an Agile context
• Stick to the spirit of an iterative and
  evolutionary approach
• Continously enagge users for evaluation, feedback
  and requirements
• Continuously verify quality test early, often
  and realistically
• Practice change request management and
  configuration management

25

• 2.9 What are the UP Phases?
• 4 major phases
• Inception approximate vision, business case,
  scope, vague estimates
• Elaboration refined vision, use cases,
  iterative development of the core architecture,
  resolution of high risks, identification of most
  requirements and scope, more realistic estimates
• Construction iterative implementation of the
  remaining lower risks aspects
• Transition beta tests, deployment
• This is not waterfall.
• See Fig 2.6 for an UP overview.

26

Fig 2.6 UP phases overview
27

• 2.10 What are the UP Disciplines?
• The UP describes a set of on-going activities
  such as requirements analysis, design, testing
  etc.
• These are spread over all phases (and
  iterations)
• The relative effort across these disciples
  changes over time e.g. early iterations tend to
  focus on requirements analysis rather than
  testing
• See Fig 2.7 UP disciplines overview
• We can take a closer look at the likely change
  over-time of the emphasis of the disciplines per
  iterations see Fig 2.8.

28
Fig 2.7 UP Disciplines Overview
29
Fig 2.8 Phases and Disciplines

• To try to clarify things, have a look at Fig 2.8a

30
Fig 2.8a Agile UP Schedule Overview
31

• 2.11 Adapting the UP
• Apart form the fundamental principles (such as
  iterative and evolutionary, risk and
  client-driven development, realistic continuous
  verification of quality), the UP is very
  flexible.
• We can write-up a Development Case document
  during inception to detail the choices of
  practices and artifacts that will be adopted for
  a project.

32

• 2.12 You Know you did not Understand Iterative
  Development When
• You try to define all the requirements details
  before you start (or the entire detailed design
• You spend weeks doing UML modeling before
  programming
• You think that inception requirements analysis,
  elaboration design and construction coding
• Your iterations are months long rather than
  weeks
• Your plans are fussy, overly detailed, document
  led and rigorously enforced
• People work in isolation, handing one document
  after another to the next person (e.g.
  requirements specification from analyst to a
  designer, design document to programmer, code to
  tester)

33

• 2.13 Conclusion
• We will apply the UP, an iterative and
  evolutionary process, within an agile context.
• Resources
• www.agilealliance.com (the Agile Alliance)
• www.agilemodeling.com (Scott Ambler)
• Craig Larman Agile Iterative Development A
  Managers Guide, Addison Wesley, 2004

• Questions Please