Software is quickly becoming integral part of human life as we see more and more automation and technical advancements. Just like we expect car to work all the time and can't afford to break or reboot unexpectedly, software industry needs to continue to learn better way to build software if it were to become integral part of human life. In this course, you will get an overview of how software teams work? What processes they use? What are some of the industry standard methodologies? What are pros and cons of each? You will learn enough to have meaningful conversation around software development processes. After completing this course, a learner will be able to 1) Apply core software engineering practices at conceptual level for a given problem. 2) Compare and contrast traditional, agile, and lean development methodologies at high level. These include Waterfall, Rational Unified Process, V model, Incremental, Spiral models and overview of agile mindset 3) Propose a methodology best suited for a given situation
Incremental Models
Loading...
來自 University of Minnesota 的課程
Software Development Processes and Methodologies
238 個評分
從本節課中
Software Development Models: Traditional Models
In this module we will learn about various traditional models like waterfall, RUP, Incremental, and Spiral models.
與講師見面
Praveen MittalAdjunct Professor
College of Science and Engineering
Kevin WendtTeaching Specialist
Department of Computer Science and Engineering
[MUSIC]
Hi, as we begin talking about testing and
its place in the software development life cycle, let's define some terms.
The most important words in software testing come as this pair,
Verification & Validation.
But before we get to our definition and give you that,
let's look at how they're defined in a few places from around the industry.
This is the definition from IEEE.
It's a bit of a troublesome definition,
I'll give you a chance to go ahead and read it.
So the issue is that it's pretty generic.
The idea that it satisfies conditions imposed versus satisfying specified
requirements.
It doesn't really tell you a whole lot until you understand what those
words mean.
When it comes to satisfying conditions imposed,
what we mean by that is that the conditions imposed on the system,
by the developers as we try and transition from what the user wants,
the requirements, into what the system does in order to meet those requirements.
So those are the conditions imposed, whatever we have the system actually do.
Validation then is whether it satisfies the specified requirements.
And they're being a little bit loose with the definition here of the word specified.
So the way we interpret that definition means that it is specified as in told,
explained by the users, it's what the users really want.
So the requirements are not necessarily a written-down document that we would
really like it to be, but it's what the user wants.
So whether it satisfies what the user said they wanted,
that's essentially what validation is.
But we're actually not going to just trust that definition,
we're going to expand it out just a little bit.
So here's another set of definitions.
Professor Kaner produced what was at one time the best selling book on testing,
and here's how he defines these terms.
So when they talk about most closely related design documents or
specifications they're talking specifically about what we wrote down that
we said the system will do versus again validation.
Checking it against the published user or system requirements,
the requirements of the system, in the user language.
So this gets a little bit closer to what we tend to think of as verification and
validation, but again it really focuses on design documents and
specification versus requirements for the validation step.
One more definition, another bigger names in testing is Glenford Myers.
In his book he defines the terms this way.
This covers testing to be sure, and actually does a pretty good job of
explaining the difference between verification and validation for testing.
An attempt to find errors by accident program in a test environment
versus Executing it in the real environment.
Now, we would tend to look at this definition as of a little bit
too narrow scope.
Validation is still executing the real environment, but
doesn't necessarily include the user.
And we think that the user is a key component to validation, it being valid.
So here is the correct definition, or well, our definition.
The way we consider verification and validation is like this.
Verification means that it conforms and
performs to its specification, what we wrote down as it will do this.
This is essentially our definition of if it does these things it meets the user
requirements.
Now there's a big transition there between what the user wants and
what we said we're going to do.
So there is some room for error in there but we have to write down what we want so
that we can give it to the developers, the designers, the architects, and
they actually build the system.
So we write that down, and
then we verify that what we built matches what we set out to build.
Are we building the thing right?
According to what we wanted to build, that's verification.
Validation, then, is that it conforms to the user satisfaction,
it's what they wanted.
And it's what they need, which are not necessarily the same thing.
What they say they want, what they say they need, and what they actually want and
need can oftentimes be different things.
So, we have to actually validate on two different levels.
It's, this is what they need, watching them use this supposed solution,
make sure it works the way that we think it will.
And they are actually satisfied with the way it provides what they asked for.
So, it's essentially are we building the right thing?
Not just, did we do what we wanted to do, but does that thing that we built right,
supposedly, actually do good things.
Is it actually good for my usability perspective?
Is it good from a security perspective?
Is it good just in a pure user satisfaction level?
That's validation.
We do this through a couple of different things.
Dynamic and State verification.
So, Dynamic Validation and Verification or V & V.
Dynamic V & V is exercising and observing product behavior.
It's actually running the thing and seeing what happens.
So that's why we call it dynamic, it's running the system.
So that's basically testing, all forms of testing.
So when you go back to the Myers definition,
this is really what we're looking at.
So when Myers does a definition of verification and validation,
he's talking specifically about dynamic verification and validation.
Running the system and seeing what happens.
So from that perspective, his definition is quite good.
Between running the testing environment and running in the real environment.
But there's also Static V & V.
Static V & V is really all about looking at established representations of
the solution that aren't necessarily running the system.
So this could be looking at code in terms of a code inspection, a code review, or
even pair programming that you will see in a lot of agile methodologies.
All of that where anyone else is looking at the code and
seeing things right without running it, that's static V & V.
It's also formal proofs or model checking.
So if we went through and actually did a theorem based proof,
mathematical type of proof for solutions of code and prove that is going to work,
prove that is secure that would be considered a static V & V method.
And you see a lot of that in formal verification, formal testing,
you see a lot of that in terms of security based testing or
also this static DMV not necessarily dynamic DMV.
Which in a security standpoint would be something like penetration testing,
trying to get in the system when is actually running.
So when it comes to verification and validation we really care about is
building the thing right and building the right thing.
In order to do that we have to employ a lot of different testing methods.
So, we're going to talk about all the different methods and
tools that we can use to provide verification and validation.
This is both true for Dynamic and Static V & V.
The thing to remember though is that verification is a lot easier and
therefore it's cheaper.
When we have a standard, this is what we are going to build,
we can verify relatively easily, did we build that?
It's a much harder thing and much more expensive thing to prove that
what we built, actually makes the user want to buy it.
