Chapter 08: Iteration 1 Basics

1
Chapter 08 Iteration 1 - Basics

• 8.1 Introduction
• We review here the requirements for first
  iteration of our case studies.
• They are a subset of the requirements as
  described by the use cases, the vision, and the
  supplementary specification
• Subsequent iterations will grow these until a
  full system is implemented
• The current requirements are not complete, they
  will evolve and benefit from feedback
• 8.2 Planning the Iterations
• After the initial inception phase, the most
  important software requirements have been
  identified, some of which have been detailed.
• Other requirements remain to be discovered
• Most will need further analysis

2

• However after the inception phase we must have a
  basic, documented, set of requirements
• These need to be scheduled over the next few
  development cycles (the elaboration phase)
• Only the first few cycles need to be scheduled at
  this stage (a very detailed schedule is not
  feasible at this point in time due to the
  fuzziness of the remaining requirements)
• An iteration must be time-boxed, say between 2
  weeks and 8 weeks (why?)
• To decide which requirements should be tackled
  early in the project we can use the following
  criteria
• Risk includes both technical complexity and
  other factors, such as uncertainty of effort or
  usability.
• Coverage implies that all major parts of the
  system are at least touched on in early
  iterations, perhaps a "wide and shallow"
  implementation across many components.
• Criticality refers to functions the client
  considers of high business value.

3

• We can then rank use cases, and other high-level
  features, according to these criteria

• This ranking should be reviewed after each
  iteration as new requirements and new insights
  will influence it
• The schedule needs to be adaptive
• In addition, we will always consider the Start Up
  use case to consider all the necessary
  initialisations in a systematic way.

4

• 8.3. Case Studies Requirements for Iteration 1
• For the POS
• Implement a basic, key scenario of the Process
  Sale use case entering items and receiving a
  cash payment.
• Implement a Start Up use case as necessary to
  support the initialization needs of the
  iteration.
• Nothing fancy or complex is handled, just a
  simple happy path scenario, and the design and
  implementation to support it.
• There is no collaboration with external services,
  such as a tax calculator or product database.
• No complex pricing rules are applied.
• User Interface Prototyping if not done already
  (we will not see this)

5

• Discussion
• Subsequent iterations will grow on these
  foundations
• The requirements have been simplified for the
  first iteration to fit in a given time-box
• In iterative lifecycle processes (such as the UP,
  XP, Scrum, and so forth) We start
  production-quality programming and testing for a
  subset of the requirements, and we start that
  development before all the requirements analysis
  is complete contrast to a waterfall process.
• A use case can span more that one iteration see
  Figure 8.1

6
Figure 8.1 Spreading Use Cases

• 8.4 From Inception to Elaboration
• The inception phase may only last 1 week
  (typically more) it is not very long
• It determines basic feasibility, risk, and scope,
  to decide if the project is worth more serious
  investigation (Elaboration).

7

• During the Inception phase the following may
  occur
• a short requirements workshop
• most actors, goals, and use cases named
• most use cases written in brief format 10 to 20
  of the use cases are written in fully dressed
  detail to improve understanding of the scope and
  complexity
• most influential and risky quality requirements
  identified
• version one of the Vision and Supplementary
  Specification written
• risk list
• For example, leadership really wants a demo at
  the POSWorld trade show in Hamburg, in 18 months.
  But the effort for a demo cannot yet be even
  roughly estimated until deeper investigation.
• technical proof-of-concept prototypes and other
  investigations to explore the technical
  feasibility of special requirements
• user interface-oriented prototypes to clarify the
  vision of functional requirements
• recommendations on what components to
  buy/build/reuse, to be refined in elaboration

8

• high-level candidate architecture and components
  proposed
• This is not a detailed architectural description,
  and it is not meant to be final or correct.
  Rather, it is brief speculation to use as a
  starting point of investigation in elaboration.
  For example, "A Java client-side application, no
  application server, Oracle for the database, "
  In elaboration, it may be proven worthy, or
  discovered to be a poor idea and rejected.
• plan for the first iteration
• candidate tools list
• On to the Elaboration phase
• Elaboration is the initial series of iterations
  during which
• the core, risky software architecture is
  programmed and tested
• the majority of requirements are discovered and
  stabilized
• the major risks are mitigated or retired
• Elaboration often consists of two or more
  iterations each iteration is recommended to be
  between two and six weeks prefer the shorter
  versions unless the team size is massive. Each
  iteration is timeboxed, meaning its end date is
  fixed.
• Build the core architecture, resolve the
  high-risk elements, define most requirements, and
  estimate the overall schedule and resources.

9

• Key ideas during elaboration
• do short timeboxed risk-driven iterations
• start programming early
• adaptively design, implement, and test the core
  and risky parts of the architecture
• test early, often, realistically
• adapt based on feedback from tests, users,
  developers
• write most of the use cases and other
  requirements in detail, through a series of
  workshops, once per elaboration iteration
• Treat each iteration during elaboration as a
  mini-project

10

• In addition to the artefacts created during
  inception (and which need to be refined during
  elaboration) the following artefacts can be
  created during the iterations of the elaboration
  phase
• Domain Model
• Design Model

11

• 8.5 Conclusion
• The elaboration phase will start before the
  specification is complete
• The elaboration phase will be followed by a
  longer Construction phase.
• During several iterations, the elaboration phase,
  builds the core architecture, resolves the
  high-risk elements, defines most requirements,
  and estimates/refines the overall schedule and
  resources.
• The Elaboration phase is not about requirements,
  nor design, nor coding it is all of these at
  once for the most important (possibly simplified)
  aspects of the project
• During Elaboration, feedback will evolve/complete
  the requirements.
• We must produce fully-tested, documented,
  production-grade code
• Questions Please