Artifact: Technical Proof of Concept |
|
 |
A Technical Proof of Concept (POC) can be used to clarify areas of uncertainty, confirm requirements, or prove the feasibility of a selected approach. It will also provide information required to make certain decisions regarding the design of the solution. A Technical POC intends to reduce risk to the project. |
Domains: Architecture |
|
Purpose
The purpose of a Technical Proof of Concept is to explore a technology new to the project team, or to resolve a
significant technical issue within the design. For each release (or build cycle), there may be areas of
uncertainty for which you may decide to build a Technical Proof of Concept. The findings and experience gained
from building a Technical Proof of Concept not only benefit the current project, but potentially future projects facing
similar situations.
In addition to its primary goal of resolving key technical issues, a Technical Proof of Concept may also point to other
issues, or shed a light on complementary issues.
A Technical Proof of Concept is only developed when needed. Many projects do not need to construct one.
However, if the suitability or performance characteristics of any proposed component is in question, and information is
not available from another source (for example, a Technical Proof of Concept from a previous project), then developing a
Technical Proof of Concept should be considered.
|
Relationships
Roles | Responsible:
| Modified By:
|
Tasks | Input To:
| Output From:
|
Description
Main Description |
A Technical Proof-of-Concept may take many forms, for example:
-
a list of known technologies (frameworks, patterns, executable architectures) which seem appropriate to the
solution
-
a sketch of a conceptual model of a solution using a notation such as UML
-
a simulation of a solution
-
an executable prototype
The Technical Proof of Concept typically addresses any new or challenging technical aspects of a proposed design. It
may be needed for a number of reasons:
-
To assess the technical viability of the design of a specific component
-
To assess a specific area of the application from a usability perspective
-
To collect key technical information regarding the service-level characteristics of the entire solution as
documented in the Operational Model: Unsized, or of a specific component within that planned solution
-
To verify the compatibility of a component with other parts of the solution
-
And many others
Technical Proofs of Concept often involve the construction of partial or complete systems from hardware and software,
or the development of application or technical code. The earlier a Technical Proof of Concept is built, the better. It
will usually be developed during the early stages of a project, and will involve an early build of the component, or
components, under investigation. It quickly addresses the particular characteristics to be investigated for the
component.
|
Key Considerations
When considering whether or not to create a Technical Proof of Concept, it is advisable to consider the
following:
-
The cost associated with developing a Technical Proof of Concept is generally not small, since it produces
executable code itself; therefore, the cost must be seriously weighed against the expected benefits.
-
Since only certain high risk components are validated in a Technical Proof of Concept, and it in itself may not go
through formal design and build cycles, it is not intended for a Technical Proof of Concept to grow into the
project's overall solution. Highly-focused components may be used in the solution, but a Technical Proof of
Concept must not become the foundation of the solution.
|
Tailoring
Impact of not having | A Technical Proof of Concept is built as needed. Many projects do not need one. However, if a project has areas
of technical uncertainty or technical risk, then a Technical Proof of Concept should be seriously considered. Without
it, there is increased risk of encountering technical problems at the end of the project. The primary goal of this
work product is to lessen the risk of failure due to unforeseen technical problems. |
Reasons for not needing | The project may not have areas of technical uncertainty or risk. It may be composed of tried, tested, and understood
technology, or reliable technical data may be available for the performance characteristics of the proposed components (for
example, from the Technology Research activity). In these cases, a Technical Proof of Concept may not be
necessary. |
Representation Options |
Generally, a Technical Proof of Concept will result in executable code and some findings. The representation for this varies as widely as the technology being proven.
Notation
Because of the wide range of possible activities, including executable code, no specific notation applies.
|
More Information
Guidelines |
|
Estimation Considerations |
|
Licensed Materials - Property of IBM
© Copyright IBM Corp. 1987, 2012. All Rights Reserved.
|
|