Microsoft Word Hardware Reconfiguration Methodology V final2

Modifying system configurations

It is important to consider the impact of system configuration modifications. Some changes are innocuous and are likely to result in no noticeable changes or behaviour to the system; others may cause services and applications to act different from before. For example, the upgrade of an important network service was configured via its configuration file to block certain types of connections from external certain systems. Now that it has been upgraded and a new configuration file has replaced the previous one these blockages are no longer in effect. This may seem a minor detail (depending on what is affected) but this could potentially allow unauthorized access to data or services that are ordinarily unavailable. In addition, the modification of system

configurations can dramatically affect the users their interaction with the system. For example, users connect using a network-based protocol but after a series of changes a service configuration is modified and now compatibility mode for older clients is deactivated.

There are certain issues that should therefore be examined during the different testing phases after an update or upgrade has been implemented. It is important to determine which files have been changed, particularly configuration files. Changed configuration files should be compared to their previous incarnations to determine if any important service or system-wide changes have been made or propagated. This is another reason why it is also important to conduct backups prior to implementing updates and/or upgrades. Furthermore, this is why documentation, change assessment, and versioning control are important.

11. Outcome testing

It is important to determine if a set of changes made to the system results in a desirable outcome; specifically, to determine whether the changes were successful or a failure. However, it is important to define beforehand what should be considered a success and a failure. Failure could be defined as the causality between a specific set of changes and a disruption of services or applications, system stability, or reliability. It could also be defined as an unacceptable change in system behaviour, performance, or application and/or service use. Only after a thorough examination and stringent testing can the cause of a problem or failure, if it occurred, be determined. Then, depending on its manageability it can deemed a success or failure. This, however, generally requires testing on the parts of both the system administrator and test users. Both have a complex job ahead of them; however, it is often more difficult for the users to determine whether their applications and work methodologies continue to work appropriately. This can include their ability to establish access and work with data and other repositories, system services and applications, as well as accessing and using remote systems and devices (i.e. printers, etc.). In addition, if things are not working as they should they must also determine where they fall short.

On the other hand, if the changes and the overall impact on the system are considered acceptable in that they have caused little to no discernable problems or disruptions then the outcome for the changes can be considered a success. The case is further solidified if a set of changes imparts additional benefits such as improvements in usability, performance, security, robustness, etc., without adversely affecting the system.

Outcome testing is not actual testing phase per se. Instead it is a culmination of results obtained from benchmarking, impact analysis, user tests, system administration related tests, etc. All successes and failures should be thoroughly documented as well as justification for an apparent success or failure. It is to be expected after an update, but especially following an upgrade that there will be some failures. However, in so long as they remain manageable then there is no need to consider the entire update or upgrade a failure. Manageable failures can still be included in the update or upgrade process while those that cannot be reasonably managed should either be altogether left out or fixed, if possible, using manual system maintenance.

12.