Hi, in this video we'll be examining

the V Model of Software Development. V models have been used throughout a

variety of industries to model the work in project definition and test. In this
version of the V model we
examine the high level task involved in developing software
products using this V model. At the beginning we define requirements,
and more specifically user requirements. It's the documented source of knowledge
on what the user wants the system to do. This should be written in
the user's natural language. On the other side is validation. This is the set of
tests that we will use
to confirm that our eventual solution meets those requirements of the user. Another
term you may hear
is acceptance testing. Next comes specification. Specification or system spec is
our recorded understanding of what the system will do in order to
meet the user requirements. And out of specification
comes Verification. Verification is the process of confirming
that a software product performs and conforms to its specification. System testing
is often a term that
is also used to describe this step. Then we have architecture or
architectural design. Architectural decisions
can include whether or not to buy the product
rather than build it. Should we build it as a client server
application, or as having some single shared hub of interaction and information,
known as blackboard architecture? Do we have the people,
the expertise, and the resources, to accomplish the goal that we're
trying to set out to build? And how will this fit into the enterprise
software system already in place? A large part of this architectural
step is decomposing sub systems and components that'll eventually collaborate
to serve as the entire solution. System and
specifically system integration testing. System integration testing
evaluates how various components or subsystems are going to work together. Then we
have design, or detail design. Once we have a set of sub systems and
components to work on, the detail design phase, task the team
with organizing those modules and class designs for the solution. This is
characterized primarily by
drawing class and sequence diagrams for your implementation. We still don't include
language
specific design at this stage. But we do solve the problem to a point
that the design can be handed off to implementing developers. Out of design, comes
module testing,
and module integration testing. This is essentially how you test
the design module's functionality, before it's included into
the larger component or subsystems. Implementation, Implementation is
the actual coding of the solution. Programmers, under the guidance of your
provided design, create a functioning program that will serve as the solution
for the product you're trying to build. And out of implementation
you get unit tests. Unit test is what the developers run against
their codes to make sure it works. This is usually at the function and
method level. Each step along the implementation side,
the implementation side of the V, should create tests and
confirm that those steps are actually met along the testing side of our V model. So
you'll notice that the pairs exist. For requirements there's validation,
for specification there's verification. For architecture there's system
integration testing, for design there's module. And for implementation or
code level design there's unit testing. So, the V Model is a model of software
development which pairs phases. Each phase on the left hand side
generates test planning for the accompanying phase
on the right hand side. Now, there is some criticism for
this model. It is relatively simple, but it does have a place in any modern
software development process. Agile methodologies for example,
use very many, many Vs. Small Vs very often, and
include testing at every phase. This isn't to say that you don't
test throughout the entire process. It's just that in the early design, you end up
building tests that will
be used in the final testing phases.