Okay now Part six princes, toothy element of secure software acceptance. And this is a very short chapter because the idea is all the work has already been done. What we're doing is we're essentially getting sign off from the customer.
So we want to make sure that we've done all the elements up to this point. We've laid down the groundwork, Sui. We've collected good requirements. We have good, strong design. We implemented the requirements into the sign of the software. We properly tested it, and now we're at that point will return it over to the actual customer
So in this phase, what we're looking at is to get a sign off from the customer. And we want to determine that the product has met the delivery criteria as per the contract.
So essentially, when we talk about meeting our requirements, those requirements better be well defined in the contract.
And we talked about very early on that the heart and soul of every thing we do stems from our requirements. So don't forget to go back and visit module to your part to where it talks about collecting good requirements. Because if our requirements are poor, then we're going to find that even though we've designed the product that we think we were supposed to
we may still not get customer sign off.
All right, now we have to provide the documentation that shows we've met the requirements. So of course we have our contract. But we're also gonna have tests, reviews, audits, other elements that we can use to say, Look, here's the product that we've provided in here all the ways in which we've met those requirements.
We also might use tools like requirements, traceability, matrices.
You know, we talked about that where we can take the requirements of individual stakeholders and trace all the way through the project and show. Here's where we met the requirements of sponsor off the end users and so on.
All right now, software qualification testing on this might be testable this definition here, and that's why I've given it pretty much word by word. So software qualification testing is thief formal analysis. So it's formal. That's done to determine whether a system or software product
satisfies its acceptance criteria.
That's exactly what we're talking about Here s O the formal analysis that determines Did we meet the requirements or not,
these tests are conducted by the customer. So this is where the customer inspects the product we're going to do in house testing through quality assurance. And then we'll turn the software over to the customer and they'll conduct conduct their own tests. And that's the software qualification testing that felt before.
Now in their qualification testing plan, they're gonna have And it should be very well written, very formalized. What are the required features that need to be tested under what load? What type of stress? Any additional tests that need to be performed in a sort of mitigation strategies,
tested interfaces. You know, all these things that we would specify. We're looking to make sure that our product is gonna withstand and it's gonna be well suited for the environment that the customer is gonna implement. This product in all of this should have been predetermined ahead of the design process. Right when we were collecting requirements,
we had all of this information.
So as long as we built the product according to the requirements and as long as we had good requirements, this acceptance peace should go very well. Now I say that with a little bit of a smile, because we know how the real world works. But the theory is good Requirements lead to good design. Good design leads to good implementation.
Then we test to make sure the implementation was good.
Now we're ready to get acceptance from the customer.
All right, so pre release, before we turn this product over to the customer, we look at the projects contract and we make sure once again, that the product is suitable for use and I so standard 9126 91 26.
Um, give six generic pieces of criteria
for products suitability. Now, this is not specific to software. This is just in general. So regardless of the product that I'm creating, we look att, six main categories. The 1st 1 is functionality again. In a confusing these phrases again again,
Does it need its requirements? Does it do what it's supposed to do? And of course, that's essential,
How, um does the system respond in relation to fault tolerance? How does it respond to shutdowns or fail years? And how many failures are we gonna have? How reliable is the system? How long do we expect it to run? You know, when we look at things like meantime, between failures and
maximum time to repair. We look at those elements to determine whether or not the system our software is reliable.
Usability goes back to ease of use. Is it efficient? Is it acceptable to the end? Users
Isn't efficient? Do we get good performance with this software?
Um, do we good response time? Does it process? Does it take a You know, an exorbitant amount of processor utilization? Ah, where does it stand?
Maintain ability. How is change management handled
change management from software development must be handled, and it is essential there must be a project, a process to handle changes because a developer can always go back and make a change. But if a developer makes a change to software that's in process, you know that's already out in production. We have
big problems, and that one change,
the developer makes make calls other functions, to not work. So what? You have to be very careful about allowing change, making sure that there's a thorough change management process in place to control how those changes have another piece of criteria is portability.
Can the product operate in different environments, or is it very rigid, or is it select simple enough
to be an environment regardless of the vendor, regardless of the additional components and elements? Now there are a 1,000,000 other pieces of performance criteria that can be specified in the contract as well. But this is just a set of requirements from ice 0 91 26