Information Technology Reference
In-Depth Information
Software validation is used to establish that software requirement
specifications conform to user needs and intended uses. In practice,
software validation activities may occur both during, and at the end of
the software development life cycle, to ensure that all requirements have
been fulfilled. A conclusion that software is validated also can depend on
comprehensive functional testing of various user scenarios.
Software verification provides objective evidence that the outputs of a
particular phase of the software life cycle meet all the specified require-
ments for that phase. Software verification looks for consistency, com-
pleteness, and correctness of the software and its supporting
documentation. Structural software testing (path, code, and statement
coverage) is one of the many verification techniques intended to confirm
that software development output meets its input requirements. Other
verification techniques include detailed analyses, and code and document
walk-throughs.
In terms of computer science theory, one validates a program's cor-
rectness by testing it against a set of inputs that one has analyzed as
plausible in the real world, for which the program has been written.
Program verification for correctness, on the other hand, sometimes uses
theoretical proof techniques to establish that the program does exactly
what it is supposed to do. As difficult as the latter may be, it can be made
more complex (impossible to solve) if one tries to prove that the program
has no incorrect behavior in it.
Validation can refer to points outside the software itself. Many a product
has failed in the marketplace because its requirements were never vali-
dated against market needs. This brings us to an important aspect of
validation: what should the validation be against? Market validation can
perhaps be obtained through early prototypes before creating production
versions. Frequent validation of assumptions, objectives, and progress is
essential in any development project. Setting up these validation points
correctly is a project management responsibility and should be undertaken
with care.
Asynchronous versus Synchronous
If two known events happen at the same predetermined rate, they are
called
synchronous
. If they happen at the same “time,” they are called
. The operative words are “known” and “rate.” “Known” implies
that it is important that the events be predestined to happen. Automobile
accidents in Los Angeles and those in Washington, D.C., may happen at
the same rate but cannot be called synchronous. “Rate” introduces the
notion of time — the events should occur together or with a predetermined
concurrent
