Readings: � Pressman Chapter 3, � MMM "Plan to throw one away"
Recall the waterfall model: � Systems engineering� Requirements analysis� Design� Implementation� Testing� Maintenance
The case for the waterfall model:� Software development can be carefully monitored by
management.� Least effort is wasted by knowing what to do before
doing it. � Resulting software product is of the highest quality.
But...
The elephant in the room Wednesday, September 09, 20092:37 PM
Agility Page 1
Software quality isn't everything! Other factors include: � Time to market. � Timely response to changing requirements. � Length of expected product lifecycle.
Somebody has to make money!
But... Wednesday, September 09, 20092:39 PM
Agility Page 2
The elephant in the room� Software Engineering is all about minimizing cost of
development.� The elephant in the room is that this is meaningless
without a concept of value. Profit = value - cost. � If a product has low value, then the software
engineering process may be meaningless. � If it has a guaranteed high value, then traditional
software engineering will work. � But if a product has a contextual value, this can
change everything about the best process to use to implement it.
Cost and Value Thursday, September 10, 200910:59 AM
Agility Page 3
Concepts of value and profit: � Lifecycle return = total value - total cost. � Short-term return = short-term value - short-term
cost.� Time-critical value = 0 unless some external deadline
is met.
Concepts of value Thursday, September 10, 200911:06 AM
Agility Page 4
The release of any new product is a risk.� People may not buy it. � It might not work. � Another product might eclipse it. � Another product might be released first.� People might not have enough motivation to switch from
an inferior product (products have "inertia").
Estimating the value of a product is a matter of quantifyingthese risks.
Understanding risk Thursday, September 10, 200911:09 AM
Agility Page 5
It is not survival of the fittest; it is survival of those who fit!
Darwinism Monday, September 14, 20094:47 PM
Agility Page 6
Alternative models of software engineering� Agile development: optimize time-to-market.� Component-based design: optimize for reuse of
existing components. � Prototyping: determine underspecified requirements
via direct experiment.
"Alternatve" software engineering Wednesday, September 09, 20092:36 PM
Agility Page 7
What if being first in the market is everything?� MySpace is awful, but it was first, and people still use
it even though better alternatives are available! � No one has managed to create the second ebay!
Answer: we need a software development process that weighs being first over software quality!
Agile development Wednesday, September 09, 20092:42 PM
Agility Page 8
Principles of agile development� Start design before requirements are etched in stone. � Start development before design is etched in stone. � Start testing before development is etched in stone.
Get the darn product out...
Principles of agile development Wednesday, September 09, 20092:44 PM
Agility Page 9
Agility requires more total work:� Design has to be done multiple times, as
requirements change in the short term. � Ditto for implementation and testing.
Proponents of agility believe that:� The overall product is more robust because its ability
to adapt to changes has been tested during the agile process.
� The time to market is less than required for traditional waterfall approaches.
� One can utilize more people to shorten development time.
Faster TTM versus "more work" Monday, September 14, 20092:08 PM
Agility Page 10
An agile process: � Copes with uncertainty by never committing
prematurely to a design. � Lowers time-to-market (TTM) by placing less emphasis
on absolutely correct requirements. � Defers development costs until product success can be
predicted from data.� Constantly tests robustness of the output of each phase
of the process.
Properties of agile process Wednesday, September 09, 20092:50 PM
Agility Page 11
A prototype (of a product) is a version developed without the software engineering process.
This is very different than a version of an agile process.
Prototype hasNo documentationNo test plan(No design!)
Agile product hasIteratively refined documentation. Iteratively refined test plan. Iteratively refined design.
Prototyping Monday, September 14, 20092:57 PM
Agility Page 12
The capability to do something with a software product depends upon the model of development under which it was created.
Key issue Monday, September 14, 20095:08 PM
Agility Page 13
So, which is best? � Agile development lowers TTM but raises total cost if
product succeeds. � Traditional development raises TTM but overall cost
is lower. Do you really want to spend a lot on a product that can fail?� Are you a betting person? � Are you feeling lucky?
Agile versus traditional SE Wednesday, September 09, 20093:01 PM
Agility Page 14
Understanding the big picture Monday, September 14, 20092:14 PM
Agility Page 15
Agility Monday, September 14, 20092:14 PM
Agility Page 16
How would you develop: � A new computer game? � An online banking application? � A new social networking site? � An e-commerce site?
In-class discussion Wednesday, September 09, 20092:46 PM
Agility Page 17
Alex Lamb: Software engineering is planning for change.
Things that can change include:� Customer requirements (e.g., for product) � Software environment (e.g., evolving threats) � Market (e.g., potential for new customers)
The traditional waterfall model attempts to minimizechange during the development process.
An agile process instead tests for adaptability of the current product to ever-changing needs. The product gets a trial-by-fire during the development process.
Planning for change Monday, September 14, 20092:23 PM
Agility Page 18
Is there a reason for a model? � Some projects are so small, that the traditional
waterfall model does not seem to profitably apply. � But there is value in knowing the model under which
software was developed. � This can guide strategic decisions about the future of a
product.
There is a huge difference between a product and a prototype!
Should there be a development model? Monday, September 14, 20092:28 PM
Agility Page 19
In Brooks' essay "Plan to throw one away", Brooks advocates exploratory software development to discoverrequirements. But: � Don't get confused about the difference between a
prototype and a product.� Be prepared to throw away prototypes. � Keep management and the customer informed about
that difference.
Reason: there are things about a product that cannot easily be recovered if product development isn't documented.
Plan to throw one away Monday, September 14, 20092:30 PM
Agility Page 20
Lessons learned� Choice of model depends upon what's important. � Largely this is a decision about when to spend money
on the project, and what timing constraints there are. � The model used determines the potential value of a
product.� It is a dire mistake to consider a prototype as a
product, or to confuse products developed according to rigorous engineering models with software developed without an engineering model.
Lessons learned from alternative models
Wednesday, September 09, 20093:06 PM
Agility Page 21
