Guideline: Technical Proof of Concept Scenarios |
Technical Proof of Concept Scenarios outline situations which may warrant the development of a technical proof of concept for a given engagement.
Relationships
Related Elements | Technical Proof of Concept
Main Description
Since a Technical Proof of Concept actually validates a component design and produces executable code, it is difficult to document a running example. This document will simply highlight scenarios which may warrant the development of a Technical Proof of Concept. 1. In order to fit a particular customer's existing IT platform, a project was implemented using Smalltalk and COBOL with C++ infrastructure code. This particular combination of technologies was at that time totally unknown in the relevant development shop, so a small subsection of the product was developed as a Technical Proof of Concept. It included the bare minimum to demonstrate the compatibility of the components and measure the end-to-end performance characteristics of a simple transaction. The transaction was measured using a desktop object on the client, the messaging service between the client and the host, and a simple server component. The following results were produced: Metrics for the performance and capacity characteristics of the technology, such as message size information and turnaround time. Outline requirements for tools to monitor and verify the cost of the technology, in this case the incorporation of trace points in the application logic to support performance analysis and debugging. Recommendations that some of the technology should not be used. In this case, the proposed version of Smalltalk was replaced with one from another supplier because of the inefficiency of the garbage collection process. Developer guidance on the most effective way to use the technology, for example on how to reduce total time perceived by the end-user by overlapping client and server processing. 2. Another project development team performed some initial work to learn exactly how MQSeries worked. The output from this was in the form of flow diagrams that identified the areas within the product that could become performance concerns. 3. A third project required an interface to an existing system. The new interface had aggressive performance requirements. A Technical Proof of Concept was created to validate the design options for maximizing the throughput of the interface. On a fourth project, the designers were unsure which batch architecture would yield the shortest overnight run time. The cost of actually developing more than one option was prohibitive, so a detailed simulation of the various options was carried out using a tool to determine which was the most effective. Note that this approach should only be used with great care, as any simulation is only as good as the data that goes into it (refer to the Performance Model WPD).
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.