Module 6 is the next section. It is where we are now talking about the element of secure software acceptance. What we are basically trying to do is get the customer to sign-off for our work. So, we want to make sure that all the elements are completed and that we have implemented all the requirements, as indicated by the customer and other stakeholders, to begin with.
Along with collecting and meeting the requirements, we’ve also laid the foundation or groundwork for the design of the software. We have designed the product so that the requirements are implemented. We have at this point, then, fully tested and just about ready to turn it over to the customer for signoff. May not be a bad idea to go back and revisit module 2, part 2. This section of material talks about what is considered as good requirements as well as how to collect those good requirements so that you can be able to really have what the customers are wanting you to make. That’s the big part of the issue in that we may think we have what the customer is wanting, but not have collected good requirements in the first place. So, then through the tests, reviews, audits, and other elements help us with saying how we met the requirements, however, if the customer isn’t happy with the product, then perhaps we didn’t collect the requirements to start with. So, hopefully, we’ve got enough documentation to support and mark the traceability of the project from its inception through the creative process, to the end where we show the meeting of requirements.
There are more formal methods to indicate whether or not we meet customer requirements. It is a formal analysis known as software qualification testing. It is a set of tests conducted by customers. After we’ve conducted our own in-house testing by quality assurance, then we’ll turn it over to the customers for their own formal testing process. The testing plan is well written and formalized as to the features which need to be tested, as to what type of stress, how much load it can handle, any sort of mitigation, strategies, performances, interfaces, and any other sorts of tests that we would specify as relating to the environment the customer is going to implement the production. All the various tests should have been predetermined prior to the design process. While the collection of requirements is being conducted at the start, before any of the design, development or other steps have happened, these tests can be decided as to what will performed by the customers. The idea here again is to get customer signoff. With good requirements, we can have them lead to good design. With good design, we can see good implementation. With good implementation, there can be acceptance by the customer.
Before turning the product over completely to the customer for the pre-release, we look at the contract and make sure that the product is implementation-ready in the environment that customer is using the production. There is a standardization of generic criteria for a product’s suitability. The ISO standard 9126 gives us six main categories: functionality, reliability, usability, efficiency, maintainability, and portability.
Functionality refers to whether or not the product actually does the job it’s supposed to do. This is the main criteria as to whether or not it meets the requirements. This is an essential piece of criteria.
Reliability refers to whether or not a piece of software or if the system responds in relation to its tolerance to problems or flaws. This looks at the maximum time to repair the problems. It also looks at if system is reliable or not.
Usability refers to how easy or difficult is it to use. This is a criterion that’s more about ease of use.
Efficiency refers to how well this software or system performs in its efficiency. In other words, we are interested in response time. Does it take too long for a response or is it able to respond fairly quickly?
Maintainability refers to how well change management is handled. Change management from software development must be handled and there must be a process in place so that there’s less miscommunication. Also if a developer makes changes for software and the software is already out in production, it’s possible that the change may make it where other functions no longer work. So, there could be problems arising if we don’t have an accepted process in place.
Portability refers to the flexibility or rigidity of the product. This is with respect of the various environments that the customer may choose to use in production. There’s also the possibility of its flexibility with reference to various vendors and with reference to different additional components.
These previously discussed six criteria are just a few of the criteria which could be used to evaluate the pre-release of the product. There’s lots more as well as more involvement on the part of the formalized customer testing methods.. This listing is just a few of the criteria for evaluating pre-release of the product, for convenience’s sake for today’s discussion.
There are still a million other pieces of performance criteria that can be specified, that we’ve chosen just not explore here, but can be prompted in the contract as well. So the ones we’ve discussed are just a set of requirements from the ISO 9126.