blob: 09b74ee7451984d367d84e0af0eccbba44073cb2 [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="" xmlns:org.eclipse.epf.uma="" epf:version="1.0.0" xmi:id="-1Lm8-0FY-QIC56u5t2SC9w" name=",__JXkoCk8EduLGM8dfVsrKg" guid="-1Lm8-0FY-QIC56u5t2SC9w" changeDate="2007-02-26T12:49:32.093+0000" version="1.0.0">
Here are some templates for representing the architecture. Architecture can be represented in a variety of ways,
according to the needs of the project team. See &lt;a class=&quot;elementLink&quot;
guid=&quot;_0XAf0MlgEdmt3adZL5Dmdw&quot;&gt;Architecture&lt;/a&gt;&amp;nbsp;for more information.
Feel free to use one or more of these templates or create your own.
The &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html&quot;
guid=&quot;_0X9iEMlgEdmt3adZL5Dmdw&quot;&gt;Architect&lt;/a&gt; should decide what views are useful for describing the system under
Consider one or more&amp;nbsp;relevant views of the architecture and document each one using the provided template for the
architectural view. If needed, document information that applies to more than one view using the template provided for
the Software Architecture Document to get an integrated representation of the architecture instead of just snapshots
taken from different angles.
The structuring of the documents must support the needs of the intended audience. For example, instead of a document
for the implementation view developers may find more useful alternative forms for the project directory structure like
the template provided for the project startup kit.
Keep documentation up-to-date but to an essential minimum. When the architecture is under development, decisions are
reconsidered frequently so constant revision of the documentation is an unnecessary expense.&amp;nbsp; Determine points in
the development lifecycle when documentation should be updated.