-: Software development models.
So, when we talk about the software development models,
there's lots of different models that exist.
We talked about the basic eight phases
that pretty much all these models are gonna go through.
But, each of these models we're gonna talk about
in this lecture are gonna provide you a
common framework to use.
You can use very formalized models,
very rapid models, or very ad hoc models.
Each one is gonna provide you some detailed
practices, procedures, and documentations.
But again, there are some that are just
very ad hoc and very haphazard and very low formality,
as you're gonna see as we go through this lecture.
Starting with one of the most formal methods,
we have what's called the Waterfall method.
And this is a very linear model.
Each phase starts and end before the
next phase starts and ends.
And so you can see, we start with requirements,
and then that feeds into design,
and then that feeds into implementation,
and then into verification and into maintenance.
And so we kind of go through all of those
eight phases, 'cause there's that planning
from the beginning, and there's some coding
that's the implementation and design.
And as we go through, each one is gonna feed the next phase.
It just kind of drips down like a Waterfall.
The next one we're gonna talk about here is Spiral.
Now, Spiral is an adaption of the Waterfall method.
It's gonna add an iterative process
that revisits the phases over and over and over again.
So, you can see we start in the middle
of this Spiral and as we Spiral out,
we get the first prototype done.
And then we Spiral and get the next prototype.
And then we go out and we get an operational prototype.
And so we're biting off a little less than the whole thing.
So with Waterfall, we want to get the entire
project done in one iteration as we go down the Waterfall.
But in a Spiral, we're gonna get a piece of it done,
and then another piece and add some features,
and then another piece and add some features.
And so we just keep Spiraling around.
So the good thing about Spiral over Waterfall
is it is a little bit faster.
We can get the minimum viable product out
and then we can add some features,
and then add some features, and add some features.
And keep going around, right?
That's the benefit of the Spiral model.
It's still a very formalized method
and it still does take quite a bit of time, though.
So that led us to Agile.
And you probably have heard of Agile out there.
It is a very, very popular topic right now.
Agile is an iterative and incremental process.
So, it's more of a modification on Spiral,
but in very, very quick verse.
So what you're gonna see in Agile is
that there's four foundations.
What we're looking at is that individuals
and interactions are much more important
than formal design processes.
So in Spiral we're gonna get all of the processes down,
we're gonna design them fully,
and then we're gonna code them all perfectly.
Agile, we don't really care about that.
We care about getting things done.
Working software is better than having good documentation.
And getting something out
is better than getting nothing out.
Those are kind of some of the concepts here in Agile.
And then there's also this idea that customer
collaboration is more important than contract negotiation.
Now what do I mean by that?
Well in Waterfall or Spiral,
you get very defined deliverables.
You could say, "I'm gonna build you an accounting
"software that does X, Y, Z".
Right?
Now with Agile, we like to start getting
into the development and then as we go along
working with the customer, we go,
oh you know what, we actually need this as well.
And you'll say, "Okay,"
and you'll start building that.
Right, and so the way you do contracting
with Agile is much different than a Spiral or a Waterfall.
And then you have responding to changes.
Agile is very good about responding to changes fast
and it is much better, in their opinion,
than having a solid plan.
With Waterfall or Spiral,
I might have a development plan over the next two years
and we're gonna stick to that plan as we go along.
With Agile, we can start making turns
and changes as much as we need along the development,
based on the feedback we start seeing from the market.
For example, in my accounting software example,
let's say I go back to QuickBooks, back in the 90s.
There was a function to print out checks.
Do many people print out checks nowadays?
Well, no.
But let's say we are building that software,
and we said, "Hey, we need to be able to print out checks."
And then about halfway through the development
we figured out, you know what nobody cares
about checks anymore, they care about taking
credit cards and getting ACH transfers
and all these electronic means.
Well, we can turn in Agile and start building
those features in very quickly.
But with Spiral and Waterfall,
we go back to negotiating a new contract
with our customer of how we're gonna develop it.
And so you'll see here in Agile,
there's all these little circles that go on
what we call sprints.
Now there's a bunch of different terms
we're gonna talk about here in Agile.
There's backlogs and backlogs are just a list
of features or tasks to complete.
If you've ever walked into a software
development team that uses Agile,
you'll see these Post-it notes all over the
board, essentially, right?
And each of those Post-it notes is
one of the features that the end customer
wants in the product.
Now, when we start building those,
what we're gonna do is each of those
is gonna get assigned an amount of time.
So, this user input function may take
me an hour and a half to code.
This being able to print a check function
might take me three hours to code.
And each of these functions is assigned a time.
That's called what's called the planning poker.
And this is where we start doing estimation
of the time it's gonna take to build the
whole product by adding each of
these components a certain amount of time.
And then we all sit around a table and we say,
"What's the five most important things
"we need to do in this cycle,
"in this 30 days of coding?"
Well in this 30 days, we want to be
able to get these five functions done.
And so we grab all of those functions,
we figure out how much time it's gonna take
and we start working on those.
And then if we say, "Well I still got another
"10 hours of coding we can do,"
then we might pull one or two more
functions and add them in.
That's that planning poker.
The next one is timeboxing.
And everyone here is gonna agree upon
the time that's required to work on a specific goal.
Every function is assigned a time period,
like I said, this code might take me 90 minutes,
that one might take me 45.
We start adding all those together.
User stories.
User stories are basically a description
of high-level requirements,
but they're not necessarily as specific
as a requirement would be in Waterfall or Spiral,
because in those you might say "I want a user
"input field and I want it to be able to accept
"anything up to 50 characters,
"and it should do blank, blank, and blank."
As a user story, it's more important about
that customer interaction and collaboration, right?
So I'll go to the end customer, whose not a programmer,
and say, "Tell me about this feature you want."
Well I wanna be able to print out checks,
and when it prints out the checks,
I think it should be able to print out
any check from zero to 5,000 dollars
and it should already have the signature on it.
If it's over $5,000, I wanna hand sign it, right?
That's a story.
And then you can turn those into real requirements
and then you can start coding to them.
Velocity tracking, this is an important one in Agile.
So we talked about there's a 30 day sprint
or a 15 day sprint, or however long you're gonna do
each of these cycles or Spirals,
as you're talking about in Agile.
Now, with the velocity tracking,
we're gonna figure out are we on time or not?
So as we figured out, we have five different functions
we're gonna build in this next 15 days.
Each of those functions are gonna take
a different amount of time.
One might take six hours, one might take an hour.
As we've all said in our planning poker
how much we think it's gonna take,
well velocity tracking sees if we
actually met that expectation.
So after I've coded the function for printing checks,
which I said would take three hours,
they'll go back and look and go, oh,
that took Jason two and a half hours,
we're 30 minutes ahead of schedule, right?
Or, it took Jason three and a half hours,
we're 30 minutes behind schedule.
And if we look across all of our different
functions we're building in this sprint,
the velocity tracker will tell us
are we ahead, are we behind,
do we need to add more resources,
more people, more coding?
Or can we add more functions
'cause we've got extra time.
All of those things are things you have to consider
when you're dealing with Agile.
Now the next one we want to talk about here is RAD,
which is rapid application development.
This again is an iterative process,
it's less formal,
and it's gonna rely on building prototypes.
We wanna get something out into the hands of our users.
This is gonna provide a highly responsive development
environment and is really good for modularized work.
So if I'm building certain functions of a program,
RAD works really well.
If I'm trying to build an entire app,
RAD doesn't work so well.
You're much better using something like Agile,
or going back to something like Waterfall or Spiral,
depending on the size and complexity of your program.
There is no planning phase in here,
they just start coding.
I'm sitting in a cell, I've got three programmers,
I come in and I go, you know what,
I need a function that does blank,
and they just start going at it.
They start banging the keyboard and get me some code.
Now, the problem with RAD is you gotta do
good testing, because there's no planning
and no requirements, you gotta make sure
the users are happy with it
and the security team is happy with it at the end.
Now when we look at RAD, there's a couple of functions
and a couple of terms that we have to understand.
There's business modeling, this is where we focus
on understanding the business process,
because if I don't understand the business process
that's being used, how can I code it into my application?
Right?
There's data modeling.
And data modeling is gonna gather and analyze
data sets and their relationships.
This is gonna tell me, "Okay, the data I'm gonna collect
"is in dollars, it's in cents, it's in yen,
"it's a text content, it's a database,"
whatever that is, we have to understand
the data we're gonna get so we can
start figuring out the relationships
so we can program to it.
Process modeling is where we start taking
those business modeling and data modeling
and make them into flow charts
and the processes that we're gonna code.
Then we go into application generation,
where we convert all those processes into code
and take the data and processes and turn
them into a functional prototype.
And at that point, we test it and if it works,
we turn it over.
When we do the testing, we're focusing
on the inputs and the outputs.
Do we give it what we think it is?
And do we get out what we think we should?
If we are, those interfaces are considered good
and then we push it on into the turnover phase and
move onto the next thing in Rapid,
'cause again, Rapid is all about quick wins,
it's all about getting functions out as quickly as possible.
Now, we started talking about some of those,
we started very formal with Waterfall
and we got less and less formal as we go on.
Well, this is the least formal you can have.
It's called the Big Bang model.
All the coding is based on requirements
and making resources available.
So, for instance, if I had a team of
two or three coders, I might say,
"Hey, here's your budget, here's your computers, go code."
Right?
This does not scale well.
This works best in a single, maybe a two
person coding environment.
So if I'm gonna make my own app for iOS,
or for android, this is a Big Bang model.
I sit down at the keyboard and I start programming it.
But if I'm gonna do this in a company,
something like Windows, would never, you know,
Microsoft could never build Windows in a Big Bang model.
There's no planning, there's no process,
you just sit down and you start coding.
It's pretty hectic, and you're gonna do all the testing
and all the coding yourself,
and it's just not a great way to get secure code.
I'm not a big fan of Big Bang.
The last one we have is V model.
And this goes back to the very formalized process.
This is an adaption of Waterfall,
so you can see on the left side of the screen of this V,
we have the Waterfall going down,
well this also has a Waterfall going back up.
This is gonna pair testing and development phases together.
So every time I develop something, I'm gonna test it.
Before I get out of each phase of the Waterfall,
I have to do testing and get myself up.
So we have the concept of operations, that's our planning.
We go into our requirements,
we go into our design, then we go into
our test and verification.
We keep validating all those things
and once we do, we can then get it out into operations.
Every piece of the V is tested,
going from each and every piece of that model.
Very structured, very costly, very time consuming.
But, you can get very good product
out of it on the other side.