Verification & validation

Verification & validationPresented by: jasmine & Hitesh5/5/201514MC009ContentsGeneral Intro to V & VVerification activitiesVerification of requirements Verification of HL design Verification of data design Verification of architectural designVerification of UI design Verification of LL design Intro to validation activities. 5/5/201514MC009Why is v & v necessary The designers and implementers ofcomputerbased systems are human

They will make errors.

These errors will result in undetected faults in delivered systems.

Faults can result in dangerous failures causing loss oflife, financial loss or property damage.

The mission of V&V is therefore to find and correct errors as early as possible in the development life cycle thus preventing the delivery of a faulty product to a customer.5/5/201514MC009

How Much V&V is Required?

The level of effort applied to V&V is a function of the criticality of the software or systems product.

That is, the risksinvolved if the system fails.

At one end of the scale the software controlling the shutdown of a nuclear reactor will likely be thoroughly verified and validated by an independent organisation.

At the other end of the scale, a website providing a company brochure will likely have no formal verification and validation applied5/5/201514MC009

What Do V&V People Do?

V&V is carried out in parallel with the software/system development process.

V&V activities includetraceability analysis, evaluation, review, inspection, assessment, and testing.5/5/201514MC009 Validation:

Are we building the right system?

Does our problem statement accurately capture the real problem?

Did we account for the needs of all the stakeholders?

Verification:

Are we building the system right?Does our design meet the spec?Does our implementation meet the spec?Does the delivered system do what we said it would do?Are our requirements models consistent with one another?

5/5/201514MC009Verification & validation It is a whole life--cycle process cycle process -- V & V must be applied at each stage in V & V must be applied at each stage in the software process. the software process.

Has two principal objectivesThe discovery of defects in a system; The assessment of whether or not the system is useful and useable in an operational situation. 5/5/201514MC009Verification & validation Verification and validation should establish confidence that the software is software is fit for purpose.

This does NOT mean completely free of defects.

Rather, it must be good enough for its intended use and the type of use will determine the degree of confidence that is needed. 5/5/201514MC009GOALS OF VERIFICATION EVERYTHING MUST BE VERIFIES: In principle, all the products of these processes must be verified

RESULTS OF VERIFICATION MAY NOT BE BINARY

EVEN IMPLICIT QUALITIES MUST BE VERIFIED: the qualities desired in the software are explicitly stated in the SRS. but those requirements which are implicit and not mentioned anywhere must also be verified.

5/5/201514MC009 V testingStartDevelopmentStart TestingTested SystemDefine specificationsCheck specificationsdesigncodingintegrateImplementationverificationvalidationSystem test Unit test Check design

Testing 5/5/201514MC009 about V- diagram Testing can be implemented in the same flow as for the SDLCTesting can be broadly planned in two activities, verification & validation Testing must be performed at every step of SDLCV- diagram supports the concept of early testing V- diagram supports parallelism in the activities of developer & testersTesters should be involved in the development process 5/5/201514MC009Verification & validation activitiesSDLC PHASES End userRequirement gathering RequirementSpecificationFunctional design, high level design(HLD)Coding5/5/201514MC009V & v ACTIVITIES V & V activities can be understood in the form of a diagram as shown beforeFor this, first we need to understand SDLC phases.After this V & V activities in those SDLC phases will be described.Requirement Gathering- the need of the user are gathered and translated into a written set of requirements.Requirement specifications-all the user requirement are specified in developers terminology and are prepared in the form of a document- SRS 5/5/201514MC0093. Functional design or High level design- Process of translating user requirements into a set of external interfaces.The HL design is prepared with SRS In HLD the software system architecture is prepared and broken into independent modules HLD document cannot be given to a programmer for coding as it provides macro level details. 4. Internal design or low level design Analyst prepares micro level design document This doc design each and every module 5. Coding If a LLD document is prepared for every module than it is easy to code the module

5/5/201514MC009End user Requirement gathering Requirement specificationHigh level design Low level design Coding Build acceptance test plan Acceptance testing Build system test plan Build function test planBuild unit test plan System testing Function/integration testing Unit validation testing Installation testing V & V Diagram VALIDATION

VERIFICATION

5/5/201514MC009Verification activities The following verification activities have been identified : Verification of requirements & objectives Verification of high level design Verification of low level design Verification of coding (unit verification)5/5/201514MC009Requirements Validation

Check that the right product is being built

Ensures that the software being developed (or changed) will satisfy its stakeholders

Checks the software requirements specification against stakeholders goals and requirements

Requirements Verification

Check that product is being built right

Ensures that each step followed in the process of building the software yields the right products

Checks consistency of the software requirements specification and other software development products (design, implementation, ...) against the specification

5/5/201514MC009How to verify requirements & objectives ?Requirements & objectives have high potential of detecting bugs : requirements must be verified Testers use SRS for verification of objectives SRS can be verified if and only if. Every requirement stated herein can be verified Requirement can be verified if & only if there is some procedure to check that the software meet its requirement 5/5/201514MC009Following are the Points against which every requirement in SRS should be verified:

CORRECTNESS UNAMBIUOUS CONSISTENT COMPLETENESS UPDATION TRACEABILITY BACKWARD TRACEABILITY FORWARD TRACEABILITY

5/5/201514MC009Verification of high level design All the requirements mentioned in the SRS document are addressed in this phase & work in the direction of designing the solution.

The architecture & design is documented in another document called the software design document(SDD)

Like the verification of requirements the tester is responsible for two parallel activities in this phase as well:

The tester verifies the high level design. Since the system has been decomposed in a number of sub-systems or components, the tester should verify the functionality of these components. The tester verifies all the components and their interfaces are in tune with requirements of the user

5/5/201514MC009 The tester also prepares a function test plan which is based on the SRS. This plan will be referenced at the time of function testing.

The tester also prepares an integration test plan which will be referred at the time of integration testing. 5/5/201514MC009How to verify high level designHigh level design takes the second place in SDLC, wherein there is a high probability of finding bugs.

HLD must be verified as a next step in early testing. unless the design is specified in a formal way, design cannot be verified. If a bug goes undetected in the high level design phase, then its cost of fixing increases with every phase. Therefore, verification for high level design must be done very carefully. 5/5/201514MC009High level design is divided into three parts: Data design It creates a model of data or information that is represented at high level of abstraction.The structure of data has always been an important part of software design At the program component level the design of data structure and the associated algorithms required to manipulate them is essential to create high quality application.5/5/201514MC009Architectural design

The phase of the design ofcomputer architectureandsoftware architecturecan also be referred to as high-level design.

The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of eachmodule,theirinterfacerelationships,dependencies,databasetables, architecture diagrams, technology details etc. The integration testing design is carried out in the particular phase.

It focuses on the representation of the structure of software components, their properties and interactions.

5/5/201514MC009Interface design

It creates an effective communication medium between the interface of different software modules , interfaces between the software system and any other external entity and interfaces between a user and the software system.

5/5/201514MC009VERFICATION OF DATA DESIGN

Points considered for this verification are as follows:Check whether the sizes of data structure have been estimated appropriately.Check the provisions of overflow in a data structure. Check the consistency of data formats with the requirements. Check whether data usage is consistent with its declaration. Check the relationship among data objects in data dictionary.Check the consistency of data warehouses with the requirements specified in SRS.5/5/201514MC009VERIFICATION OF ARCHOTECTURAL DESIGNPoints considered for this verification are as follows:Check that every functional requirement in the SRS has been take care of in this design.Check whether all exceptions handling conditions have been taken care of.Verify the process of transition mapping and transaction mapping, used for the transition from requirement model to architectural designCheck the inter-dependance and interface between the modules.5/5/201514MC009It takes patience to listen It takes skill to pretend youre listening

5/5/201514MC009