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