The purpose of this workflow detail is to construct and assess an Architectural Proof-of-Concept to demonstrate that the system, as envisioned, is feasible.


Topics


          Risk List
Risk List
     
      Risk List
Risk List
  Business Case
Business
Case
Glossary
Glossary
  Design Model
Design Model
 
      Glossary
Glossary
Vision
Vision
  Vision
Vision
Architectural Proof-of-Concept
Architectural
Proof-of-Concept
  Deployment Model
Deployment
Model
Software Architecture Document
Software
Architecture
Document
 
           
 
Software Architect
Software
Architect

 

 
Architectural Analysis
Architectural
Analysis

 
Assess Viability of Architectural Proof-of-Concept
Assess Viability
of Architectural
Proof-of-Concept

 
Construct Architectural Proof-of-Concept
Construct
Architectural
Proof-of-Concept

 
           
      Deployment Model
Deployment
Model
Design Model
Design Model
  Reference Architecture
Reference
Architecture
Review Record
Review Record
  Architectural Proof-of-Concept
Architectural
Proof-of-Concept
 
      Analysis Class
Analysis
Class
Software Architecture Document
Software
Architecture
Document
         
      Analysis Model
Analysis
Model
         


Description To top of page

This workflow detail is about showing that there exists, or is likely to exist, a solution which will satisfy the architecturally significant requirements, thus showing that the system, as envisioned, is feasible.

Related Information To top of page

This section provides links to additional information related to this workflow detail.

Timing To top of page

Inception phase

Optionality To top of page

Optional

How to Staff To top of page

As with Workflow Detail: Define a Candidate Architecture, these activities are best carried out by a small team staffed by cross-functional team members. Issues that are typically architecturally significant include performance, scaling, process and thread synchronization, and distribution. The team should also include members with domain experience who can identify key abstractions. The team should also have experience with model organization and layering. From these inputs, the team will need to be able to synthesize a model, or even a prototype, of a solution.

Work Guidelines To top of page

This work takes place during inception, and so should be limited to one or two iterations. The purpose is to determine feasibility, not to construct the system during this workflow detail.



Rational Unified Process   2003.06.15