| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ProcessDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" epf:version="1.0.0" xmi:id="_mtb_DvL5Edm6Nvont3uinw" guid="_mtb_DvL5Edm6Nvont3uinw" version="1.0.0"> |
| <mainDescription><p> |
| This activity is repeated in each iteration in the Elaboration phase. The main&nbsp;goal of this activity is&nbsp;to |
| propose an <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html" guid="_0XAf0MlgEdmt3adZL5Dmdw">architecture</a> that addresses the requirements with high architectural risks, thus |
| providing a solid, yet resilient, foundation on which to build the system functionality. |
| </p> |
| <p> |
| The <a class="elementLinkWithUserText" href="./../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">architect</a> analyzes the architectural constraints, identifies available assets to |
| build the system, defines how the system will be structured, and identifies the initial abstractions and mechanisms |
| that must be provided by the architecture. |
| </p> |
| <p> |
| Throughout all of the iterations, the architect: |
| </p> |
| <ul> |
| <li> |
| Identifies commonalities between different requirements to leverage reuse |
| </li> |
| <li> |
| Defines strategies for achieving requirements related to quality |
| </li> |
| <li> |
| Captures and communicates architectural decisions |
| </li> |
| </ul></mainDescription> |
| <howtoStaff><p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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<b>.</b> 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. |
| </p></howtoStaff> |
| <usageNotes><p> |
| 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 identifying <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/design_mechanism,_w2ACwA4LEduibvKwrGxWxA.html" guid="_w2ACwA4LEduibvKwrGxWxA">Concept: Design Mechanism</a>s&nbsp;and&nbsp;specifiying the&nbsp;important&nbsp;design |
| elements.&nbsp;Care should also be taken to incorporate existing design elements to ensure that new&nbsp;design do not |
| duplicate existing functionality. |
| </p> |
| <p> |
| As the design emerges, concurrency and distribution issues are introduced. As these issues are considered, changes to |
| design elements may be required to split behavior across processes, threads or nodes. |
| </p> |
| <p> |
| As the individual models are refined to incorporate the architectural decisions, the results are documented in the |
| Architecture description. The resulting architecture is reviewed. |
| </p></usageNotes> |
| </org.eclipse.epf.uma:ProcessDescription> |