The purpose of this workflow detail is to complete the architecture for an iteration.

Topics


      Design Model
Design Model
Software Architecture Document
Software
Architecture
Document
  Design Model
Design Model
Software Architecture Document
Software
Architecture
Document
  Analysis Class
Analysis
Class
  Analysis Class
Analysis
Class
  Software Architecture Document
Software
Architecture
Document
Design Model
Design Model
 
               
 
Software Architect
Software
Architect

 

 
Describe Distribution
Describe
Distribution

 
Describe the Run-time Architecture
Describe
the Run-time
Architecture

 
Identify Design Elements
Identify
Design Elements

 
Identify Design Mechanisms
Identify
Design Mechanisms

 
Incorporate Existing Design Elements
Incorporate
Existing
Design Elements

 
               
      Deployment Model
Deployment
Model
Software Architecture Document
Software
Architecture
Document
  Design Model
Design Model
Software Architecture Document
Software
Architecture
Document
  Design Subsystem
Design Subsystem
Design Model
Design Model
  Design Model
Design Model
Software Architecture Document
Software
Architecture
Document
  Design Model
Design Model
Software Architecture Document
Software
Architecture
Document
 
              Design Package
Design Package
Signal
Signal
  Design Package
Design Package
Design Subsystem
Design Subsystem
  Design Package
Design Package
Design Subsystem
Design Subsystem
 
              Event
Event
Design Class
Design Class
  Design Class
Design Class
  Interface
Interface
Design Class
Design Class
 
              Enterprise Java Bean (EJB)
Enterprise
Java Bean
(EJB)
Interface
Interface
         

      Risk List
Risk List
Software Architecture Document
Software
Architecture
Document
 
       
 
Technical Reviewer
Technical
Reviewer

 

 
Review the Architecture
Review the
Architecture

 
       
      Review Record
Review Record
 


Description To top of page

This Workflow Detail:

  • Provides the natural transition from analysis activities to design activities, identifying:
    • appropriate design elements from analysis elements
    • appropriate design mechanisms from related analysis mechanisms
  • Describes the organization of the system's run-time and deployment architecture
  • Organizes the implementation model so as to make the transition between design and implementation seamless
  • Maintains the consistency and integrity of the architecture, ensuring that:
    • new design elements identified for the current iteration are integrated with pre-existing design elements.
    • maximal re-use of available components and design elements is achieved as early as possible in the design effort.

Related Information To top of page

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

Timing To top of page

Starts in Elaboration phase, recurs through Construction and Transition phases.

Optionality To top of page

Required.

How to Staff To top of page

These activities are best carried out by a small team staffed by cross-functional team members. Issues that are typically architecturally significant include usability, 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. The team will need to be able to pull all these disparate threads into a cohesive, coherent (albeit preliminary) architecture.

Because the focus of the architecture effort is shifting toward implementation issues, greater attention needs to be paid to specific technology issues. This will force the architecture team to shift members or expand to include people with distribution and deployment expertise (if those issues are architecturally significant). In order to understand the potential impact of the structure on the implementation model on the ease of integration, expertise in the software build management process is useful to have.

At the same time, it is essential that the architecture team not be composed of a large extended team. A strategy for countering this trend is to retain a relatively small core team with a satellite group of extended team members that are brought in as "consultants" on key issues. This structure also works well for smaller projects where specific expertise may be borrowed or contracted from other organizations; they can be brought in as specific issues need to be addressed.

Work Guidelines To top of page

The work is best done in several sessions, perhaps performed over a few days (or weeks and months for very large systems). The initial focus will be on the activities Identify Design Mechanisms and Identify Design Elements, with a great deal of iteration with the Incorporate Existing Design Elements activity to make sure that new elements do not duplicate functionality of existing elements.

As the design emerges, concurrency and distribution issues are introduced in the activities Describe the Run-time Architecture and Describe Distribution, respectively. As these issues are considered, changes to design elements may be required to split behavior across processes, threads or nodes.

As the individual models are refined to incorporate the architectural decisions, the results are documented in respective view sections in the Software Architecture Document (e.g., as the Design Model is refined, the Logical View of the Software Architecture Document is refined, as well). The resulting architecture is reviewed.



Rational Unified Process   2003.06.15