Rapid Application Development Part 2
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Course
Difficulty
Intermediate
Video Transcription
00:00
>> Welcome to lesson 2.2, RAD Part 2.
00:00
I'm your instructor Cane,
00:00
and this is probably
00:00
my favorite lesson of the entire course.
00:00
In this lesson, you will learn about
00:00
Rapid Application Development in its true formalized way.
00:00
We'll talk about the roaring 1990's in the dot-com boom,
00:00
is waterfall actually dead?
00:00
Then we'll discuss a couple of relatively unknown.
00:00
Again, he said sarcastically, rugby programmers,
00:00
and then finally, the Internet weighs
00:00
in on Agile development.
00:00
In 1991, James Martin published
00:00
a book called Rapid Application Development,
00:00
and thus Rapid Application Development is born.
00:00
What he envisioned in that book was a four-phase process.
00:00
You would have a requirements planning phase,
00:00
so that's where you would address
00:00
your high-level requirements,
00:00
not your detailed requirements.
00:00
Then you'd enter into the user design phase.
00:00
Now, notice this is the first time that
00:00
we talk about JAD,
00:00
which people are pretty familiar
00:00
with that acronym if you're in
00:00
the software development business,
00:00
joint application development.
00:00
This is also the first time
00:00
that we're going to talk heavily
00:00
about the user being
00:00
integral in the design phase once you've
00:00
established the general high-level requirements.
00:00
James Martin, when he was writing this book,
00:00
Rapid Application Development,
00:00
his key focus was you have to engage
00:00
the users early on in the process.
00:00
He envisioned engaging the users
00:00
at step Number 2 during the design phase,
00:00
and we'll see as we get further along in
00:00
the Agile development process where we see
00:00
benefits for including the users even earlier than that.
00:00
James was the one who pioneered the JAD concept,
00:00
getting those users and
00:00
those business owners in
00:00
the room with the technical people.
00:00
That way, they could tell you about
00:00
how the business does business,
00:00
and the technical folks could be there to
00:00
watch that for lack of better expression,
00:00
sausage being made a little bit
00:00
before they move into the construction phase.
00:00
We're now starting to see a little
00:00
bit more of that ready fire aim,
00:00
where we think we're ready to go,
00:00
let's see what happens.
00:00
Let's adjust our fire
00:00
accordingly in the user design phase.
00:00
Then he would go into construction phase,
00:00
the customer and the users remain
00:00
involved throughout the construction phase.
00:00
There's a lot of iteration.
00:00
But again, our iterations
00:00
will hopefully be faster and smaller because
00:00
we had those same core users in
00:00
the design phase during Rapid Application Development.
00:00
Once you did your construction phase,
00:00
you'd have your user acceptance testing and training.
00:00
All those things would happen
00:00
in some ways at the same time.
00:00
Because if your testers are testing your beta product,
00:00
or they're demoing it,
00:00
or they're doing both of those things,
00:00
then once the construction is done,
00:00
in theory, your user base,
00:00
or at least a lot of them,
00:00
were well trained on the new software.
00:00
Then the final phase would be
00:00
the cutover phase when they would actually move
00:00
the software from some development
00:00
and testing platform into production.
00:00
This is way back in 1991.
00:00
Now my decade, the 1990s,
00:00
they must be showing my age a little bit.
00:00
Is waterfall dead?
00:00
In the 1990s,
00:00
we had a lot of
00:00
really interesting things happening
00:00
throughout the business community.
00:00
For those of you that were around or read history books,
00:00
you might remember that
00:00
the US automotive manufacturers and
00:00
the Japanese automotive manufacturers were in
00:00
a fierce competition for
00:00
dominance of the US automotive market.
00:00
During that time,
00:00
some very famous business people like Jack Welch from
00:00
GE started to look at how the Japanese were,
00:00
in essence, doing better than we were.
00:00
I don't want to use any course language,
00:00
but they were handling us at hat,
00:00
when it came to automotive quality,
00:00
the space of innovation, all that stuff,
00:00
whereas the US was really the slow, bureaucratic,
00:00
again, waterfall way of designing new vehicles.
00:00
They started studying the Japanese,
00:00
and they saw a couple of things like TQI,
00:00
Total Quality Improvement, Kanban,
00:00
which we'll talk about in regards
00:00
to specific Agile methodologies later on in the course.
00:00
But these were all methods that
00:00
the Japanese had really focused on and
00:00
perfected when it came to manufacturing of, a,
00:00
not tying up a lot of their time
00:00
and money in large inventories,
00:00
they weren't placing bulk orders of
00:00
parts like the US at the time was.
00:00
They were also focused
00:00
on the opposite of a death by 1,0000 cuts.
00:00
They were focused on constantly,
00:00
and training their people to constantly be looking for
00:00
ways to reduce waste, to improve efficiency.
00:00
The concept that they had was
00:00
that perform the activity as it was designed,
00:00
then you measure the essential elements of success,
00:00
you make small commonsense changes,
00:00
you measure again, and it's a cycle, and it's constant.
00:00
It is part of their bread and butter.
00:00
That they're constantly improving,
00:00
and measuring all that stuff.
00:00
Then along came a couple
00:00
of relatively famous rugby programmers,
00:00
Jeff Sutherland and Ken Schwaber.
00:00
They developed a process that they
00:00
presented in a conference in 1995,
00:00
and they called it the
00:00
Scrum Software Development Process.
00:00
For those of you that have ever been exposed
00:00
to Agile on any of its forms,
00:00
I'm sure you've heard the name Scrum.
00:00
This particular presentation made
00:00
a small possible dent in the Agile methodology.
00:00
Again, I'm being sarcastic.
00:00
They actually revolutionized the idea of Agile.
00:00
We haven't even really called it Agile yet,
00:00
we're still calling it Rapid Application Development.
00:00
But the idea of their Scrum software development process,
00:00
which is where it took
00:00
the Rapid Application Development to the next level,
00:00
the users are involved in everything,
00:00
we're building our two-week sprints,
00:00
we're meeting every day in the morning,
00:00
and we're just putting all of our effort in
00:00
this short little time frame.
00:00
Then we recover, reset,
00:00
and then do it all over again,
00:00
rather than these long drawn-out schedules
00:00
where people would get behind, and so on and so on.
00:00
If you've taken my enterprise project management class,
00:00
you probably remember me saying
00:00
that task completion or project completion,
00:00
whether it's requirements,
00:00
or tasks, or deliverables,
00:00
or whatever, you
00:00
can plan it out for as long as you want.
00:00
You can have a task in
00:00
your project schedule that runs 200 and something days.
00:00
But the task completion is basically a binary thing,
00:00
it's either complete or it's not.
00:00
So the longer your tasks are,
00:00
the longer you draw it out,
00:00
the harder it actually becomes to measure progress,
00:00
because you won't know whether
00:00
that task passed or failed until it runs late.
00:00
If you've got a 200-day task, day 201,
00:00
you find out the person didn't
00:00
actually get a whole lot done,
00:00
now you're 200 days behind.
00:00
With Scrum, the idea was we just ball it all up,
00:00
just like a Scrum and rugby,
00:00
and we all move the ball together.
00:00
Then we stop and reassess where we were at,
00:00
move the ball together.
00:00
We're really taking Rapid Application Development
00:00
and moving it to the next level.
00:00
Then a little thing called the Internet came about.
00:00
Rapid Application Development,
00:00
Iterative Programming, Scrum,
00:00
all of these things were really part
00:00
of the birth of the client-server software.
00:00
The idea that you had a centralized database,
00:00
centralized server that everybody
00:00
could connect to remotely and they
00:00
would have software on
00:00
their computer that they could then use to work.
00:00
Well, the release schedule for that,
00:00
as you can imagine,
00:00
is a little bit complicated.
00:00
Because even if I'm updating
00:00
just the server side of it and
00:00
there's no changes to the user experience,
00:00
sure, I can do those anytime
00:00
the user never knows about them.
00:00
But in order for me to deploy new UI,
00:00
to deploy new functionality,
00:00
to deploy new features,
00:00
you had to update the client.
00:00
It wasn't the end of the world,
00:00
but it did add some complexity
00:00
to client-server Rapid Application Development.
00:00
But all of a sudden we had this
00:00
little thing called the Internet.
00:00
The Internet spark the rise of
00:00
web-based applications that are now part of
00:00
the famous dot-com boom because the Internet used to
00:00
be pretty much view only in a lot of ways.
00:00
Then Amazon and all these folks got involved,
00:00
and then the Internet became useful.
00:00
Now, I've got these rapid application prototyping people
00:00
that can deploy working
00:00
software to a production environment.
00:00
Anytime, day or night,
00:00
they can deploy at one time a day,
00:00
once an hour, every five seconds.
00:00
As soon as that cache clears and updates on the browser,
00:00
bam, I see new stuff.
00:00
Prototyping, iterative development,
00:00
Rapid Application Development,
00:00
all this continuous improvement,
00:00
TQI stuff from the manufacturing world,
00:00
all became the cornerstones of
00:00
the new kind of project manager.
00:00
This type of project manager really value ambiguity.
00:00
I don t know what I don't know,
00:00
I'm not going to worry about it,
00:00
we'll deal with that later.
00:00
We have fierce release
00:00
schedules because you want to be the
00:00
first to the market with the
00:00
newest, latest greatest stuff.
00:00
I wasn't so worried about
00:00
detailed requirements gathering because
00:00
I knew change was inevitable.
00:00
Wherever I put out there,
00:00
you are going to find something you
00:00
didn't like or that could be improved,
00:00
so why not make money on something that works
00:00
now and then go back and make it better,
00:00
and constantly be making it better.
00:00
There were several surveys done.
00:00
One of the things that people
00:00
realize in the late '90s is,
00:00
of the total cost of a system, so think Google,
00:00
Amazon, any one of these large-scale websites,
00:00
80 percent of the total cost
00:00
is in maintenance or enhancements.
00:00
It's the long-term cost that you pay
00:00
over time to keep that system up and running.
00:00
Why would we spend all this time planning and
00:00
developing detailed requirements that
00:00
we're going to change anyway,
00:00
just to encompass that 20 percent
00:00
of the initial development effort?
00:00
It didn't make financial sense.
00:00
In today's video, we discussed
00:00
Rapid Application Development,
00:00
talked about the beginning of the end of waterfall,
00:00
potentially, the birth of Scrum,
00:00
and how the Internet changed the game.
00:00
There's a little timeline on
00:00
the right hand side for you where you can really
00:00
start to see just how fast all of this happened.
00:00
Again, thank you for your time and I
00:00
look forward to seeing you in the next lesson.
Up Next
The Agile Manifesto
What was Old is New Again
Scrum
Lean
XP
Similar Content
