4 added 64 characters in body
source | link

Software verification and validation are all the activities that ensure that the software fulfillsfulfils all the needs and requirements for its intended purpose.   As such V&V is part of the larger set of Quality Assurance activities (the latter also include activities to improve the quality, beyond the area of quality control to which V&V belongs)

The best known of these activities is of course testing, which verifies that the software works well, produces the expected results, is usable, and with acceptable performance. Of course this activity can be highly automated, even if usability tests and acceptance tests may require human involvement in near operating conditions.

But testing is not the only verification. Code review for example is another Q&A activity, that verifies if the code is robust, and meets some quality criteria that are expected to facilitate future maintenance. Another kind of verification is related to security. These kind of code reviews might be required to enusre that no undesired stealth behavior was hidden in the software (e.g. spying functions sending data to a foreign country once it is in operation), or that no vulnerability was implanted on purpose.

Nowadays, the V&V should no longer be considered as being necessarily a sequential step in a waterfall-like SDLC. THese activities can be integrated smoothly in the day-to-day activities (e.g. embedded in the definition of done) in agile processes.

Independent V&V is another (expensive) thing. This is often found in the context of mission critical systems (e.g. aircraft systems, factory system in a pharmacological company, etc..) and governement acquisition process. The reason is that team members (or staff members of a supplier) may have unconscious bias, or apply incomplete verification procedures (procedure might even be flawed because of purely economic consideration that are not appropriate for systems on which human lives depend on). This is why an independent team might be required. It is to ensure that V&V is carried out as objectively as possible and with state of the art expertise.

So V&V and IV&V are highly related. It is just that the second must be performed by a different economic operator in view of a proper segregation of duties. Note that in some cases V&V or even independent V&V could be subject of legal requirements.

Software verification and validation are all the activities that ensure that the software fulfills all the needs and requirements for its intended purpose.  

The best known of these activities is of course testing, which verifies that the software works well, produces the expected results, is usable, and with acceptable performance. Of course this activity can be highly automated, even if usability tests and acceptance tests may require human involvement in near operating conditions.

But testing is not the only verification. Code review for example is another Q&A activity, that verifies if the code is robust, and meets some quality criteria that are expected to facilitate future maintenance. Another kind of verification is related to security. These kind of code reviews might be required to enusre that no undesired stealth behavior was hidden in the software (e.g. spying functions sending data to a foreign country once it is in operation), or that no vulnerability was implanted on purpose.

Nowadays, the V&V should no longer be considered as being necessarily a sequential step in a waterfall-like SDLC. THese activities can be integrated smoothly in the day-to-day activities (e.g. embedded in the definition of done) in agile processes.

Independent V&V is another (expensive) thing. This is often found in the context of mission critical systems (e.g. aircraft systems, factory system in a pharmacological company, etc..) and governement acquisition process. The reason is that team members (or staff members of a supplier) may have unconscious bias, or apply incomplete verification procedures (procedure might even be flawed because of purely economic consideration that are not appropriate for systems on which human lives depend on). This is why an independent team might be required. It is to ensure that V&V is carried out as objectively as possible and with state of the art expertise.

So V&V and IV&V are highly related. It is just that the second must be performed by a different economic operator in view of a proper segregation of duties. Note that in some cases V&V or even independent V&V could be subject of legal requirements.

Software verification and validation are all the activities that ensure that the software fulfils all the needs and requirements for its intended purpose. As such V&V is part of the larger set of Quality Assurance activities (the latter also include activities to improve the quality, beyond the area of quality control to which V&V belongs)

The best known of these activities is of course testing, which verifies that the software works well, produces the expected results, is usable, and with acceptable performance. Of course this activity can be highly automated, even if usability tests and acceptance tests may require human involvement in near operating conditions.

But testing is not the only verification. Code review for example is another Q&A activity, that verifies if the code is robust, and meets some quality criteria that are expected to facilitate future maintenance. Another kind of verification is related to security. These kind of code reviews might be required to enusre that no undesired stealth behavior was hidden in the software (e.g. spying functions sending data to a foreign country once it is in operation), or that no vulnerability was implanted on purpose.

Nowadays, the V&V should no longer be considered as being necessarily a sequential step in a waterfall-like SDLC. THese activities can be integrated smoothly in the day-to-day activities (e.g. embedded in the definition of done) in agile processes.

Independent V&V is another (expensive) thing. This is often found in the context of mission critical systems (e.g. aircraft systems, factory system in a pharmacological company, etc..) and governement acquisition process. The reason is that team members (or staff members of a supplier) may have unconscious bias, or apply incomplete verification procedures (procedure might even be flawed because of purely economic consideration that are not appropriate for systems on which human lives depend on). This is why an independent team might be required. It is to ensure that V&V is carried out as objectively as possible and with state of the art expertise.

So V&V and IV&V are highly related. It is just that the second must be performed by a different economic operator in view of a proper segregation of duties. Note that in some cases V&V or even independent V&V could be subject of legal requirements.

3 added 64 characters in body
source | link

Software verification and validation are all the activities that ensure that the software fulfills all the needs and requirements for its intended purpose.

The best known of these activities is of course testing, which verifies that the software works well, produces the expected results, is usable, and with acceptable performance. Of course this activity can be highly automated, even if usability tests and acceptance tests may require human involvement in near operating conditions.

But testing is not the only verification. Code review for example is another Q&A activity, that verifies if the code is robust, and meets some quality criteria that are expected to facilitate future maintenance. Another kind of verification is related to security. These kind of code reviews might be required to enusre that no undesired stealth behavior was hidden in the software (e.g. spying functions sending data to a foreign country once it is in operation), or that no vulnerability was implanted on purpose.

Nowadays, the V&V should no longer be considered as being necessarily a sequential step in a waterfall-like SDLC. THese activities can be integrated smoothly in the day-to-day activities (e.g. embedded in the definition of done) in agile processes.

Independent V&V is another (expensive) thing. This is often found in the context of mission critical systems (e.g. aircraft systems, factory system in a pharmacological company, etc..) and governement acquisition process. The reason is that team members (or staff members of a supplier) may have unconscious bias, or apply incomplete verification procedures (procedure might even be flawed because of purely economic consideration that are not appropriate for systems on which human lives depend on). This is why an independent team might be required. It is to ensure that V&V is carried out as objectively as possible and with state of the art expertise.

So V&V and IV&V are highly related. It is just that the second must be performed by a different economic operator in view of a proper segregation of dutiessegregation of duties. Note that in some cases V&V or even independent V&V could be subject of legal requirements.

Software verification and validation are all the activities that ensure that the software fulfills all the needs and requirements for its intended purpose.

The best known of these activities is of course testing, which verifies that the software works well, produces the expected results, is usable, and with acceptable performance. Of course this activity can be highly automated, even if usability tests and acceptance tests may require human involvement in near operating conditions.

But testing is not the only verification. Code review for example is another Q&A activity, that verifies if the code is robust, and meets some quality criteria that are expected to facilitate future maintenance. Another kind of verification is related to security. These kind of code reviews might be required to enusre that no undesired stealth behavior was hidden in the software (e.g. spying functions sending data to a foreign country once it is in operation), or that no vulnerability was implanted on purpose.

Nowadays, the V&V should no longer be considered as being necessarily a sequential step in a waterfall-like SDLC. THese activities can be integrated smoothly in the day-to-day activities (e.g. embedded in the definition of done) in agile processes.

Independent V&V is another (expensive) thing. This is often found in the context of mission critical systems (e.g. aircraft systems, factory system in a pharmacological company, etc..) and governement acquisition process. The reason is that team members (or staff members of a supplier) may have unconscious bias, or apply incomplete verification procedures (procedure might even be flawed because of purely economic consideration that are not appropriate for systems on which human lives depend on). This is why an independent team might be required. It is to ensure that V&V is carried out as objectively as possible and with state of the art expertise.

So V&V and IV&V are highly related. It is just that the second must be performed by a different economic operator in view of a proper segregation of duties. Note that in some cases V&V or even independent V&V could be subject of legal requirements.

Software verification and validation are all the activities that ensure that the software fulfills all the needs and requirements for its intended purpose.

The best known of these activities is of course testing, which verifies that the software works well, produces the expected results, is usable, and with acceptable performance. Of course this activity can be highly automated, even if usability tests and acceptance tests may require human involvement in near operating conditions.

But testing is not the only verification. Code review for example is another Q&A activity, that verifies if the code is robust, and meets some quality criteria that are expected to facilitate future maintenance. Another kind of verification is related to security. These kind of code reviews might be required to enusre that no undesired stealth behavior was hidden in the software (e.g. spying functions sending data to a foreign country once it is in operation), or that no vulnerability was implanted on purpose.

Nowadays, the V&V should no longer be considered as being necessarily a sequential step in a waterfall-like SDLC. THese activities can be integrated smoothly in the day-to-day activities (e.g. embedded in the definition of done) in agile processes.

Independent V&V is another (expensive) thing. This is often found in the context of mission critical systems (e.g. aircraft systems, factory system in a pharmacological company, etc..) and governement acquisition process. The reason is that team members (or staff members of a supplier) may have unconscious bias, or apply incomplete verification procedures (procedure might even be flawed because of purely economic consideration that are not appropriate for systems on which human lives depend on). This is why an independent team might be required. It is to ensure that V&V is carried out as objectively as possible and with state of the art expertise.

So V&V and IV&V are highly related. It is just that the second must be performed by a different economic operator in view of a proper segregation of duties. Note that in some cases V&V or even independent V&V could be subject of legal requirements.

2 added 172 characters in body
source | link

Software verification and validation are all the activities that ensure that the software fulfills all the needs and requirements for its intended purpose.

The best known of these activities is of course testing, which verifies that the software works well, produces the expected results, is usable, and with acceptable performance. Of course this activity can be highly automated, even if usability tests and acceptance tests may require human involvement in near operating conditions.

But testing is not the only verification. Code review for example is anotehr activitiyanother Q&A activity, that verifies if the code is robust, and meets some quality criteria that are expected to facilitate future maintenance for example. Another kind of verification is related to security. These kind of code reviews might be required to enusre that no undesired stealth behavior was hidden in the software (e.g. spying functions sending data to a foreign country once it is in operation), or that no vulnerability was implanted on purpose.

Nowadays, the V&V should no longer be considered as being necessarily a sequential step in a waterfall-like SDLC. THese activities can be integrated smoothly in the day-to-day activities (e.g. embedded in the definition of done) in agile processes.

Independent V&V is another (expensive) thing. This is often found in the context of mission critical systems (e.g. aircraft systems, factory system in a pharmacological company, etc..) and governement acquisition process. The reason is that team members (or staff members of a supplier) may have unconscious bias, or apply incomplete verification procedures (for example to spare money and reach higher marginsprocedure might even be flawed because of purely economic consideration that are not appropriate for systems on which human lives depend on). THis This is why an independentindependent team might be required. It is to ensure that V&V is carried out as objectively as possible and with state of the art expertise.

So V&V and IV&V are highly related. It is just that the second must be performed by a different economic operator in view of a proper segregation of duties. Note that in some cases V&V or even independent V&V could be subject of legal requirements.

Software verification and validation are all the activities that ensure that the software fulfills all the needs and requirements for its intended purpose.

The best known of these activities is of course testing, which verifies that the software works well, produces the expected results, is usable, and with acceptable performance. Of course this activity can be highly automated, even if usability tests and acceptance tests may require human involvement in near operating conditions.

But testing is not the only verification. Code review is anotehr activitiy, that verifies if the code is robust, and meets some quality criteria that are expected to facilitate future maintenance for example. Another kind of verification is related to security. These kind of code reviews might be required to enusre that no undesired stealth behavior was hidden in the software (e.g. spying functions sending data to a foreign country once it is in operation), or that no vulnerability was implanted on purpose.

Nowadays, the V&V should no longer be considered as being necessarily a sequential step in a waterfall-like SDLC. THese activities can be integrated smoothly in the day-to-day activities (e.g. embedded in the definition of done) in agile processes.

Independent V&V is another (expensive) thing. This is often found in the context of mission critical systems (e.g. aircraft systems, factory system in a pharmacological company, etc..) and governement acquisition process. The reason is that team members (or staff members of a supplier) may have unconscious bias, or apply incomplete verification procedures (for example to spare money and reach higher margins). THis is why an independent team might be required. It is to ensure that V&V is carried out as objectively as possible and with state of the art expertise.

So V&V and IV&V are highly related. It is just that the second must be performed by a different economic operator in view of a proper segregation of duties. Note that in some cases V&V or even independent V&V could be subject of legal requirements.

Software verification and validation are all the activities that ensure that the software fulfills all the needs and requirements for its intended purpose.

The best known of these activities is of course testing, which verifies that the software works well, produces the expected results, is usable, and with acceptable performance. Of course this activity can be highly automated, even if usability tests and acceptance tests may require human involvement in near operating conditions.

But testing is not the only verification. Code review for example is another Q&A activity, that verifies if the code is robust, and meets some quality criteria that are expected to facilitate future maintenance. Another kind of verification is related to security. These kind of code reviews might be required to enusre that no undesired stealth behavior was hidden in the software (e.g. spying functions sending data to a foreign country once it is in operation), or that no vulnerability was implanted on purpose.

Nowadays, the V&V should no longer be considered as being necessarily a sequential step in a waterfall-like SDLC. THese activities can be integrated smoothly in the day-to-day activities (e.g. embedded in the definition of done) in agile processes.

Independent V&V is another (expensive) thing. This is often found in the context of mission critical systems (e.g. aircraft systems, factory system in a pharmacological company, etc..) and governement acquisition process. The reason is that team members (or staff members of a supplier) may have unconscious bias, or apply incomplete verification procedures (procedure might even be flawed because of purely economic consideration that are not appropriate for systems on which human lives depend on). This is why an independent team might be required. It is to ensure that V&V is carried out as objectively as possible and with state of the art expertise.

So V&V and IV&V are highly related. It is just that the second must be performed by a different economic operator in view of a proper segregation of duties. Note that in some cases V&V or even independent V&V could be subject of legal requirements.

1
source | link