Capability Pattern: Determine Architectural Feasibility
Confirm that the project is feasible by constructing an architectural proof-of-concept.
DescriptionWork Breakdown StructureTeam AllocationWork Product Usage
Relationships
Context
Properties
Event-Driven
Multiple Occurrences
Ongoing
Optional
Planned
Repeatable
Staffing

As with Activity: Define the Architecture, this activity is 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.

Usage
Usage Notes

The major effort occurs early in the inception phase; thereafter, the system should be assessed at the beginning of each iteration to ensure that the design is still on track with the architecture (see Capability Pattern: Assess and Plan Iteration).

Estimation should ideally be based in the organization's own experience, which is then used to calibrate an estimation model, such as COCOMO. (See  http://sunset.usc.edu/research/cocomosuite/index.html.) If no other data are available and you are using default values for model coefficients, it will be important to use other methods to validate the estimates. It is just as important to obtain staff and other stakeholder agreement that the estimates are realistic and achievable. However, take into account the experience of staff giving feedback about estimates. More junior staff may be just guessing numbers and then adding large margins for error; conversely, their effort estimates may be naively low. Be circumspect when dealing with estimates from junior staff, and be prepared to counsel them when necessary, and offer the assistance of a more experienced peer.

All enclosed plans and sections of the Software Development Plan should be evaluated through internal walkthroughs and reviews.