| < Day Day Up > |
|
Exhibit 10 presents an appropriate validation procedure.
Exhibit 10: Technology Validation Process
Validation Step | Rationale |
---|---|
Proof of concept (alpha test) | In laboratory environment, validate functionality and that components work together acceptably. |
Stress test | Simulate production load via scripting, "packet flooding," or other relevant techniques. |
UAT | Turn test environment over to beneficiary for testing. This is a dress rehearsal, and should be run in the production environment with adequate safeguards, or in isolation if testing in production is not feasible. |
The key thing to remember is you want to get into the production environment well in advance of cutover or rollout time, so you can discover and react to any problems that may crop up. In the previous load-balancing example, the incompatibility of the legacy load-balancing software with the new network switching was not anticipated. Because the user acceptance testing (UAT) ended up running late, we had very little time to react once the issue surfaced.
When planning this validation process, you need to look for potential failure points and have a remedy scheme prepared to the extent possible. If we revisit the load-balancing scheme one more time from this perspective, load balancing should have been identified as a test item. How? It should have been quite simple. During the test planning meetings, several documents, as presented in Exhibit 11, should be reviewed.
Exhibit 11: Test Plan Document Review
Document | Contents |
---|---|
System architecture drawing | Shows hardware and software components and inter-connectivity. |
System architecture description | Describes applications, tools, and services, and how they interact. |
Draft runbook | Required for operations turnover. Indicates how services and application are started and stopped, how users log in, user functionality, backup and disaster recovery schema, and other connections (e.g., File Transfer Protocol [FTP]). |
A diagram, such as the one displayed in Exhibit 12 detailing system architecture, would clearly have identified load balancing, as would system documentation that lists each hardware component and identifies applications or services running on each platform.
Exhibit 12: Network Load-Balancing Configuration
A draft runbook, which is normally required by operations, would also have flagged load balancing as a piece of system architecture requiring specific configuration, as well as an escalation list for support in the event of an outage. [4]
Again, as project manager it is not your job to write detailed test plans or come up with clever solutions to tricky problems. It is your job, however, to insist that such work is done. The best way to ensure compliance is to schedule meetings to review the plans. Network and operations personnel should be present in addition to implementers, software developers, etc. The intent is to focus the right eyes on the technology game plan so that any gaps or potential points of failure can be identified and resolved.
The last action item in this piece of the project is addressing risk, performance issues, or unfulfilled requirements. You can also expect that, once the user gets involved, new requirements will mysteriously arise. Although you may or may not know why new demands come to light at this stage of the game:
It could be the fault of the analysts who developed your requirements.
End users might have done a poor job of articulating their needs.
A new requirement may spring from a recent change in the business environment.
Hopefully, you can see why this process should be agreed to and scheduled well in advance of any production dates. Also, you should consider planning this in phases. In other words, have a first UAT in June, a follow-up in July, and so forth even though production turnup is not scheduled until October. You know things take time to get ironed out, so be realistic, and be sure your plan reflects that reality.
[4]See Chapter 11 for details on runbooks.
| < Day Day Up > |
|