Development processes, waterfall which is the more traditional, versus what this
course is about its Agile.
Waterfall, is it gets called a life cycle.
It's basically a development crisis but I was
confused when they used life cycle like lifetime.
That's not what it is.
Life cycle is kind of the development process
of software.
The, we'll explain what Waterfall is, but this idea you go through
these steps and you're kind of like falling down a waterfall.
You complete a phase as you go onto the next one.
Kind of sarcastically, it gets lumped into a
couple of other things called big design up front.
There's a lot of planning in this one.
So that's another phrase you can hear.
So, here would be the first step of the waterfall.
Requirement, analysis, and specification.
You'd write this down.
Before you write a line of code, you'd do the requirement, analysis, and
specification.
And you do an architecture design.
And once the software architecture is going to be, still you're not writing
any code, then you do the implementation.
So you've completed the first two phases.
Now you start doing the, writing a lot of code.
Now that that's been done, then you do the verification phase.
Typically, and these phases often get done by different
people.
That would be some people doing the requirements, some people doing the
architecture, some people doing the implementation, and a separate
verification or testing team.
And then, and probably a separate group to do
operations and maintenance.
Now you've got it running.
You're delivering it.
People are operating.
So these are different, the program to go through these phases, so
this is kind of the classic way that it's done.
This is basically the way that hardware is done.
That's probably why software followed this model.
Hardware absolutely gets the requirements,
architecture design, implementation, verification, operation, and maintenance.
This is the way hardware's done.
So this is the waterfall model.
And why did they do it this way?
A lot of data suggests the earlier you catch the bug, the cheaper it
is.
If you don't get the bug until in the verification phase, boy that's a lot
harder to fix.
If you could just get it by getting requirements right, that saves a
lot of money.
But this is, and one of the reasons they do the extensive
documentation, is these phases take a long time and so people come and go and so new
persons on the team, how do they get up to speed?
Well, they read the documentation.
How it was able to work.
It really works well for things that don't change fast.
Correct.
So NASA space craft or going to the moon.
You know.
That's a classic one.
Aircraft control you know, 747, you got softer in there.
Boy, you really went very tight specs [inaudible] that's not gonna
change.
On the other hand, a lot of the software that all of us use is this custom
basing software is you talk to the customer what they want, you'll get,
hopefully get to experience that in class, and then you go away, you do the specs and
all that and you build it and you get there, and that's, That's not what I want,
I want something different.
So is it, did you just end up with a bad customer?
No, that's pretty common.
The other thing for developers is they build it, they go
through these phases.
And once they're all done they realize, now I know how to build
it.
And that, once it's done and once I built the program now I know how to build
it.
So this has got one of so, as you'll see in the book, there's a, we, we do this
a lot, we quote famous people.
So Fred Brooks one of who received the highest
award in computer science, we don't have a Nobel Prize.
Is the touring award.
And part of it was for his really famous book.
The mythical man one and soft engineering said.
Plan to drill one away and you will any how.
So you try to build that first one and the customers don't like it.
Or you figure out what's wrong with it.
You can throw it away.
So that's what kinda happens in the waterfall model.
So, another, famous person.
So they, but they say it's kind of inevitable.
Well, if you right the specs and you build it, they're
not gonna like it.
So what are we gonna do?
We gonna train customers?
What are we gonna do?
So, this is [inaudible] Perez, not, somebody not often quoted in, maybe
in this building, but not in this, class.
He's, he's got this wisdom [inaudible] on.
He said, look, if a problem has no solution, you can't think of it as a
problem, right?
If it's a problem, problems, you know, we're problem solvers.
It's problem, we've gotta solve it.
They said, if it has no solution, it's not
really a problem, but it's a fact.
Not to be solved, to be coped with.
So there's times when things look like problems that
are really just facts that you gotta come up with a solution that doesn't change
that assumption.
So we can't, customers being unhappy with the requirements, you
figuring out that's a fact of life.
So come up with another idea.
So it turns out, ten years ago, a group of people
frustrated by the big design up front thing, where it wasn't working.
They would build things, and the customers didn't
like it, and it took forever.
They based a manifesto, like Martin Luther nailing, you
know, the manifesto onto the doors of the church.
You know, with the Protestant movement.
This is a movement.
We're going to do things differently, starting now.
This is our claim.
And this slide is actually what they wrote down.
So I'll just read it.
We are uncovering better ways of developing software by doing it
and helping others do it.
Through this work we have come to value, and then
they've got four principles here.
Individual?s interactions over processes and tools.
Working software over comprehensive documentation.
That's a dig against the waterfall model.
Customer collaboration over contract negotiation.
You know, if the customers are going to change their minds, let's work with the
customers.
Let's not make it, well you can't change it.
The contract says that you can't change it, right?
We're gonna work with the customer.
Responding to change or are we following a plan?
So, it's not the elaborate planning, it's
gonna be, things have changed, let's respond quickly.
And then their bottom line.
They're not saying the things on the right are valueless.
Just as while their audit, why we value the things on the
right, we value the items on the left more.
So, individuals and interactions, working software, customer collaborations,
respond to changes, that's going to be the things we value not that waterfall, or big
[inaudible] upfront model.
So this agile lifecycle embraces this change as fact of
life.
Continuous improvement you're, you're going through these repeatedly
rather these big changes here, big phases.
So you're continuously finding a working but in completing prototype until the
customer's happy with customer feedback on every iteration.
I'll show you what iteration looks like.
In the real world it's probably every two weeks.
In this class you're going to get a chance to do
this iteration a lot.
We're going to make it one week iterations.
We think the more iterations you do, the more you're going
to learn and understand the process.
And it is a [inaudible] and you hear a lot
about this [inaudible] test driven development.
You write the test before you write the code.
[inaudible] user stories that is you're gonna, we're gonna talk
about user stories later in the semester.
But basically you talk to the customer, the customer and you say what do you want
to happen with this software.
And that is going to be the requirement and a thing
called velocity where you measure how fast your team completes user stories.
And so you're gonna self monitor that's, that's
going to be the principles.
If we go to this is the tool flow, this is the flow of
the agile, this is one iteration that actually maps on to the chapters of the
book, and, and you'll see this when, when you get the book.
So, you start off talking to the customer.
We're gonna split this test-driven development into two
phases.
The first phase is behavior [inaudible] design and test-driven
[inaudible].
Those are Chapters four and five.
Measuring velocity, we deploy it so the customer can see it, talk to the
customer again.
That's fundamentally what the bo-, what the Agile flow is.
You notice, Legacy is over there in Chapter
seven.
Well, it turns out.
The saying behavior [inaudible] design can be used to
enhance legacy.
So the same technique you're losing to write [inaudible] code,
code from scratch, you can use to attack a legacy code.
We're excited about that.
Now another big idea in software, is to have
good software architectures.
And one of the criticisms of [inaudible] is maybe you
just start doing this text driven development.
Maybe you don't think about the architecture.
So there will be a chapter that talks about the architecture
and you can be learning about how to do design patterns.
That will come up a lot and you'll be incorporating design
patterns when you're writing code.
But this is not only the, this is the Agile
cycle, this so-called Agile life cycle.
And that's what the course and book is around.
And you'll go around this thing four or five times.