Task Descriptor: Outline the Architecture |  |
Outline the architecture through analysis of the architecturally significant requirements and identification of architectural constraints, decisions and objectives.
Based on Method Task: Outline the Architecture
Relationships
Roles | Main: Architect | Additional: Analyst Developer Project Manager Stakeholder | Assisting:
Inputs | Mandatory: Glossary Use-Case Model Vision | Optional: Architecture Supporting Requirements Specification Use Case | External: None
Outputs | Architecture
Steps
Identify architectural goals
Work with the team, especially the Stakeholder and Analyst, to describe the remaining goals for the architecture and identify which ones are appropriate to address for this iteration. Examine the product Vision and requirements. These goals will prioritize and guide the approach to important technical decisions. It will be important to regularly review the status of these goals throughout the project to make sure that they are still valid and that the system is on track to deliver them.
Identify architecturally significant requirements
Identify which of the current requirements are architecturally significant. Explore and refine those that must be implemented in order to realize the architectural goals for the current iteration. See Concept: Architecturally Significant Requirements and Guideline: Determine Architecturally Significant Requirements for more information. Reference the architecturally significant requirements in the Architecture Notebook after they are identified. It will be important to review this list regularly in line with changes to requirements to make sure that they are still valid.
Identify constraints on the architecture
List any constraints on the architecture and any trade-offs between competing requirements and resources. Decide how the architecture will meet these issues. Justify each of the decisions made and capture this information. Regularly review the list of constraints to make sure that they are still valid and that no new ones have appeared.
Survey, assess and select available assets
Identify assets from other areas that may be reused in the current architecture. These could include: Architectural frameworks Architectural mechanisms Architectural decisions Constraints Applications Components COTS software
Define approach for structuring the system
Decide how to structure the software, both in logical and physical terms. As a minimum, decide on: How to partition the software when managing development (the use of layering as a partitioning strategy, for example). How the software will be composed at run time. For each software partition, briefly describe Their name and purpose. Their relationships to other partitions. These decisions will form the basis for structuring the Design and the Build.
Define approach for deploying the system
Outline how the software will deploy over the nodes on the network. Work with stakeholders such as network support and deployment teams to ensure that the proposed approach is a good fit for the wider technical environment.
Identify key abstractions
Identify the key abstractions that the system needs to handle. These can usually be found by looking for nouns that the requirements emphasize or repeat, because they help identify what is important to the business. The Glossary is also a useful source for key abstractions as it is itself a list of business nouns. Not all nouns will be key abstractions in the system though, so work with the Analyst and Stakeholder as they will have knowledge and materials that are relevant to this step.
Identify architectural mechanisms
Make a list of the technical services that the system needs to provide and capture some basic information about each item on the list. It's generally a good idea to make an initial list of all the mechanisms required for the project and then prioritize the development of those that need to be delivered to achieve the goals of the current iteration. See Concept: Architectural Mechanism to understand what architecture mechanisms are and how to describe them. See Guideline: Architectural Mechanisms to understand how to develop them. See Guideline: Outline the Architecture for perspectives and issues to consider when defining the architecture.
Capture architectural decisions
Capture important decisions about the architecture for future reference. Consider using the templates provided for the Architecture Notebook. Developers in particular should clearly understand the current state of the architecture each iteration before developing the architecture.
Verify architectural consistency
The Architect works with the Developer and Project Manager to verify that the architecture is consistent with the requirements; and that the descriptions of the architecture are complete, meaningful, and clear.
Properties
Multiple Occurrences |
Event-Driven |
Ongoing |
Optional |
Planned |
Repeatable |
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. OpenUP Copyright.