Let us change approaches here for a moment and talk about software in terms of build or buy. The acquisition of software is of course, like anything else, we can build it or we can buy it. But software is unlike almost any other commodity. It is a combination or recombination of existing elements, possibly with new components added. Licensing its use, but never owning similar to other intellectual properties, such as books, music or movies. But we also get a warranty that indicates it is almost certainly flawed in some way, reading the EULA, the End User License Agreement for any software, typically it says this product is provided on an as is basis. And what this generally means is they have done everything they reasonably can to assure that it's free from flaws and mistakes, but they can't guarantee that it absolutely 100% is.

Now in-house built software, almost certainly contains modules and components, built by other parties. And this aspect raises the question of security and the pedigree of those other elements. Nevertheless, we're going to be involved in an acquisition process that must have quality and security integrated into the flow to ensure the protection of the supply chain for all components that are required, versus those that are built in-house. So, the software assurance in the phases of the acquiring process are these, we execute planning activities, we do the contracting, we do the monitoring and acceptance to assure that the quality and performance specifications are being met. And then the follow-on, once the software itself has been delivered, released and deployed and is now an operation.

So, first let's address the planning phase. In the planning, what we hope for is that we have a well-conceived plan that talks about the product as we actually want it to be when it's complete. This will contain of course, the security features that are tailored to our needs and that they're fully integrated and operate smoothly. The process of planning of course must include compliance and the requirements of it built in. We need to have in all cases, clear descriptions of the required functionality and the features and all of the aspects that we'll deliver there. We should have a clear understanding of the intended user and their needs. This is primarily the descriptive process that we will give prospective builders. There should always be full disclosure of any constraints, so that we avoid costly surprises in the work of designing and building. And there should also be an understanding that with the progress, will come the necessary requirement to be able to adapt to change along the way.

We start with a composite, a combination, a recombination, an aggregation, an agglutination so to speak of all the different pieces that we must bring together from which we will develop our software requirements, build an acquisition strategy, set up the monitoring and acceptance of the controls to assure that what is delivered is what is expected and that it will perform up to expectations. And then we will have to develop from this, the process by which we will acquire it, use it and then manage it over its life cycle.

So, to break down the contracting phase. In this portion of the procurement cycle, what we're going to do is build an RFP, an RFI or our Request for Bid. We're going to put together everything that we spoke of on the previous slide and deliver it to prospective contractors. Let them evaluate the scope of work that we have provided them and then ask them to submit their idea, their bid, regarding an offer that will meet the terms and make the deliverables. Things that we're going to need to consider in this process for our prospective contractors, our past experience and successful accomplishment of projects, similar to the one that we're putting before them, that they have a clear understanding of the scope and what the end product is supposed to be and what it is supposed to do and for whom, that they adhere to the Iron Triangle concepts for on-budget, on-schedule performance, and that they're committed throughout this process to open and clear communications.

So, the process that they're going to go through is going to be to read the scope of work that we've given them, develop and issue an RFP, they're going to deliver to us and we're going to evaluate the respondents to see who meshes up best to what we need. Then we're going to select the optimal offer that meets all the different terms at the best level. And then ultimately execute a contract with the winner. Then once it has been awarded, we're going to monitor the development, build, tests, et cetera, all the different phases that we're going to have. We're going to begin by establishing and providing consent for the contract work to begin and the schedule on which it will be delivered. Then we're going to define and implement change control procedures, because as with all projects of any type, change is inevitable. The change that we experience in software development projects is not however, like the change that we experienced when building a dam.

In software, many different ways can be found to bring about a function and its product. We have to find the best way, the right way, the most efficient way. And by these different terms, we need to come up with what for us will be the right way that it needs to be done, but it may differ in its actual execution from what was originally envisioned. And so we need to put in place a strong change management process to assure that we stay within as is reasonable, the Iron Triangle constraints that we put on the project. Then once it has been satisfied, we invoke that and then we carry on with the process of defining and building.

Then we have to make sure that we define and establish the Deliverables Acceptance Matrix and the process for evaluating deliverables, against those metrics to make sure that regardless of how much change we may have had to endure during the process of design and build that it still meets the performance requirements that we've set out. Once the deliverable has been actually delivered, then we review it, test it, evaluate the metrics and then decide to accept or reject the deliverable. Throughout this process, there has to be active exchange, good communications and effective change management to ensure that we don't suffer from that interminable feature scope creep. We have to be willing to adapt as new and better ways come up and can be included in building our program in a way that is better perhaps than it was originally envisioned. But we have to be sure that in the end, what is made and delivered and tested as evidence that it does exactly what we needed to do.

Now, once the deliverables are combined and the ultimate end product has been integrated and is now ready to be deployed and operated, we have to be sure that we have a plan in place for how those operations and the accompanying maintenance is going to be performed. As designed and build transition into operations, this must be something that we have prepared for and are ready to assume as soon as our deadline say, as soon as the program is actually ready, so that the benefit that we have just paid good money for, can now be attained.

Part of this will be to evaluate whether the contractor that has built this should be the one that maintains it or if we've decided that we're going to move that in-house. If we decide that we're going to do it ourselves, then we should be of course, considering staffing changes if those are necessary, if not, there may be a second procurement that we must undertake to get someone in to maintain it. And before the end, we have to evaluate and decide how we're going to handle the decommissioning and disposal of the product. This will of course include replacement if the work that this has been created and purchased to perform is going to continue. Issues that we have to address during this, will involve clearing the program of any sensitive data and any special handling that any residual private covered data will have to be given to ensure that breaches are avoided.

So, in our acquisition process, we're going to make the make or buy decision, based on a number of factors, the cost of labor, the availability of resources, urgency and market factors. When we consider these things in the context of what we're having delivered and what its intended use and who its intended users will be, we have to consider these things as to whether making is better, more efficient, faster or that buying it, whether it's having someone else build it or buying the various pieces and assembling it is going to be the best route. All of these decisions are the normal ones that accompany the acquisition process.

Now, this concept originates many times with the company that does not develop software, but in fact has an idea for a particular product or service they wish to offer. And if software development is not part of their core function or an area with which they have any experience at all, this can complicate the matter of putting together a concept, developing the statement of work and ultimately leading to buying a firm's product that has been built for it and knowing exactly what to do with it. It's paramount that experience, knowledge, and diligence in this kind of a process is something that the purchasing company needs to have to be able to know that they're getting what they're paying for in every sense. We can of course outsource every part of this or certain parts. The challenges we face when it comes to outsourcing is the economics, timing, distance or if we're going abroad or out of the country in which we're going to use it, the culture and the country and any legalities involved with non-native contracting requirements and loss. Sometimes these can prove to be quite costly. They can also prove to be missteps for a failure to have considered all the different factors that may affect the user acceptance of our product and the support that will come with it.