Post-Release Activities. At which we're going to look at verification and validation, the management verification and validation, the technical verification and validation, the differences between the two and independent testing.

Now immediately following the successful installation of the deployed software, we need to begin several necessary activities. These will include a configuration audit to ensure that all required settings are in fact and verified as correctly implemented. We will undertake hardening to ensure that all security measures are in place and that the attack surface has been optimally minimized. We need to ensure that we capture all of the installation issues and documentation of those corrective actions to resolve them. And the capturing of a new master image baseline and the creating of the original clean source backup of it.

Now, the required procedural documentation must also be created and used to ensure that these critical aspects are created, maintained, and improved as the software is made to adapt and evolve through the change management process. So, verification and validation. Now taken together, these are processes to confirm that it is the correct build that functions correctly. To break it down a little further, it means that the software was constructed correctly and meets the quality and performance measures. Also, that it meets the user functional requirements when in operation.

To put it another way, it is, we have built the right thing and we have built it the right way. These processes are performed in the concluding steps of each stage of your software development life cycle and a final one at deployment, with procedures to ensure that we capture anomaly incident and problem reporting, that auditing is done for deviations and exceptions, that we establish baseline control and configuration management, and that we have an evaluation process to ensure continual alignment with business requirements and change management processes to bring about controlled evolution to maintain this.

Now, overall, the verification and validation processes break out into two separate groups. Now they are separate, but they are of course, intimately related. Now the management V&V are the processes geared towards management process behaviors and requirements that will involve the software. These typically include comparison to plans or schedules to evaluate project suitability, outcomes that will typically impact corrective actions, resource allocations, and project scoping.

Outcomes will often include changes and corrective actions and the roles that are typically involved in this process will include the decision makers, the management staff, the tactical staff and the user representatives. From the aspect of the technical V&V, this is the verification and validation set of processes that are geared towards the software itself. All the documentation including code, test, and installation. 

Now these will involve analysis concerns of the configuration and conformance to the specific standards, outcomes management and customer support, supports problem, anomaly and incident management, and it typically involves the very same set of roles, decision makers, management staff, technical staff and user representatives in a separate, but related set of issues. Now, a subject that must be addressed by anyone involved in the management or the tactical build of any program will be independent testing an audit.

Testing by third parties is often employed to obtain objective results and thus heighten the confidence that the receiver will have in the delivered software. Now it's common to separate duties throughout these kinds of processes, but here the separation between builder and buyer tends to inspire more confidence by elimination of the inherent bias in either party, as well as the possible influence over the decisions that might be made concerning it. Auditor independence has long been a requirement throughout many of these aspects within IT and specifically when it comes to assurance and certification.

In these cases, it has to ensure that there is integrity and confidence in the quality and compliance of the delivered product. In addition to that, third party audits are often required in these arrangements where compliance certification and attestation are mandatory. Now, as in the case of the SSAE-18 Audit, often called a SOC, which is an abbreviation for the report that is produced by the SSAE-18 Audit, these activities are planned with scope, risk assessment, methodological organization and execution.

As with all audits, items and artifacts are to be examined or outlined. The methods of examination and evidence artifacts are described in detail. The attributes and the pass fail factors are defined. Requirements to be met are compiled with their related metrics. And the reporting delivers the findings, recommendations and typically what follow up activities will follow next. Now, this report, which we have in the closing phases of the software is delivering, and all of its related documents and actions will become part of the history of the software and will be employed as the original source to guide future activities and adaptation and the progressive improvement of it to ensure it remains in alignment with its original and evolving objectives.

We have discussed and learned that before software that is built or bought and is decided as ready for deployment or release, it must go through a formal acceptance process. Now benefits of a formalized software acceptance process include validation of security requirements and the verification of the controls, meaning that we ensure that it is not only operationally hack resistant but also compliant with the applicable regulations. We've also covered that prior to the acceptance of the software, several things have to be taken into consideration. Including the satisfaction of the redefined completion criteria which must be defined as precisely as possible. The establishment of a change management process which is key to the products installation and to its future evolution and adaptation. The process of approvals to deploy release, including the risk acceptance and any exceptions to this policy and the completeness of pertinent documentation.