So let us begin with this idea. Conceive clearly, design well, build better, and implement flawlessly. Certainly a series of great ideas. However well the software was designed and developed with security in mind, there is no assurance by default that it will be deployed with security controls in place and functioning correctly. Now, all of the assurance efforts that we've discussed throughout this entire course in designing and building the software will of course be rendered impotent if the deployment process does not also include security with its functionality in place, though it may have to start in a default sort of setting but it can't end up that way. Once this is deployed, the monitoring is a crucial aspect of this because we have to see how the process is working.

We have to detect as early as possible the kinds of problems that may be encountered during the installation and deployment process so that we can correct them and make sure that everything ultimately goes to plan. Now, the ongoing operations and maintenance including addressing these incidents impacting the software and patching it are going to have a lot to do with how the software ultimately will be brought up for operational use and how down the road it is protected and hardened against exploitation.

The subject of final disposal of the software when it reaches its point of obsolescence or where it simply is decided that it's no longer going to be patched and it will be ultimately replaced by something else is something that has to be dealt with and should be dealt with relatively early in the cycle. As software is used, it acquires attributes, changes, it evolves, and very likely, it becomes possessive of sensitive information and data. And this needs to be thought about so that as the software is used and ultimately disposed, these issues and the cleaning up of all of this can take place in accordance with other good operations and management processes.

Now, the processes required in this phase involve the builder, the acquirer, and the operator roles to ensure that this is a well orchestrated and well executed implementation and deployment process. Now, obviously the purpose of the installation and deployment process is to embed the release product into the target environment, and having designed well and built better, the project has arrived at the point where care must be taken to make sure that the implementation process is as nearly flawless as possible. No doubt, certain kinds of irregularities or unexpected occurrences will happen, but we have to do this with the idea in mind that we're going to proceed with caution and with a great deal of care and diligence because to do otherwise, will most assuredly undo all the work that has gone into the finished product.

Consideration is going to have to be given to the process steps that have led to this stage, including all of the adaptation and modifications that no doubt have occurred along the way and may not have actually been in the original plan at all. The environment into which it's going to be introduced has continued to operate and evolve as well. And the implementation plan that has been conceived at project beginning may well require updating. Now installation and verification is a subject area that we have to address because this has got to be done at several different points along the way. Now, as was done in the build process, each stage of the implementation should be conducted with V and V actions taking place.

Now, let's recap briefly. Verification. This is the confirmation that all intended actions were taken correctly. Doing things the right way you could say. Validation. And this is the affirmation that all actions and results were the correct ones or that all the right things were done. So what we have here is the confirmation that we have done things the right way and we have done the right things themselves. Now that may sound like two of the same things that we're doing but in fact, they're not, they're complimentary, and we do need to do both.

Now, these should have been determined in agreed to suite of tests during and following the implementation of the product. And these should include configuration of the modified platform to the enterprise baseline. We need to harden the platform, a process that should be taken on any software that is going to be deployed. Part of that will be to remove anything that was put in there during the development process that should not make it into the operational environment, such as back doors or hard coded credentials.

These may be common aspects that we'll find going through these processes. And indeed they are the very is things that hackers when they exploit a piece of software are going to look for. And sadly, they're not disappointed nearly often enough. We also have to be sure the defaults have been changed to the enterprise standards and removed when and where possible. All of which boils down to our actively removing and reducing the attack surface so that it is as small as is reasonably possible.

Now, a quick clarification, we always have to keep operations and performance in mind. Security is a very high priority of course, but we have to balance security needs with the operational functionality of the program. So when we say that we're reducing the attack surface, we're doing it to the reasonably lowest level that we can that doesn't adversely impact performance at the same time.

So once we have completed all of these essentials, we're going to put this into a position where customer testing and their acceptance will have to follow, because until the customer says, yes, this is what I wanted. This does what I want it to do the way that I wanted to do it, we haven't actually achieved the ultimate objective.

Now the acceptance testing we've done earlier is of course a prelude to customer acceptance testing. But until we get the customer's blessing at the end of this particular process, we really haven't done the job totally. We also have to, for our part of it, we need to ensure that we've accomplished all of the contract deliverables we've committed to. And we complete those in the actual implementation as we prepare for actual deployment and then usage. Part of this will probably include a security assessment or sometimes known as certification and accreditation actions that must be performed so that formal acceptance, and along with that risk acceptance in the final product can be conducted, recognized, and documented as formalized.

All of this leads up to a successful go, no-go decision to go forward with the actual deployment and use. So now we've arrived at the point where we have to consider planning for the operations. Now, following the deployment readiness decision, notice that it's the decision is being made. We haven't actually begun the formal deployment yet, but we've decided that we're prepared and ready to go forward with them. At this point, we should have a transition plan that takes shape or is finalized to ensure a smooth assimilation into operations.

Now, various things have to be done by various parties and we have to be sure that the proper people have been defined early on and assigned to actually perform these tasks. First, we have to have assigned a system owner or an application owner, depending upon the size and scope of the project we've developed. We have to determine which monitoring and reporting activities and who will be responsible for doing those.

We have already had to consider the integration of the new system or application with the CM process but we have to be sure that we've got this app aspect recognized so that we can cover it. We're going to have to draft the currently envisioned software roadmap so that this program will fit into not only the enterprise baseline, but into a product roadmap for management with the integration of it with other elements considered. Then, as always, we have to consider user training and the piloting, various departments may be the first adopters, then the second ones, and then maybe a general rollout.

But however that process is going to take place, we have to be sure that we have an idea, a concept or a firm plan in mind. This can't be the final time or first time rather when we've thought about this. Part of it needs to be that customer support or help desk operations need to also be orchestrated and be available on day one of operations. A delay can generate resentment and a refusal to accept or grudging acceptance of the program if user support is not there at the very beginning.

So bootstrapping. Well, this of course comes from the notion that we're pulling it up by its bootstraps but we have to go ahead and do this process and walk through it and be sure that we gather all of the information we can about how it performs, how it progresses, because a number of very important functions will take place. We need to be sure that security settings and general configuration parameters are in effect and that we get those set in the proper manner in accordance with the enterprise baseline.

We have to be sure that we have the execution default set up and we have to have error detection routines. At this point, this is one of the more serious considerations, because during the initial deployment, during the initial bootstrapping of this program, a lot of things may happen. And we're going to have to make sure that we have a way of capturing all the errors that may occur so that we can resolve them so that in normal operations, which is what this is all leading up to, we'll be able to run much more smoothly and those errors will be addressed and we hope go away entirely for having been fixed.

We're going to do the secure startup and secure startup means that the process is built in such a way that all of these things have been set. It is shown to be secure, and it goes from power on to a proper ready state with all of these parameters in force. Integration of this program with the general configuration management process. We have to be sure that this program like all others before it is included in the overall plan for managing configuration day to day as well as the long term aspects of it.

Now, programs and systems that are managed in this way are controlled in their configuration at every step in its life and configuration management isn't just about controlling the details. It has a much bigger, much broader objective. The point is we're going to keep the systems and applications in a trusted and reliable state by keeping it under control, making sure that whatever operational level agreements or OLAs or service level agreements or SLAs that we have in place, that all of the commitments for performance availability, et cetera, are built into the program, managed actively, so that we can provide what we've promised.

Keeping it in a controlled state means at any given point in time, we know what it should be, and hopefully what we believe it should be is what it is in actual operation. The ultimate objective is to ensure that it stays in alignment with the organization's mission. So we're going to have to establish the actual CM process for this particular program in question. We have to have different members of our organization involved. We have to have their roles and responsibilities defined and we have to actually map out the plan for this application and know how it fits with all of the others to ensure that this alignment that we keep talking about remains in effect.