Rapid Application Development Part 1

00:00

Hello and welcome to the first lesson of module to

00:05

the history of agile.

00:07

I am your instructor cane, and we will be going through the following four lessons.

00:13

Lesson 2.1 Rapid application development part one.

00:19

Lesson two rapid application development part two.

00:23

Then we will discuss the agile manifesto

00:27

and then conclude with what was old is new again.

00:34

Lesson 2.1 is the first part of the rapid application development or rad.

00:42

In this lesson, you're gonna learn about the early history of rad,

00:46

how it came about from structured system analysis and designed commonly known as waterfall.

00:53

We'll also talk about the important development that the call for prototyping brought about

00:59

as well as look at the spiral model of software development and enhancement.

01:03

And finally, no good history lesson is complete without understanding the impact that the U. S. Federal government had on the agile development methodology.

01:18

So originally in the 19 eighties,

01:22

developers came up with the structured systems analysis and design method, or S s a d. M. We do love our acronyms in information technology.

01:33

So SS ADM was originally released as a methodology or best practices. Something like that in order to try to create a reusable, trainable and repeatable process

01:49

within the UK as part of the Central Computer and Telecommunications Agency. So they were experiencing a lot of the same pain that the U. S. Was experiencing with software development projects. And so they look to develop some sort of structure that they could again repeatable, trainable

02:07

so they could begin to bring this best practice

02:10

into information technology and try to use it to make better software.

02:17

In the case of SS, ADM is basically what we we would commonly look at today as the waterfall method of project management. So you do a feasibility study. Is this something that's even technologically possible?

02:34

Then you investigate the current environment. What are we have? Resource is time, etcetera?

02:39

Can we physically do this once we determine that it's technologically possible?

02:46

What are some of the business system options? What are the requirements and the actual requirements gathering, which we talked about a little bit in the in a previous lesson?

02:57

You have to know what you need to build before you build it.

03:00

Once you develop all of your business requirements, you then start looking at the technical system and the options that are available for you there.

03:09

Then you go through your logical design and then your physical design. So those of you that have experience in software development or have some sort of formal education and software development that should look pretty familiar. So that was from the 19 eighties on word.

03:28

Then a couple of gentlemen wrote a very famous paper

03:31

called Prototyping, The New Paradigm for system development.

03:37

It was released in 1982 and it was designed, or it advocated for the use of prototyping. So if for those of you that are in the military or of ever fired a gun, you may understand the idea of ready aim fire or if you see an old movie with the firing squad

03:55

and the idea is that you do your planning

03:58

in this case, we're talking about shooting, so you get ready to shoot

04:01

you aim the gun where the target is. You see it account for distance and wind and things of that nature.

04:09

And then you finally pull the trigger and fire. So ready aim Fire is the normal methodology used in shooting a firearm.

04:16

While it's also the normal methodology that was used at that time in project management.

04:21

So the idea of the ready fire AIM concept came from the prototyping.

04:28

The idea that let's build something we know it's not gonna be perfect. We know it's It may not even necessarily work exactly the way the customer wants it to work.

04:39

But if we prototype it and then we see what the response is, our next iteration will be much better and closer rather than the traditional waterfall method, which we've already talked about sometimes extend a software project really past the point of relevance once you get it at three year window.

04:59

What are the odds that the person that you're building the software for is even

05:02

still the company in some cases, eso that we're trying to speed up the iterations? And so we were way were advocated

05:13

or people advocated for prototyping, and it was already being used in hardware. It was a part of the Apollo space program, the rapid prototyping of hardware, so the concept wasn't totally foreign to information technology. It just had never been applied to the software part of information technology.

05:34

Then, in 1986 Barry Bone published the first True Rapid Application Development model, although it wasn't necessarily called rapid application development at the time. On this was the spiral model of software development and enhancement. So if you look at the picture on the right,

05:54

you started to see this prototyping and this rapid application starting to blend a little bit

06:00

in the late 19 eighties. So you develop a concept of your requirements in lieu of detailed requirements. Documentation. So we think we know what you want. Let's go build something real quick, bring it back to you

06:15

and then look at it and say Okay, yes, this is what I wanted. But this part is not what I wanted. So we can get a better idea of where the customer's needs were.

06:24

Do a verification and validation exercise. After you verify the requirements,

06:29

come up with a new plan.

06:30

Go to in a prototype number two Brinson Repeat hopefully, in the in the case of ah, the spiral model only one or two times,

06:41

and then you would actually build it

06:43

and then do your detailed design documents, test it to your user testing and implemented. So this was much, much faster than the existing, even rapid or even prototyping was a little bit slower than this, So we're starting to try and speed it up. But I want you to notice here when you look at the detail design

07:02

code, integration tests and implement

07:05

that last phase

07:09

is still kind of mirrors the waterfall methodology that was used in like SS ADM. So that last phase still meant that detailed requirements were happening. We weren't actually doing detail coating yet, and then we definitely weren't doing testing an implementation

07:28

up until the very end of the spiral development enhancement model. So it was faster,

07:34

but it wasn't quite fast enough. And there's a couple of reason why that is, which we'll get into in some of the later lessons. And finally, Uncle Sam always puts his finger on the scale A little bit. Eso In the 19 eighties and nineties, this largest organization

07:51

that was doing software development in the entire world

07:55

was Uncle Sam, the U. S. Government.

07:59

And because the U. S government is a course regulation intensive, the Department of Defense actually had a specific software development model called D o D Standard 2167 it clearly favored the waterfall model over

08:15

any other model. So the idea is, if the largest vendor

08:20

developing software has co defied the use of the waterfall model, which they again they got from in some no small part based on the Apollo moon program,

08:31

then

08:33

that's going to be what you train your individuals on. It's gonna be what they're familiar with and used to. So as a industry information technology was still very waterfall heavy all the way up until the late 19 nineties.

08:52

So in summary, we talked about the early history of rapid application development. We discussed SS ADM prototyping and how that became a game changer for the software folks that we stole it from the hardware folks a little bit.

09:07

We talked about the spiral model and how it aeration started to become a common theme in all nonmilitary non department defense software programs. And then finally, we saw how the government sort of

09:20

in some cases actually hindered the progress of agile because they were the biggest vendor. It wasn't really until the mid to late nineties, where we had some other big players, which we'll talk about here shortly that that began to change and change in a very, very quickly