UNIT – I:

Introduction: Software is new product development –

Iterative development – Risk- Driven and Client-Driven
iterative planning – Time boxed iterative development –
During the iteration, No changes from external stakeholders
– Evolutionary and adaptive development - Evolutionary
requirements analysis – Early “Top Ten” high- level
requirements and skilful analysis – Evolutionary and adaptive
planning – Incremental delivery – Evolutionary delivery – The
most common mistake – Specific iterative and Evolutionary
methods.
Software is new
product development
 Consider building mobile phones on an assembly line: It is possible to
unambiguously define the specifications and construction steps.
 After building some phones and measuring things, it is possible to reliably
estimate and schedule the building of future phones.
 A different problem: Build a custom house. The owner wants to use new
environmentally friendly materials and methods, but isn't exactly sure
what they want, and is going to change or clarify their decisions as they
see the house, costs, and weeks unfold.
 At one end of the spectrum, such as manufacturing phones, there are
problems with low degrees of novelty or change, and high rates of
repeated identical or near-identical creation—mass manufacturing or
predictable manufacturing.
 At the other end, there are problems with high degrees of novelty,
creativity, and change, and no previous identical cases from which to
derive estimates or schedules. This is the realm of new product
development or inventive projects.
 The development process, management values, planning and estimation
models appropriately associated with these two domains are different.
 And now the point is :
Most software is not a predictable or mass
manufacturing problem. Software development is
new product development.
 Plus, many projects use new and buggy
technologies that exacerbate the degree of
novelty and unpredictability. Note also it is a new
product for the inexperienced even if it has been
done before.
 Since predictable manufacturing is the wrong
paradigm for software, practices and values
rooted in it are not helpful.
 This mismatch lies at the heart of many of the
challenges associated with traditional approaches
to running a software project.
 A "waterfall" lifecycle, big up-front specifications,
estimates, and speculative plans applicable to
predictable manufacturing have been misapplied
to software projects, a domain of inventive, high-
change, high-novelty work.
 Factors preventing reliable up-front specifications include:
 The clients or users are not sure what they want.
 They have difficulty stating all they want and know.
 Many details of what they want will only be revealed during
development.
 The details are overwhelmingly complex for people.
 As they see the product develop, they change their minds.
 External forces (such as a competitor's product or service) lead to
changes or enhancements in requests.
 This deep appreciation—that building software is complex, new product
development with high change rates, and not predictable manufacturing
—is at the heart of the motivation for agile and iterative methods.
 Certainly, another driving force is the desire to compete and win.
Iterative and agile methods foster flexibility and —competitive
advantage. In Agile Competitors and Virtual Organizations the authors
examine the limitations of the mass manufacturing model and the need
for agility:
 Agility […] is about succeeding and about
winning: about succeeding in emerging
competitive arenas, and about winning profits,
market share, and customers in the very centre of
the competitive storms many companies now fear.
Iterative &
Evolutionary
OVERVIEW:
 Basic practices of iterative and evolutionary
methods, including timeboxing and adaptive
planning.
 A common mistake adopting iterative methods.
 Specific iterative and evolutionary methods,
including Evo and UP.
Iterative development

 Iterative development is an approach to building

software (or anything) in which the overall lifecycle
is composed of several iterations in sequence.
 Each iteration is a self-contained mini-project
composed of activities such as requirements
analysis, design, programming, and test. The goal for
the end of an iteration is an iteration release, a stable,
integrated and tested partially complete system.
 To be clear: All the software across all the teams is
integrated into a release each iteration. Most iteration
releases are internal, a baseline primarily for the benefit of
the development team—they are not released externally.
The final iteration release is the complete product,released
to the market or clients. See Figure 2.1.
iterative and incremental
development
 Although an iteration can in theory be only for clean-up or
performance tuning, usually the partial system grows
incrementally with new features, iteration by iteration; in other
words, incremental development.
 The concept of growing a system via iterations has been called
iterative and incremental development (IID), although simply
"iterative development" is common.
 Some older process literature[Wong84] used the term
"incremental development" to mean a combination of frozen up-
front specifications followed by iterative development of the
features, but there is no widespread agreement on usage.
 In this era, most development methods are IID methods. And, IID
is at the core of all the agile methods, including Scrum and XP.
 Most projects have at least three iterations before a final public
release; I've seen a two-year Valtech project composed of close to
20 iterations averaging around four weeks each, and I know of at
least one long project with 45 iterations.
 In modern iterative methods, the recommended
length of one iteration is between one and six
weeks.
 Each iteration includes production-quality
programming, not just requirements analysis, for
example. And the software resulting from each
iteration is not a prototype or proof of concept,
but a subset of the final system.
 More broadly, viewing an iteration as a self-
contained mini-project, activities in many
disciplines (requirements analysis, testing, and so
on) occur within an iteration (see Figure 2.2).
Disciplines across
iterations
Risk-Driven and Client-
Driven Iterative Planning
 What to do in the next three-week iteration? IID methods
promote a combination of risk-driven and client-driven
priorities.
 Risk-driven iterative development chooses the riskiest,
most difficult elements for the early iterations. For
example, maybe the client says "I want the Web pages to
be green and the system to handle 5,000 simultaneous
transactions." Green can wait.
 In this way, the highest risks are surfaced and mitigated
early rather than late. Risk is a broad concept—maybe you
are making a new 3D modelling tool and market research
shows that what will capture market interest is a novel,
much easier user interface metaphor. The high risk is
not getting the UI right.
 Client-driven iterative development implies
that the choice of features for the next
iteration comes from the client—whatever
they perceive as the highest business value to
them.
 In this way, the client steers the project, iteration by
iteration, requesting the features that they currently
think are most valuable. Note that the customer
adaptively plans the choice for the next
iteration, shortly before it starts, based on their
latest insight, rather than speculatively at the start
of the project.
 The customer has ongoing control and choice, as
fresh information arises.
Iteration Goals: Risk, Coverage,
Criticality, Skills Development

 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.
 The goal is to discover and stabilize the major
software and hardware components, their
interfaces, and collaborations.
 That's an important part of the overall architecture.
For example, early use case scenarios may be chosen
that require execution (and thus development) across
many of the components (e.g., from UI to database).
These are called architecturally significant use
cases.
Timeboxed Iterative
Development
 Iteration timeboxing is the practice of fixing
the iteration end date and not allowing it to
change. An overall project may be
timeboxed as well.
 If it eventually appears that the chosen requests
(the scope) for the iteration can't be met within
the timebox, then rather than slip the iteration
end date, the scope is reduced (placing lower
priority requests back on the wish-list), so that the
partial, growing system always ends in a stable
and tested state on the original planned iteration
end date
Figure 2.3. timeboxing
 It is important that timeboxing is not used to
pressure developers to work longer hours to meet
the soon-coming deadline.
 If the normal pace of work is insufficient, do less.
 In most IID methods, not all timebox lengths need
be equal. The first iteration may be four weeks,
the second iteration three weeks, and so forth.
 On the other hand, the Scrum method
recommends that each timebox be exactly 30
calendar days.
 As mentioned, most IID methods recommend an
iteration timebox between one and six weeks.
 A three-month or six-month timeboxed "iteration"
is extraordinarily long and usually misses the
point and value; research shows that
shorter steps have lower complexity and risk,
better feedback, and higher productivity and
success rates.
 That said, there are extreme cases of projects
with hundreds of developers where a three-month
iteration is useful because of the overhead.
 All the modern IID methods (including Scrum, XP,
and so forth) either require or strongly advise
timeboxing the iterations.
During the Iteration, No Changes
from External Stakeholders

 Iterative and agile methods embrace change, but

not chaos. In a sea of constant change, a point of
stability is necessary.
 In IID methods this is achieved with the rule:
 Once the requests for an iteration have been
chosen and it is underway, no external stakeholders
may change the work.
 One week into a three-week iteration, the product
manager should not come along, and ask, "Can you
do this too?" They wait for the
next iteration. However, the team itself can reduce
the scope of an iteration if the timebox deadline
cannot otherwise be met.
Iteration Goals: Primary and
Secondary Requests

 By frequently tracking remaining effort estimates, it

may eventually appear that not all requests will be
completed within the iteration.
 In timeboxed methods the response is to remove or
simplify requests, rather than extend the iteration.
What to remove? On projects with a strong
customer-driven emphasis (such as XP projects),
consider this approach: During the iteration planning
meeting with customers, after the requests have
been chosen, classify some as secondary that may
be deferred.
 Not only does this support the agile spirit of
customer-driven work, it also aids expectation
management.
Evolutionary and Adaptive
Development
 Evolutionary iterative development implies
that the requirements, plan, estimates, and
solution evolve or are refined over the
course
of the iterations, rather than fully defined and
"frozen" in a major up-front specification effort
before the development iterations begin.
 Evolutionary methods are consistent with the
pattern of unpredictable discovery and change in
new product development.
Adaptive development

 Adaptive development is a related term. It

implies that elements adapt in response to
feedback from prior work—feedback from
users, tests, developers, and so on.
 The intent is the same as evolutionary development,
but the name suggests more strongly the feedback-
response mechanism in evolution.
 Some methods or methodologists emphasize the
term "iterative" while others use "evolutionary" or
"adaptive."
 The ideas and intent are similar, although strictly
speaking, evolutionary and adaptive development
does not require the use of timeboxed iterations.
Evolutionary
Requirements Analysis
 In evolutionary and adaptive development, it is not the
case that the requirements are forever unbounded or
always changing at a high
rate.
 Rather, most requirements discovery and refinement
usually occurs during early iterations, and the earliest
attention is given to understanding the most
architecturally significant or high-business-value
requirements.
 For example, on an ultimately 20-iteration
project, it is likely that most requirements will be
discovered and refined within the first three or four
iterations (that include, in parallel, early software
development).
 In each iteration, there is a one- or two-day
requirements workshop in which the specifications
expand and refine, in response to further analysis
and feedback from the system under
development.
 See Figure 2.4. For example, the first workshop
focuses on detailed analysis of 20% of the most
architecturally significant and risky requirements;
this gives the software architect enough
meaningful input to start development and test in
short cycles.
Figure 2.4. evolutionary
and iterative requirements
Note as a design comment, that it is not true that 100% of the
functional requirements need be known to start building an
excellent core architecture. The architect needs to know most non-
functional or quality requirements (e.g., load, internationalization)
and a much
smaller representative subset of functional requirements.
Early "Top Ten" High-Level
Requirements and Skillful Analysis

 It is a misunderstanding to equate evolutionary

requirements analysis with "no early
requirements" or sloppy requirements practices.
 Modern IID methods encourage the early creation
and baselining of vision statements, "top ten"
high-level requirements lists, and early analysis of
architecturally influential factors, such as load,
usability, and internationalization.
 Further, these methods encourage many skillful
analysis techniques during early iterations, such
as a series of requirements workshops involving
both target users and developers, writing use
cases, and much more.
Evolutionary and Adaptive
Planning
 As with evolutionary requirements, with
evolutionary and adaptive planning it is not the
case that estimates and schedules are forever
unbounded or unknown.
 Yet, due to early requirements change and other
factors, there is an initial phase of high
uncertainty, which drops as time passes and
information accumulates. This has been called the
cone of uncertainty
Figure 2.5. cone of
uncertainty
 The iterative response to this uncertainty is to defer an
expectation of semi-reliable estimates for cost, effort or
schedule
 until a few iterations have passed. Perhaps 10% to 20% into a
project.
 This is consistent with management practice in other new
product development domains, where an initial exploratory
phase is common.
 Further, the practice of adaptive planning is encouraged
rather than predictive planning. That is, a detailed
schedule is not created
 This document was created by an unregistered ChmMagic,
please go to http://www.bisenter.com to register it. Thanks
 beyond a relatively short time horizon, so that the level of detail
and commitment is commensurate with the quality of
information.
Fixed-Price Contracts

 With respect to fixed-price bidding and evolutionary

estimates, some IID methods (such as the UP) recommend
running projects in two contract phases, each of multiple
timeboxed iterations.
 The first phase, a relatively short fixed-time and fixed-price
contract, has the goal of completing a few iterations, doing
early but partial software development and evolutionary
requirements analysis.
 Note the key point that partial software is produced, not
merely documents.
 The outputs of phase one—including the software base—are
then shared with bidders for a phase two fixed-price contract.
 The evolutionary refinement of specifications and code in
phase one provides higher quality data for phase two
estimators, and advances the software for the project.
Figure 2.6. two contract
phases
Incremental Delivery

 Incremental delivery is the practice of

repeatedly delivering a system into
production (or the marketplace) in a series
of expanding capabilities (Figure 2.7).
 The practice is promoted by IID and agile
methods. Incremental deliveries are often
between three and twelve months.
Figure 2.7. incremental
delivery with iterations
 Incremental delivery is often confused with
iterative development.
 A six-month delivery cycle could be composed of
10 short iterations.
 The results of each iteration are not delivered to
the marketplace, but the results of an incremental
delivery are.
Evolutionary Delivery

 Evolutionary delivery is a refinement of the

practice of incremental delivery in which
there is a vigorous attempt to capture
feedback regarding the installed product, and
use this to guide the next delivery.
 Naturally, the evolutionary goal is to best meet
some difficult-to-predict need, such as the most
frequently requested new features.
 Uniquely, the Evo method promotes—when
possible—very short evolutionary delivery cycles of
one or two weeks, so that each iteration delivers
something useful to stakeholders.
 To contrast "pure" incremental delivery with
evolutionary delivery, in the former a plan is
defined of several future deliveries—feedback
 is not driving the delivery plan.
 In evolutionary delivery, there is no plan (or at
least no fixed plan) of future deliveries; each is
dynamically created based on emerging
information.
 In practice, a marriage of some future prediction
and feedback is obvious and common, and the
two terms are used interchangeably.
The Most Common
Mistake?
 Iterative and agile process coaches often see
scenarios like this:
Jill:
 Sure, we don't apply the waterfall—everyone
knows it doesn't work. We've adopted <iterative
method X> and are into our first project.
 We've been at it for two months and have the use
case analysis nearly finished, and the plan and
schedule of what we'll be
doing in each iteration.
 After review and approval of the final
requirements set and iteration schedule, we'll
start programming.
Specific Iterative &
Evolutionary Methods
 Specific agile methods are summarized in the
next chapter. This section mentions some iterative
methods (Evo and UP) that predate
most agile methods; they may or may not be
considered agile.Of all the methods mentioned in
this book (Scrum, XP, Evo, UP, OPEN, DSDM, ...)
the UP or its variation the Rational Unified
Process(RUP) is perhaps the most widely used. It
is found in thousands or tens of thousands of
development organizations worldwide.
 This does not mean it is well applied or well
understood.
Evo

 Evo was perhaps the first iterative and

evolutionary method, starting in the 1960s. Evo
recommends short 1–2 week iterations, and
uniquely, evolutionary delivery each iteration.
 Evo adaptively plans iterations by highest value-
to-cost ratio, and strongly promotes the
unambiguous definition of quality requirements
(such as load) with quantified and measurable
statements.
Unified Process

 The UP or RUP, first developed in the mid-1990s,

brings together the knowledge of many
experienced large-system architects and
process-leaders at Rational Corp., and their
customers, into a well-defined IID method.
 One key UP theme is risk-driven development in
the early iterations, focusing on creation of the
core architecture and driving down the high risks.
 The UP also includes the definition of common
project work products, such as the Vision,
Software Architecture Document, and Risk List.
Other Methods

 In addition to UP and Evo, other IID methods

include:
 The Microsoft Solutions Framework process,
available from Microsoft Education. It is a
description of best practices used
 by Microsoft.
 The OPEN process from Henderson-Sellers,
Firesmith, and Graham [FH01].
 WinWin Spiral Model and MBASE Spiral
Model from Barry Boehm (creator in the
1980s of the well-known iterative Spiral
Model) and colleagues