Determine evaluation criteria
Draw the criteria against which the Architectural Proof of Concept is to be evaluated from the
architecturally significant requirements for the concept under evaluation and from the functional requirements for the
candidate service(s) that are under consideration. Leverage the Software
Architecture Document and the Service Model.
|
Decide on construction approach
Work with the Developer to select the techniques to be used to construct the Architectural Proof of Concept, for
example:
-
Conceptual modeling
-
Rapid Prototyping
-
Simulation
-
Automatic translation of specifications to code
-
Executable specifications
-
Construction of spikes as prototypes - vertical slices through layers
|
Select assets and technologies for Architectural Proof of Concept
The Developer selects the assets and technologies to be used to construct the Architectural Proof of Concept.
|
Construct Architectural Proof of Concept
Using the techniques selected for construction, the Developer builds the Architectural Proof of Concept, using the
selected assets and technologies, to satisfy -- to the extent required by the risk profile of the project -- the
functional and non-functional requirements for the candidate service.
|
Evaluate Architectural Proof of Concept
Test the Architectural Proof of Concept against the evaluation criteria. The way that this is performed
depends on the form of the proof-of-concept. For example:
-
In the case of an executable prototype, this might be through demonstration
-
For a conceptual model, through inspection and reasoning; or,
-
For a simulation, requiring the set-up and running of the simulation model with input data derived from the
evaluation criteria, the testing is performed by collecting and analyzing output data from the model.
|
Assess results
Assess the results to determine whether the evaluated concept (generally an existing asset) meets the requirements for
the candidate service. Also, use these results to check on the validity of the requirements. At this time in
the project, requirements are still mutable and not necessarily well-understood by the stakeholders. For example,
perhaps the opportunity exists to relax requirements that were shown to be high-risk by the evaluation of the
Architectural Proof of Concept. All these avenues need to be thoroughly explored in assessing the
results. This contrasts with the situation later in a project, when there will be much greater reluctance to
change or reinterpret requirements.
Update the Asset Fit Gap Analysis based upon the results of the Proof of Concept.
|
|