Download Report

2. Iterative, Evolutionary & Agile
CSE 5324 Quiz 2 due at 5 PM,
Tuesday, 26 August 2014
Chapter 2 Objectives
• Motivate the textbook’s content and order.
• Define the iterative, agile process.
• Define the Unified Process’ fundamental
concepts.
Introduction
• Iterative development (e.g., the Unified
Process) is the most effective way to do OOA
and OOD, whose object orientation facilitates
software development productivity.
• Light-weight agile practices (e.g., Agile
Modeling) are the most effective ways of
applying UML, which facilitates
communications among developers.
Introduction – Continued
• The sequential “waterfall” software development
life cycle (SDLC) attempts to complete
requirements analysis, architecture, design,
coding and as many layers of testing in distinct
phases punctuated by irrevocable peer reviews. It
is associated with the highest failure rates among
all SDLCs.
• Iterative development codes and tests parts of a
system in many short cycles. Before requirements are known in detail, software development feedback clarifies and improves evolving
specifications. It is associated with higher success
and productivity rates and lower defect levels.
2.1 UP & Associated Methods
• The Unified Process (UP) is the de facto standard
iterative SDLC. (An SDLC tells how software is to
be built, deployed and maintained. IBM’s Rational
UP tool is in 124 ERB.)
• Heavier-weight agile practices, such as Extreme
Programming (XP) and Scrum, also are consistent
with UP.
• XP’s test-driven development, refactoring and
continuous integration also fit within any UP
project.
• Developers are encouraged to blend any or all of
these complementary methods as needed.
RUOK?
1. What is the most effective way to do
OOA/D?__
a. Agile Modeling, which is one of many lightweight agile practices.
b. The Unified Process, which is the most
popular form of iterative development.
c. Both of the above.
d. None of the above.
RUOK?
Match the following descriptions with the terms below:
2. Associated with high success and productivity rates and lower defect
levels.
__
3. Attempts to complete requirements analysis, architecture, design,
coding and as many layers of testing in distinct phases punctuated by
irrevocable peer reviews.
__
4. Develops and tests parts of a system in many short cycles. __
5. Associated with the highest failure rates of software development
life cycles.
__
6. Before requirements are known in detail, software development
feedback clarifies and improves evolving specifications.
__
7. A strictly sequential software development life cycle.
__
a. Waterfall.
b. Iterative development.
RUOK?
8. Which of the following is NOT true of the Unified Process
(UP)? __
a. UP is the de facto standard iterative software
development life cycle; i.e., how software is to be built,
deployed and maintained.
b. Light-weight agile processes and heavier-weight agile
practices, such as Extreme Programming (XP) and Scrum,
are consistent with UP.
c. XP’s test-driven development, refactoring and continuous
integration also fit within any UP project.
d. Developers should not attempt to blend combinations of
these methods, because that would dilute the UP’s
effectiveness.
2.2a Iterative & Evolutionary Development
Fig. 2.1. Iterative and Evolutionary Development.
• Each ~3-week iteration is a mini-project, with
its own requirements analysis, design,
implementation and testing activities, which
produce a fully tested, integrated and
executable partial system.
• The ~5 iterations’ incremental growth depend
upon feedback and adaptation to evolve the
system’s specifications and design (Fig. 2.1).
2.2b An Example Iteration
1st Monday: Team leader clarifies new iteration’s
tasks and goals. Team manager prints and displays
Rhapsody UML diagrams, which were reverse
engineered from the last iteration’s tested (higher
risk) subsystem. Together they do agile modeling
(i.e., trade studies of design alternatives), and
sketch rough UML diagrams of the new iteration’s
software, including pseudocode and design notes.
1st Wednesday through 3rd Friday: Implementation, unit/acceptance/usability testing, design
refinements, integration and daily builds. Also
demonstrations/evaluations with stakeholders, who
help plan the next iteration.
2.2c Iterative Projects Embrace Change
Fig. 2.2. Requirements and design converge.
• Iterative developers welcome change, evolution and
adaptation.
• Continually agreed upon requirements converge, as
stakeholders clarify their visions in the ever changing
marketplace.
• After choosing a small subset of the (highest risk)
remaining requirements, each iteration quickly designs,
code and tests, all of which evokes valuable feedback
for the next. For example, users say, “Yes, this is what I
asked for, but what I need is a little more of that.” And
load testing either proves the partial design or suggests
minor course corrections (Fig.2.2).
2.2d Iterative Development Benefits
1. Fewer failures: successful projects, higher
productivity, fewer defects.
2. Earlier risk mitigation: requirements, technical,
usability.
3. Happy customers: early visible progress, early
feedback, more user engagement, adaptation, refined
systems that more closely meet stakeholders’ needs.
4. Complexity management: development team not
overwhelmed by “analysis paralysis” or very long,
complex steps.
5. Learning by doing: on-the-job training, innovative
design patterns, process improvements.
2.2e Iteration Timeboxing
• Choose a 2- to 5-week iteration length, and stick
with it…!
• Shorter iterations are better, but meaningful
work can’t be completed in fewer than 2 weeks.
• Longer iterations are too complex, and their
feedback comes too late.
• The partial system must be integrated, tested and
stabilized by the scheduled date.
• If deadline is too hard to meet, move planned
tasks or requirements into the next iteration.
RUOK?
9. Which of the following is NOT true of iterative and
evolutionary development? __
a. Each iteration is a mini-project, with its own
requirements analysis, design, implementation and
testing activities.
b. Ideally these disparate activities should not overlap.
c. Each iteration produces a fully tested, integrated and
executable partial system.
d. Incremental growth of the iterations depends upon
feedback and adaptation to evolve the system’s
specifications and design.
e. Consistent with your 15-week Fall semester, a project
may consist of five 3-week iterations.
RUOK?
10. If each iteration is 3 weeks long, when should Rhapsody
UML diagrams be drawn? __
a. Throughout the current iteration’s OOA/D cycle, before its
coding and testing begin.
b. Light-weight agile urges developers to roughly sketch UML
diagrams, instead of completing those detailed formal
diagrams that Rhapsody requires.
c. On the new iteration’s first day, to reverse engineer the
tested code of the prior iteration.
d. Just before the iteration’s concluding demonstration to
stakeholders, because they may want to carefully inspect
the UML and possibly edit it.
e. None of the above.
RUOK?
11. Which of the following does NOT describe an iterative project’s
changing requirements? __
a. Iterative developers welcome change, evolution and adaptation.
b. Continually agreed upon requirements converge, as stakeholders
clarify their visions of the ever changing marketplace.
c. An iterative developer would consider the following user response
to be good feedback for use in the next iteration: “Yes, this is what
I asked for, but what I need is a little more of that.”
d. Load testing may validate the partial design or suggest minor
design course corrections in the next iteration.
e. Requirements must not be allowed to “creep.”
f. All of the above are descriptive of iterative projects’ changing
requirements.
RUOK?
12. Which of the following is NOT a benefit of iterative
development? __
a. Fewer failures: successful projects, higher productivity,
fewer delivered defects.
b. Earlier risk mitigation: requirements, technical, usability.
c. Happy customers: early visible progress, early feedback,
more user engagement, adaptation, refined systems that
more closely meet stakeholders’ needs.
d. Jobs for high school graduate C coders.
e. Complexity management: development team not
overwhelmed by “analysis paralysis” or very long, complex
steps.
f. Learning by doing: on-the-job training, innovative design
patterns, process improvements.
RUOK?
13. Which of the following is NOT true of iteration
timeboxing? __
a. After a project commits to a particular iteration
length, it must not change.
b. Plan each iteration to be the shortest possible interval
in which significant work can be accomplished.
c. At each project’s onset, company management
estimates the number of iteration timeboxes and the
average length of each, to ensure on-time delivery.
d. If deadline is too hard to meet, move planned tasks or
requirements into the next iteration.
2.3a Avoid Waterfall’s Errors
1. Resist temptation to declare too many
requirements before development begins.
2. Avoid thorough and detailed UML models and
designs before coding.
3. About half of waterfall requirements never
deliver as product functions, and waterfall
schedule estimates vary by 400%.
4. Research shows iteration is much better.
5. Avoid even thinking about waterfall practices;
e.g., big, up-front analyses and modeling.
2.3b Waterfall is Failure Prone
1. It assumes that predictable, stable specifications
will be correctly defined at project onset and will
never change.
2. In fact, in the course of a typical software
project, 25% of requirements change, and larger
projects’ requirements change by 35 to 50%.
3. Software projects are connected with new
product developments, not with traditional
mass manufacturing with its small incremental
changes.
4. Stable software requirements and refined
designs evolve from continual feedback.
2.4 How To Develop Software
Fig. 2.4. Evolutionary analysis and design.
1. Before iteration-n: Developers and stakeholders list the
high-level requirements and do an intense OOA of 20% of
the most significant; i.e., highest risk and business value.
Break down one of the use cases into detailed iteration
tasks.
2. Iteration-n: Pick a timebox. Project leader and manager
spend a day Agile Modeling the subsystems in many
UML-ish sketches. Then they repeatedly code, test and
integrate. On the last day, coding stops and testing
culminates in an iteration baseline. (They may delay tasks
to complete on time.) And they demonstrate the partial
system’s performance to stakeholders for feedback, which
enables requirement and design refinements.
3. Repeat steps 1 and 2 till system delivery (Fig. 2-4).
2.5 Risk- and Client-Driven Planning
• Early iterations 1) identify and mitigate
highest risks and 2) build the features that the
client desires most.
• To mitigate risk, early iterations focus on
building, testing and stabilizing the core
architecture, because all other system
elements depend so heavily on it.
• Author’s disclaimer: early iterations of this
textbook’s examples focus on learning goals,
not the items listed above for real projects.
2.6 Agile Methods & Attitudes
• Timeboxed iterative/evolutionary development,
adaptive planning and incremental delivery all encourage rapid and flexible responses to change; i.e., agility.
• Agile Manifesto: 1) individuals & interactions >
processes & tools, 2) working software > comprehensive documentation, 3) customer collaboration >
contract negotiation and 4) responding to change >
following a plan.
• Agile Principles: 1,3,7) weekly software deliveries =
happy customer, 2) change = customer’s competitive
edge, 4) business people & developers meet daily,
5,10,12,13) support good workers, 6) talk face-to-face,
8,9) steady pace and 11) simplify.
RUOK?
14. True or False: To avoid “waterfall thinking,”
good iterative developers do every task
incompletely and move on to the next. __
a. True.
b. False.
RUOK?
15. What is the waterfall SDLC’s most fatal flaw? __
a. It assumes that 25% of requirements typically change,
and larger projects’ requirements change by 35 to
50%.
b. It assumes regards software projects like traditional
mass manufacturing, which has manageably small
incremental changes.
c. It assumes that predictable, stable specifications will
be correctly defined at project onset, and they will
never change.
d. It assumes that stable software requirements and
refined designs can evolve from continual feedback.
e. None of the above.
RUOK?
Arrange the following software development steps in chronological order:
16. __ 17. __ 18. __ 19. __ 20. __ 21. __ 22. __ 23. __
24. __ 25. __ 26. __ 27. __ 28. __
a. Developers and stakeholders list high-level requirements.
b. Do an intense OOA of only the highest risk and highest business value
20% of the requirements.
c. Break down just one of the OOA’s use cases into detailed iteration tasks.
d. Set the iteration’s time interval.
e. Agile model the iteration’s partial system in many UML-ish sketches.
f. Repeatedly code, test and integrate.
g. Stop coding, so that testing can culminate in an iteration baseline.
h. Delay tasks as necessary to complete the iteration on time.
i.
Demonstrate the partial system’s performance to stakeholders.
j.
Accept feedback, for use in refining future requirements and designs.
k. Repeat until the system is complete.
l.
Deploy the system.
m. Do beta testing.
RUOK?
29. What is the highest risk task in the typical
software development project? __
a. Accurately assessing users’ needs.
b. Incorrectly assessing the product’s market.
c. Developing the core architecture.
d. Allocating responsibilities to objects.
e. None of the above.
RUOK?
30. Which of the following is incorrect,
according to the Agile Manifesto? __
a. Individuals & interactions > processes &
tools.
b. working software > comprehensive
documentation.
c. contract negotiation < customer
collaboration.
d. responding to change > following a plan.
e. Actually all of the above are correct.
2.7 Agile Modeling
Fig. 2.5. An example UML-sketched sequence diagram.
• UML sketches help developers understand and talk about
the problem (OOA) and see the path to a good OOD, not
document its solution. (Don’t give the sketches to a
programmer.)
• Model and sketch UML only for the trickier parts of the
design, and save the easy design elements for the coders.
• Use the easiest, highest productivity tools available; e.g.,
whiteboards, camera (Fig.2.5). Always work in thinker and
scribe pairs. Create many models in parallel, trading off
complexities. Include only enough detail to be understood.
• All models are inaccurate—only tested code demonstrates
the (invisible) “true design.”
• OOD modelers should code their own designs—Oops…!
2.8 Agile UP
• An agile Unified Process (UP) reuses a small
subset of UP’s rich set of activities and artifacts.
• Continually evolving through feedback,
requirements and designs are incomplete before
implementation.
• The UP suggests applying UML in agile models.
• Don’t plan projects in detail. UP’s high-level
phase plan identifies project milestone dates, and
its iteration plan (adaptively) describes only the
current iteration.
2.9 Critical UP Practices
1. Keep all development short, timeboxed, iterative,
evolutionary and adaptive.
2. Do high risk (e.g., core architecture) and high value
(user preferences) tasks first.
3. Continually accept users’ feedback, evaluations and
requirements.
4. Verify quality by testing early, often and realistically.
5. Apply use cases as needed, and do UML modeling.
6. Carefully manage requirements, change requests and
software configurations.
2.10 UP Phases
Fig. 2.6. UP phases.
1. Inception: approximate vision, business case,
scope, vague estimates (i.e., a stop or go
feasibility study).
2. Elaboration: vision refined, core architecture
iterative implementation, high risks resolved,
requirements and scope identified, more
realistic estimates.
3. Construction: lower risk and easier elements
iteratively implemented, prepare for
deployment.
4. Transition: beta testing, deployment.
2.11 UP Disciplines
Fig. 2.7. UP Disciplines.
Fig. 2.8. Disciplines &phases.
• UP “disciplines” (e.g., Requirements) produce
“artifacts” (e.g., tested code).
• The Business Modeling discipline produces Object
Model Diagrams, which show application concepts.
• The Requirements discipline captures functional and
nonfunctional requirements as a Use Case Model and
Supplementary Specifications.
• The Design discipline produces the Design Model,
which (momentarily) describes software objects.
• Implementation: coding and building the objects.
• Environment: setting up UP process and tools.
RUOK?
31. Which of the following is NOT a valid agile UML sketching
guideline? __
a. UML sketches help developers understand and talk about the
problem (OOA) and see the path to a good OOD, not document its
solution.
b. Sketch only enough detail to be clearly understood.
c. Give the finished OOD sketches to the project’s coders.
d. Model and sketch UML only for the trickier parts of the design,
and save the easy design elements for the coders.
e. Use the easiest, highest productivity tools available; e.g., many
whiteboards and a digital camera.
f. Always work in thinker and scribe pairs.
g. Create many models in parallel, trading off complexities.
h. All models are inaccurate—only tested code demonstrates the
(invisible) “true design.”
i. OOD modelers should code their own designs.
RUOK?
32. Which of the following is NOT true of agile UP? __
a. An agile Unified Process (UP) should reuse only a
small subset of UP’s rich set of activities and artifacts.
b. To continually evolving through feedback,
requirements and designs nevertheless should be
complete before implementation.
c. The UP suggests applying UML in agile models.
d. Don’t plan projects in detail.
e. UP’s high-level phase plan only identifies project
milestone dates.
f. UP’s iteration plan describes only the current
iteration.
RUOK?
33. Which of the following practices is NOT critical to UP?
__
a. Keep all development short, timeboxed, iterative,
evolutionary and adaptive.
b. Do high risk (e.g., core architecture) and high value
(user preferences) tasks first.
c. Continually accept users’ feedback, evaluations and
requirements.
d. Verify quality by testing early, often and realistically.
e. Apply use cases as needed, and do UML modeling.
f. Manage requirements, change requests and software
configurations to the least possible extent.
RUOK?
Match the following UP phases with their definitions:
34. Inception: __
35. Elaboration: __
36. Construction: __
37. Transition: __
a. Vision refined, core architecture iterative
implementation, high risks resolved, requirements and
scope identified, more realistic estimates.
b. Lower risk and easier elements iteratively
implemented, prepare for deployment.
c. Approximate vision, business case, scope, vague
estimates (i.e., a stop or go feasibility study).
d. Beta testing, deployment.
RUOK?
Match the following UP disciplines with the artifacts that they
produce:
38. Business Modeling: __
39. Requirements: __
40. Design:
__
41. Implementation: __
42. Environment: __
a. Set up UP process and tools.
b. Coded and built objects.
c. Design Model, which (momentarily) describes software
objects.
d. Functional and nonfunctional requirements captured as a
Use Case Model and Supplementary Specifications.
e. Object Model Diagrams, showing application concepts.
2.12 The Development Case
Table 2.1. Sample Development Case.
• The table above summarizes practices and
artifacts in each UP discipline for an arbitrary
example development project.
2.13 Iterative Development & UP
In summary, here is a list of things that should NOT
be done in a UP iterative development project:
1. Defining most requirements before design and
most of design before implementation.
2. Defining designs and models in great detail, so
that coding becomes largely mechanical.
3. Assuming inception = requirements, elaboration
= design, and construction = implementation.
4. Believing that each iteration is 3 months long.
5. Thinking the UP is a rigid list of practices and
artifacts.
6. Planning a project in detail, from start to finish.
2.14 History
1950s: Evolutionary, iterative and incremental
development (IID) used on NASA’s Mercury project.
1960s: IID used on Trident submarine project.
1968: IBM published first paper on IID.
1970s: Seventeen 4-week iterations of IID used on
NASA’s Space Shuttle flight control system.
1980s: Boehm published paper describing the
“spiral” model, risk-driven IID method.
1990s: IID begat UP, DSDM, Scrum, XP, etc.
RUOK?
43. Who would prepare a “Development Case” table,
when and why? __
a. Company management, stakeholders and Software
Engineers collaborate in writing it as a Software
Development Plan in the UP’s Business Modeling
discipline.
b. In the Environment discipline, company management
prepares it to list the deliverables promised from
every project phase, in compliance with the
customer’s development contract.
c. Software Engineers prepare a part of it on the first
day of every iteration to report their progress.
d. None of the above.
RUOK?
44. How would you translate into POSITIVE
instructions the foregoing “list of things that should
NOT be done in a UP iterative development
project”? __
a. Just relax, and do what comes naturally to any
competent Software Engineer.
b. Do the hard work first, and the remainder
whenever.
c. Do whatever your stakeholders want every day.
d. All of the above.
e. None of the above.
RUOK?
45. How long have Software Engineers been
successfully applying evolutionary, iterative and
incremental development? __
a. About a decade.
b. For 2 decades.
c. About half a century.
d. For 6 decades.
e. About a century.
School Supplies
Everyone please bring to ERB124 on Wednesday,
August 27th:
–
–
–
–
pencils,
eraser,
white paper and
an email-enabled camera.
Also please bring your completed Confidentiality
Agreements, so that our grader can associate you
with your teammates. Thanks!