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 *

Already have an account? Sign In »

3 hours 55 minutes
Video Transcription
come to a lesson. 2.2
Rad Part two.
I'm your instructor, Kane, and this is probably my favorite lesson of the entire course,
and this lesson you will learn about rap lap rapid application development in its true, formalized way.
We'll talk about the roaring 19 nineties in the dot com boom. Is waterfall actually dead?
They will discuss a couple of relatively unknown again, he said sarcastically. Rugby programmers And then finally, the Internet weighs in on agile development.
So in 1991 James Martin published a book called Rapid Application Development and thus rapid Application Development Is Born.
What he envisioned in that book was a four phase process. You would have a requirements planning phase, so that's where you would address your high level requirements, not your detailed requirements.
Then you'd enter into the user design phase. Now notice. This is the first time that we talk about
Dad, which people are pretty familiar with that acronym if you're in the software development business Joint application development, and this is also the first time that we're gonna talk heavily about the user
being interval in the design phase. Once you established
the General High level requirements.
So James Martin, when he was writing this book Rapid Application Development, his key focus was You have to engage the user's early on In the process.
He envisioned engaging the users at Step number two during the design phase,
and we'll see as we get further along in the agile development process where we you see benefits for including the users even earlier than that.
So James was the one who sort of pioneered the JAG concept, getting those users and those business, those business owners in the room with the technical people. That way they could tell you about how the business does business,
and the technical folks could be there to watch that for lack of better expression sausage being made a little bit
before they move into the construction phase. So we're now starting to see a little bit mawr of that Ready, fire, aim where we're going. We think we're ready to go. Let's see what happens. Okay, let's adjust our fire accordingly in the user design phase,
Then you would go into construction phase. The customer and the users remain involved throughout the construction phase. There's a lot of federation, but again our iterations will hopefully be faster and smaller because we had those same core users in the design phase during rapid application development.
Once you did your construction phase, you'd have your user acceptance, testing and training. All those things would happen sort of
in some ways at the same time, because if you're testers air testing, your beta product or your or their demo ing in or they're doing both of those things,
then once the construction is done in theory, your user base or at least a lot of them, were well trained on the new software, and then the final phase would be the cut over phase when they would actually move the software from some sort of development and testing platform into production.
So this is way back in 1991
and now my decade, the 19 nineties. I must be showing my age a little bit.
So is waterfall dead? Well, in 19 in the 19 nineties, we had a lot of really interesting things happening throughout the business community. For those of you that were around or read history books, you might remember that the U. S. Automotive manufacturers
and the Japanese automotive manufacturers
were in a fierce competition for dominance of the U. S. U s automotive market.
During that time, some very famous business people like Jack Wells from G E, started to look at how the Japanese were,
in essence,
doing better than we were. I don't want to use any coarse language, but they were They were handing us our hat when it came to automotive quality, the space of innovation, all that kind of stuff.
Whereas the US was really the slow, bureaucratic, again waterfall kind of way
of designing new vehicles.
So they started studying the Japanese and they saw a couple things like Teach you I total quality improvement Kon Bon, which we'll talk about it and mawr in regards to specific, agile methodologies later on in the course.
But these were all methods that the Japanese had really focused on and kind of perfected when it came to manufacturing
of a knot, tying up a lot of their time and money in large inventories. They weren't placing bulk orders of parts like the U. S. A. Time Waas, and they were also focused on
it sort of the opposite of a death by 1000 cuts right. They were focused on
constantly and training their people to constantly be looking for ways to reduce waste to improve efficiency. And the concept that they had was, if you that you perform the activity as it was designed, then you measure the essential elements of success.
You make small, common sense changes.
You measure again, and it's a cycle and it's constant. It is part of their bread and butter that they're constantly approving, constantly approving,
improving, I should say,
and measuring all that kind of stuff.
And then along came a couple of
relatively famous rugby programmers, just other Lyndon Ken Schwab er,
and they developed a process that they presented in a conference in 1995 and they called it the Scrum software development process. For those of you that have ever been exposed to agile in any of its forms, I'm sure you've heard the name scrum. This particular presentation made Oh,
a small possible dent
in the agile methodology and again I'm being sarcastic. They actually revolutionized
the idea of agile. We haven't even really called it agile yet we're still calling it rapid application development, but the idea of their scrum software development process, which is where
it took the rapid application development to the next level. The users are involved in everything we're doing. These were building our two weeks. Prints were meeting every day in the morning, and and we're just putting all of our effort in this short little time frame.
Then we recover, reset and then do it all over again
rather than these long, drawn out schedules where people would get behind and so on a throne. If you've been, have you taken my Enterprise Project management class? You probably remember me saying
that task completion or project completion, whether it's requirements or tasks, or deliver balls or whatever,
you can plan it out for as long as you want. You could have a task in your project schedule that runs 200 something days. But the task completion is basically a binary thing. It's either complete or it's not. So the longer you're tasked are, the longer you draw it out, the harder it actually becomes to measure progress because you won't know
whether that task passed or failed
until on runs late. So if you've got a 200 day task Day 201. You find out the person didn't actually get a whole lot done. Now you're 200 days behind with Scrum. The idea was, we just We ball it all up
just like a scrum and rugby, and we and we all move the ball together and then we stop and reassess where rat move the ball together. So we're really taken rapid application development and moving it to the next level.
And then a little thing called the Internet came about
rapid application development, iterative programming scrum. All of these things were really part of the client server, the birth of client server software, the idea that you had a centralized, database centralized server that everybody could connect to remotely. And they would have software on their computer
that they could then use to work well.
The release schedule for that, as you can imagine, is a little bit complicated because
even if I if I'm updating just the server side of it and there's there's no changes to the user experience, Shuriken do those any time. The user never knows about him. But in order for me to deploy new you I to deploy new functionality to deploy new features. You had to update the client.
It wasn't the end of the world, but it did add some complexity to
client server rapid application development. But all of a sudden you have this little thing called the Internet and the Internet sparked the rise of Web based applications that are now part of the famous dot com boom. Because the Internet used to be pretty much of you only in a lot of ways.
And then Amazon, all these folks got involved, and then the Internet became useful.
Well, now I've got these rapid application prototyping people
that can deploy working software to a production environment
any time, day or night. They can deploy at one time a day, once an hour, every five seconds. As soon as that cash clears and updates on the browser. Bam! I see new stuff. So prototyping. Inter development, rapid application development. All this continuous improvement teach you I stuff from the
the manufacturing world.
All became the cornerstones of the new kind of project manager.
This type of project manager really value ambiguity.
I don't know what I don't know. I'm not gonna worry about it. We'll deal with that later. We have fierce release schedules because you want to be the first to the market with the newest latest greatest stuff. I wasn't so worried about detailed requirements gathering
because I knew change was inevitable. Whatever I put out there, you we're gonna find something you didn't like or that could be improved.
So why not make money on something that works now
and then go back and make it better and constantly be making it better?
There were several surveys done, and one of the things that people realize in the late nineties is of the total cost of a system. So think Google Amazon. Any one of these large scale websites,
80% of the total cost is in maintenance or enhancements. It's the long term costs that you pay overtime to keep that system up and running. So why would we spend all this time planning in developing detail requirements that we're going to change anyway?
Justic encompass that 20% of the initial development effort. It didn't make financial sense.
So in today's video, we discuss rapid application development,
talked about the beginning of the end of waterfall, potentially
the birth of scrum and how the Internet changed the game. And there's a little timeline on the right hand side for you, where you can really start to see just how fast all this happened again. Thank you for your time. I look forward to seeing you in the next lesson.
Up Next