Work Product (Artifact): Architectural Proof-of-Concept








var defaultQueryStr = '?proc={002674F9-6511-4D15-8623-B761D8C48986}&path={002674F9-6511-4D15-8623-B761D8C48986},{71ADFE9A-34A0-41BD-8A17-BEA3210E2BBD},_Pu3DA0ocEdqrjq4i3fchvA';
var backPath = './../../';
var imgPath = './../../images/';
var nodeInfo=null;
contentPage.preload(imgPath, backPath, nodeInfo, defaultQueryStr, false, true, false);










Work Product (Artifact): Architectural Proof-of-Concept















This work product is a solution, which may simply be conceptual, to the architecturally-significant requirements that are identified early in Inception.






Purpose



The purpose of the Architectural Proof-of-Concept is to determine whether there exists, or is likely to exist, a solution that satisfies the architecturally-significant requirements. 



Relationships



RolesResponsible:



Software Architect


Modified By:



Input ToMandatory:


None

Optional:



Architectural Analysis


External:


None





Properties



Optional


Planned



Tailoring



Representation Options The Architectural 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 decision about whether or not an Architectural Proof-of-Concept is required and what form it should take depends on: how well the domain is understood - if the domain is unfamiliar, the Architectural Proof-of-Concept may not only explore possible solutions, but may also help the customer and development organizations understand and clarify requirements the novelty of the system - if the development organization has constructed many such systems previously then it should not be necessary to build a proof-of-concept - it should be possible to base a determination of feasibility on existing reference architectures and technologies whether or not, even though the domain is familiar and the system is precedented, any of the requirements are judged to be particularly onerous; for example, ultra-high transaction rates or extreme reliability are required The higher the risk, the more effort needs to be put into this architectural synthesis activity in Inception (with the expectation of more realistic results from the models produced and assessed), so that all stakeholders can be convinced that the basis for committing funds and continuing into Elaboration is credible. However, it has to be recognized that all risks cannot be eliminated in this phase. The Inception phase should not be distorted into a de-facto Elaboration phase.





©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.







contentPage.onload();
contentPage.processPage.fixDescriptorLinks();