Now, the last section of this chapter is just making sure that we understand certain terms that air associate it with product acceptance in these terms kind of sound alikes. We want to make sure that we understand the differences between them.
So the 1st 2 terms we have our verification and validation
verification is more about the technical design of the product. Does the software meet the developers description? Does the does the software meet the requirements? Does it do what it's supposed to do,
then? Validation, which would come next? And validation is essentially, does the product solve a real world need that I have? So it does what it's supposed to do. But does it solve a problem for me? Does it fix the problem that I have not make sense that if it does what it's supposed to do, then it would fix the problem.
But again, sometimes you can have these variances between requirements
and where customers don't give us good requirements and we don't collect good requirements, so you might actually have a product that's verified that doesn't get validated. In an ideal world, verification would be followed by validation, we verified. It does what it's supposed to do. Therefore, it will solve the problem that we're trying to solve
now. We would have checks for verification and validation. Of course, we have to make sure that the security protection mechanisms air in place. We always go back to thinking about the C I. A triad of confidentiality, integrity and availability.
But remember there lots of other security elements we have to check for, like authenticity,
non repudiation authorizations, session management, all that stuff that we've talked about. So these are some of the checks that we would go through for the verification and validation process.
Now, the remaining two terms certification versus accreditation certification is the technical evaluation of the security features of a product
in a particular environment. So, ultimately, does the product provide the appropriate level of protection that's necessary given an environment cause. It's certainly possible for a product to be certified in one environment but not to be certified for a separate environment.
So certification is technical. Does that do the requirements get satisfied through this product,
and once the product is certified in the next logical step would be accreditation management's acceptance off the product and at that point in time management accepts all the risks associated with the product and they move forward and say, Let's roll this out, Let's implement.
So at this point in time, we've gone through the full process.
Management's accepted the product. They rolled out the product after accreditation, and they've accepted the risks associated. So, really, at this point in time, we're in the post acceptance phase. And here's where we really are withdrawing our support for this product. You know, any sort of warranty work
or any sort of ongoing support,
like patching the system. Um, anything that's necessary to ensure that the product works well in its environment, that we fix any bugs or flaws that are out there. But again, it post acceptance. We've handed off this product, and we're sort of backing off.
Now the customer comes to us and wants other changes.
Unless they're a result of the product not meeting its requirements, those other changes would be handled as a separate project. So maybe the customer now wants us to come back. And they say, You know, we just assumed you were going to train our customers on this product. Well,
we've documented that we're not going to provide training or manuals. We'd be happy to do so. But that'll constitute another project, and we can begin from that stage again.
So ultimately, after post excess acceptance, we're patching the system any sort of updates that are necessary in any sort of warranty.