Capability Pattern: Determine Architectural Feasibility |
Confirm that the project is feasible by constructing an architectural proof-of-concept.
| Description |  | Work Breakdown Structure |  | Team Allocation |  | Work Product Usage |  |
Relationships
Context | OpenUPBasic
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.
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. View copyright information here: OpenUP Copyright