| <?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.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-TQGTcBlsrTWNeoszYTC7Cg" |
| guid="-TQGTcBlsrTWNeoszYTC7Cg" version="1.0.0"> |
| <mainDescription><p>
 |
| The goal of this activity is to&nbsp;define a technical approach to the system that&nbsp;supports the project
 |
| requirements,&nbsp;within the constraints placed on the system and the development team. The architect should do the
 |
| following:&nbsp;
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Work with the team to create an initial sketch of the&nbsp;technical approach to&nbsp;the proposed system
 |
| </li>
 |
| <li>
 |
| Ensure that the technical decisions are adequately captured and communicated
 |
| </li>
 |
| <li>
 |
| Ensure that the team has enough information to understand the approach being taken
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| The work done here does not seek to produce a detailed and comprehensive technical specification for the&nbsp;system.
 |
| Rather, the approach should be to decide the overall technical approach at a high level.
 |
| </p>
 |
| <p>
 |
| Emphasis should be placed on proving the architecture with working software. If the solution is similar to a system
 |
| produced previously (or is a well-known solution domain) then it&nbsp;will probably&nbsp;be good&nbsp;enough to
 |
| reference that example as evidence of the feasibility of the approach. In some cases, it may be necessary to develop
 |
| one or more prototypes to validate some of the decisions or clarify some of the requirements.
 |
| </p>
 |
| <p>
 |
| The conclusion of this work should produce just enough information to communicate the architecture to the team and
 |
| demonstrate its viability to the customer so that the project can move forward,&nbsp;enabling&nbsp;the
 |
| architecture&nbsp;to be refined and baselined.
 |
| </p></mainDescription> |
| <howtoStaff><p>
 |
| This activity is best carried out collaboratively by the&nbsp;team, with the architect&nbsp;acting as a focal point
 |
| for&nbsp;coordinating and facilitating the decisions.
 |
| </p></howtoStaff> |
| <usageNotes><p>
 |
| The major effort occurs early in the Inception phase; thereafter, the system should be assessed at&nbsp;every iteration
 |
| to ensure that the design is still on track with the architecture.
 |
| </p></usageNotes> |
| </org.eclipse.epf.uma:ProcessDescription> |
